RE: [Flightgear-devel] Re: Custom scenery integration
Martin Spott wrote: Does osgPlanet allow for contour lines for elevation data instead of DEM's ? No FYI osgPlanet questions better asked on the OSSIM list. http://mailman.remotesensing.org/mailman/listinfo/ossim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Jon Stockill wrote: The SRTM data is available in GeoTIFF format. gdal_contour (from gdal) can convert this to contour lines. Well, I expect I'll be able to take SRTM data in any format, not only GeoTIFF. I don't think the format will get me into trouble. I'm currently working on setting up database infrastructure for that, starting with VMAP0 data that everyone with appropriate skills will be able to improve. After I'm done with this I'll investigate if we really profit from converting DEM's into contour lines or it it makes more sense to simply overlay contour lines over the DEM. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Hello, Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? Well, this approach certainly enables us to store and retrieve elevation data, but to my knowledge neither of both methods is suited to alter the data using the preferred tools like GRASS for example. We probably would need to build our own storage method for GRASS !? I don't see why we need to store elevation data for the whole world in the database anyway. I wouldn't think elevation data would be a typical subject for user-submitted modifications related to wide areas. If more detailed structures are desired than provided by the DEM data, corrective contour data for small areas could be stored in the database and be combined with the official DEM data, which could be stored outside the database. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Custom scenery integration
Martin Spott writes: Ralf Gerlich wrote: I don't see why we need to store elevation data for the whole world in the database anyway. I wouldn't think elevation data would be a typical subject for user-submitted modifications related to wide areas. If more detailed structures are desired than provided by the DEM data, corrective contour data for small areas could be stored in the database and be combined with the official DEM data, which could be stored outside the database. Great, this is almost exactly what Frederic and I discussed while talking about his intended reorganization of FGSD :-) The beauty of storing things in a DB is that you can easily have a history of the changes, maintain metadata, and have an easier way to serve the data thru OGC Standard Interfaces. Also once you start making any changes you have to go thru the DB Interface anyway unless you just modify the originals. Then again since FGFS is just a g 'game' /g Also who knows Native PostGIS support for Raster Data may not be all that far in the future :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Norman Vine wrote: Also who knows Native PostGIS support for Raster Data may not be all that far in the future :-) I typically expect that _you_ know much more of what happens on this terrain than I do :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich wrote: I don't see why we need to store elevation data for the whole world in the database anyway. I wouldn't think elevation data would be a typical subject for user-submitted modifications related to wide areas. If more detailed structures are desired than provided by the DEM data, corrective contour data for small areas could be stored in the database and be combined with the official DEM data, which could be stored outside the database. I converted a chunk of SRTM data to 10m interval contours, and overlaid this on an ordnance survey map (using mapserver) - the results are actually incredibly close - the 0 point of the two datasets is obviously slightly different, but the two datasets fit together remarkably well - Obviously I have no idea how good the data is for the rest of the world, but the UK data seems surprisingly accurate, which leads me to my question - is there really such a huge problem with our source data, or do we just need to be generating scenery with more polygons? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Hello, Norman Vine schrieb: Martin Spott writes: Great, this is almost exactly what Frederic and I discussed while talking about his intended reorganization of FGSD :-) Hm, as long as you did not yet patent it, there is not a problem, is it? ;-) The beauty of storing things in a DB is that you can easily have a history of the changes, maintain metadata, and have an easier way to serve the data thru OGC Standard Interfaces. Also once you start making any changes you have to go thru the DB Interface anyway unless you just modify the originals. My point was that we don't have to store the DEM data in raster format. As long as there is no PostGIS support for raster data, we either need to store the raster data outside of PostGIS or store it as vector data such as contours. The whole SRTM-DEM-set stored as contours however possibly would take lots of space in the DB and throttle access to the data when generating the scenery (correct me, if I'm wrong) The original DEM-set is unlikely to change in detail, except for when a new topography mission is started (AFAIK, the German Aerospace Center is currently preparing for a mission for 1arcsec DEM data, however no free download intended) and the data is disseminated. It is questionable whether we'd want to record the changes in that. The actual user-supplied modifications would be stored in vector format in the database and would be subject to the change monitoring you stated. Probably most of the surface of the earth would not have to be touched at all ;-) Also who knows Native PostGIS support for Raster Data may not be all that far in the future :-) Well, then it depends on who is ready first: us or them ;-) In any case, any DB-support for raster data would need integration with GIS-tools in some way. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Hello, Jon Stockill schrieb: I converted a chunk of SRTM data to 10m interval contours, and overlaid this on an ordnance survey map (using mapserver) - the results are actually incredibly close - the 0 point of the two datasets is obviously slightly different, but the two datasets fit together remarkably well - Obviously I have no idea how good the data is for the rest of the world, but the UK data seems surprisingly accurate, which leads me to my question - is there really such a huge problem with our source data, or do we just need to be generating scenery with more polygons? I haven't yet tried it, but did anyone have a look at, e.g., Niagara Falls, in the standard DEM set? Given that 3arcsec data means a distance of about 60-70m between raster point centers I don't think such landmarks should look good in the scenery. In general I'm thinking about specific landmarks, which are important enough to be included for VFR flying but small enough to fall through the grid of SRTM. After all this detail might not be important enough for having to discuss it in length before going to the real work for the rest of the (virtual) world ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich wrote: Hello, Norman Vine schrieb: Martin Spott writes: Great, this is almost exactly what Frederic and I discussed while talking about his intended reorganization of FGSD :-) Hm, as long as you did not yet patent it, there is not a problem, is it? ;-) Hmmm, maybe I should switch over to a different business :-) The actual user-supplied modifications would be stored in vector format in the database and would be subject to the change monitoring you stated. Probably most of the surface of the earth would not have to be touched at all ;-) I agree, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich writes: My point was that we don't have to store the DEM data in raster format. As long as there is no PostGIS support for raster data, we either need to store the raster data outside of PostGIS or store it as vector data such as contours. I agree you don't have to but there are advantages to doing so, the way you do this is to store the DEM as a BLOB whose polygon is a PostGIS object. Note this allows you to use PostGIS spatial functions Any way just a suggestion for a way to bring TerraGear into the world of the main stream Open Source GIS standards Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
On Monday, 4 July 2005 15:04, Jon Stockill wrote: I converted a chunk of SRTM data to 10m interval contours, and overlaid this on an ordnance survey map (using mapserver) - the results are actually incredibly close - the 0 point of the two datasets is obviously slightly different, but the two datasets fit together remarkably well - Obviously I have no idea how good the data is for the rest of the world, but the UK data seems surprisingly accurate, which leads me to my question - is there really such a huge problem with our source data, or do we just need to be generating scenery with more polygons? SRTM3 is very coarse. What I had problems with were airports that are on hill tops or steep terrrain. One example being KAVX. One would need a DEM with a = 5m sample spacing and about 1 meter vertical accuracy around such airports. SRTM's vertical accuracy is only guaranteed to be within 16 meters! It's usually within 10 meters but that is still a large error when dealing on a micro scale. Also what about custom mods like Alcatraz? There is going to be a need to custom tweak scenery with regards to both the DEM and the vector overlays (roads, rivers, railroads, powerlines, etc). Having everything in one DB with a single TG exporter interface is going to make life a lot easier in the long run in my opinion and there are numerous advantages which haven't been discussed yet. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: Martin Spott writes: I'm currently uncertain if we really can store the _whole_ scenery in PostGIS. Our elevation data currently comes as raster data but maybe it makes sense to convert that into contour lines - which we finally can store in such a database as well. Does this make sense, Norman, or will this eliminate our ability to alter the data with 'common' tools ? Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? I wouldn't store contour lines as you'll allways loose precision by converting the data (DEM - contour lines - triangle mesh). Beeing able to change the elevation data can be important, especially when you are puting a finer grid over the data. I dunno what is possible with PostGIS but the most intuitive solution would be to store additional elevation data on arbitrary positions. Then the resulting mesh could be calculated by a weighted average (using the 2D distance) of the cutom elevation and the underlaying DEM. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCyYSZlhWtxOxWNFcRAvW6AKCL/lc6zq4xuDtHKnE5bRMkjh9amQCdG9Vy 9e8Ihp/XgLydtYH5yEvSTbg= =pR6o -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Christian Mayer wrote: Norman Vine schrieb: Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? I wouldn't store contour lines as you'll allways loose precision by converting the data (DEM - contour lines - triangle mesh). Oh, I still believe that hand-crafted contour lines give us some of the highest precision we can get. If you force the triangulator to let the contour lines lie precisely in the triangulated surface (without any weighing), then you'll inevitably get the desired result. Norman Vine wrote: I agree you don't have to but there are advantages to doing so, the way you do this is to store the DEM as a BLOB whose polygon is a PostGIS object. Note this allows you to use PostGIS spatial functions Any way just a suggestion for a way to bring TerraGear into the world of the main stream Open Source GIS standards Just for the understanding: Does this mean you are going to define an area via the polygon and store the DEM as a BLOB that fits exactly into this polygon ? I didn't realize that this was already common use does todays OpenSource GIS software really handle DEM's this way ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Custom scenery integration
Martin Spott writes: By definition you can transform the current VMAP0 data, which comes in the so called VPF format, into shapefiles. In order to achieve this you need OGR and the OGDI VPF driver (Norman, please correct me if I'm wrong). The same set of tool scan be used to go directly to PostGIS without teh intermediary shapefile step. Once we have the landcover data in a PostGIS database we are enabled to manually adjust roads and rivers, add ponds like the one in front of the Oracle building and send everything to Curt for the scenery generation if someone adds a Shapefile or PostGIS driver to TerraGear which replaces the current VMAP0 importer. I'm currently uncertain if we really can store the _whole_ scenery in PostGIS. Our elevation data currently comes as raster data but maybe it makes sense to convert that into contour lines - which we finally can store in such a database as well. Does this make sense, Norman, or will this eliminate our ability to alter the data with 'common' tools ? Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
On Sun, 3 Jul 2005 21:51:24 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Norman Vine wrote: Ralf Gerlich writes: Actually, I _do_ agree that having preprocessed scenery _is_ an advantage. But it does have disadvantages as well: 1.) At the current state it appears (to me) nearly impossible to inject user-contributed additions into the scenery, 2.) I don't manage to build the necessary tools on my server ;-)) Share your problems with us, perhaps we can help ;-) I simply chose the 'wrong' hardware: I'm running AIX on my RS6k server. A great machine to build FlightGear scenery (4 GByte RAM, 8 CPU's) but without a compiler that meets the requirements. ..stupid Q: Can this iron run User Mode Linux? Qemu? Bochs? ..emulator overhead, but allows running all the goodies. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Norman Vine wrote: Martin Spott writes: I'm currently uncertain if we really can store the _whole_ scenery in PostGIS. Our elevation data currently comes as raster data but maybe it makes sense to convert that into contour lines - which we finally can store in such a database as well. Does this make sense, Norman, or will this eliminate our ability to alter the data with 'common' tools ? Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? Well, this approach certainly enables us to store and retrieve elevation data, but to my knowledge neither of both methods is suited to alter the data using the preferred tools like GRASS for example. We probably would need to build our own storage method for GRASS !? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Arnt Karlsen wrote: On Sun, 3 Jul 2005 21:51:24 + (UTC), Martin wrote in message I simply chose the 'wrong' hardware: I'm running AIX on my RS6k server. A great machine to build FlightGear scenery (4 GByte RAM, 8 CPU's) but without a compiler that meets the requirements. ..stupid Q: Can this iron run User Mode Linux? Qemu? Bochs? It probably would be _much_ easier to build the desired geo-tools on that machine than building an emulator :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
