Jan Hartmann wrote:
1) If a map is converted to OGR and converted back, there should be an option of getting it back byte-identical. Law #1 of archiving: always make sure that you can get back the original
Jan, I think this is generally impractical with most OGR formats. In most cases "ogr2ogr" from a file to a new file of the same file format will not be byte identical. Instead, if this is a goal of archiving, I'd suggest archiving the original data (in a possibly arcane format), and a copy in a more accessable format likely to still be usable decades later.
2) For long term archival purposes, there should be an ascii format (XML or GeoJSON) associated with OGR. I have had to converted binary files from a 60-bits Cyber long ago, so I know what I am talking about. God knows what a computer word will look like in the age of quark-computers.
It would be relatively easy to have an XML format which is a lossless dump of what OGR knows through it's data model. However, it might be unlikely that any application not built on OGR would ever support it. The OGR VRT driver already captures most of this with my recent addition of schema support. It could be extended to actually be a feature store. Alternatively, we could look at improving the GML driver to support capture of everything that OGR can represent. This would have the benefit of being useful in non-OGR applications.
3) There should be some sort of lossless compression scheme associated with OGR
With Even's work, it is not possible for many drivers to to transparently access compressed files using the /vsigzip/ mechanism.
3) Topology would be nice too. What to think about the way ArcGIS does it nowadays? It uses some sort of shapefiles as base maps, but computes the topology (you can choose different criteria) and puts it in separate files. There is work going on for topology in the PostGIS, I believe, but it is a horribly difficult subject, of course.
Note that the OGR Arc/Info binary coverage (and I think a few others drivers) do capture and represent topological relationships with features. However, different drivers do this in slightly different ways since there is no well defined way of doing this in the OGR data model. There are no tools to build topology in GDAL but perhaps this could be a GRASS task. Of course, OGR does nothing to update topologies cleanly. Currently it really just allows access to existing topological datasets.
The problem with (governmental) organisations is that they create their own small universums, which aren't compatible with other universums, and even don't know about each other's existence.
Very true, and to some extent this can also happen to software projects (open source and proprietary). Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
