eugeneloza/castlegis

Trying to implement basic GIS features for CGE. Moved to https://gitlab.com/EugeneLoza/CastleGIS

castlegis's Issues

Stick to X3D nodes

@eugeneloza X3D specification includes geospatial component http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html . This allows to place things (visible things, viewpoints, etc.) at geospatial coordinates. So, GIS inside CGE should integrate with it :)

The advantage is that someone already designed these X3D nodes (hopefully with a sensible and generally-useful properties and concepts). And there are examples, like http://www.web3d.org/x3d/content/examples/Basic/GeoSpatial/ . And it would integrate then with engine perfectly, just new X3D nodes that work to represent something.

We already parse all X3D nodes related to it, see src/x3d/x3dnodes_standard_geospatial.inc . But we don't do anything with them, for now. For starters, one could probably implement GeoTransform (just like current TTranformNode, you can override one method to apply a transformation defined by GeoTransform). You could also implement GeoElevationGrid by defining a "proxy" that implements IndexedFaceSet from it (see how e.g. Cylinder or NURBS or ElevationGrid nodes are implemented, they use a "proxy" underneath to actually realize everything by an IndexedFaceSet).

All of this can be implemented locally in src/x3d/x3dnodes_standard_geospatial.inc .
michalis - Today at 8:00 PM
@eugeneloza Note: I would not worry about Single vs Double precision for start, I would first implement something working by using the existing engine infrastructure. Just making sure the API uses Double-coordinates, like X3D already does. Underneath various things may "degenerate" to Single, but maybe it's acceptable (for start)? It would sure make implementing easier. Let's worry about precision later.

Note that I did not read the X3D geospatial specification carefully yet, so I do not guarantee that everything is perfect there 😃 But it is something ready, already designed, and we already even process it (parse etc.) as it's just defined in terms of X3D nodes.

This doesn't mean that we cannot add our own methods, propertiers, or even whole classes related to GIS. Sure we can (just like we do for a lot of existing X3D nodes, to make using them from Pascal more comfortable or flexible). But everything should, ideally, revolve around, and be integrated with X3D geospatial nodes, as much as possible.

I looked at your code https://github.com/eugeneloza/CastleGIS/blob/master/castlegis.pas and I don't really have anything useful to add 😃 This seems like a possible basis for some concepts of X3D geospatial component. Some tiny style hints only: single->Single (this is not a keyword, so we write it CamelCase), and usually avoid spelling out Self.(edited)

michalis - Today at 8:14 PM
@eugeneloza If your code would make us support X3D geospatial nodes, that would be very great:) Googling, I found some information about it. You should also be able to test geospatial nodes in other X3D browsers (at least X3DOM https://www.x3dom.org/ and FreeWRL ), both free and open-source, seem to implement then. So you can test how some X3D models work in them. Some more resources : https://x3dgraphics.com/slidesets/X3dForAdvancedModeling/GeospatialComponentX3dEarth.pdf , https://sites.google.com/site/x3dgeo/x3d-geospatial-nodes , https://www.researchgate.net/publication/321201556_3D_geospatial_visualizations_Animation_and_motion_effects_on_spatial_objects .(edited)

Cycle map

TGeoLabel

TGeoObject.Draw

TCity