Hi, 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 value. > 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 > with. 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 vanished again. 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. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
