[OSM-dev] Relations, landuse, and gml2osm mess
frederik at remote.org
Sun Mar 30 19:20:02 BST 2008
On Sun, Mar 30, 2008 at 06:04:04PM +0200, Stefan Keller wrote:
> GML uses XML and you can use XLink to encode relationships - even
> between layers. And "layers" can be put in one file. GML
> purposely encodes polygons as separate object to support object
> oriented handling. This does not exclude sharing attributes if
> you add this as an additional constraint.
But that would then be some "custom addition" that's not enshrined in
GML, wouldn't it? I mean I could do all sorts of things with GML based
on the fact that it's XML, but an application that claims to be able
to "read GML" would not necessarily be able to read whatever extra
stuff I built in.
What, exactly, does it mean if a product claims to "support GML"? Is
that a more or less bogus claim like "this product supports CSV" or
"supports ASCII"? Or is the information that something supports GML a
hard fact that tells me it will be able to read and meaningfully
process my file if it has the proper structure?
As far as I see, GML is based on "profiles" which seem to define a lot
of what's in the file. Could I simply define an "OSM profile", export
GML using that profile and tell everybody that I now support GML?
Would applications that claim to support GML be able to read my data,
given a proper definition of the profile - or is GML support in
applications usually limited to the "Simple Features" profile?
> Handling of shared topology always was a matter of controversy. The
> only two big (!) GIS systems which tried it that way I know of
> disapeared from the market.
I have the impression that this depends on what people want to do with
the data. It seems to me that topology is very important if you want
to *edit* the data, especially if it has some kind of network
structure. As long as you only process read-only data, a lack of
topology doesn't hurt you too much.
I could well imagine downloading map data from somewhere and
instructing my GIS program to filter and display all that in a nice
way without topology. But downloading, modifying, and uploading again
seems difficult. On the other hand, distributed editing is not a
traditional GIS core task, so maybe those systems that did support
topology were perceived to add too much complexity for too little
> That does'nt mean it's completely wrong what you're trying to
> do with relations. Still I think your approach - with node-ways,
> "predefined" keys and now relations - will become more and more
> complicated the more computational geometry artefacts you try to cope
I'm with you in that it would have a certain appeal to have a few
extra basic types in our repertoire, instead of just nodes and ways.
We did have an extra area type once, but that was never used and so
On the other hand, we only have to store what our mappers map, and
there are certain limits to their creativity when it comes to
designing complex computational geometry artifacts. They're not
professionals and it is difficult to force complex models on them.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev