<div>Dear Frederik,</div>
<div> </div>
<div>You wrote:</div>
<div>> As far as I see, GML is based on "profiles" which seem to define a lot<br>> of what's in the file. Could I simply define an "OSM profile", export<br>> GML using that profile and tell everybody that I now support GML?<br>
> Would applications that claim to support GML be able to read my data,<br>> given a proper definition of the profile - or is GML support in<br>> applications usually limited to the "Simple Features" profile?<br>
<br>GML 2.x are mostly user in practice. These versions are less complex as the current version GML 3.2.1.</div>
<div>And in fact, ESRI for example only supports a sort of "ESRI Profile" for GML.</div>
<div>So I would prefer version 2.1 of GML if I had to decide.</div>
<div> </div>
<div>-- Stefan<br> </div>
<div><span class="gmail_quote">2008/3/30, Frederik Ramm <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>>:</span> 
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>On Sun, Mar 30, 2008 at 06:04:04PM +0200, Stefan Keller wrote:<br>> GML uses XML and you can use XLink to encode relationships - even<br>
> between layers. And "layers" can be put in one file. GML<br>> purposely encodes polygons as separate object to support object<br>> oriented handling. This does not exclude sharing attributes if<br>> you add this as an additional constraint.<br>
<br>But that would then be some "custom addition" that's not enshrined in<br>GML, wouldn't it? I mean I could do all sorts of things with GML based<br>on the fact that it's XML, but an application that claims to be able<br>
to "read GML" would not necessarily be able to read whatever extra<br>stuff I built in.<br><br>What, exactly, does it mean if a product claims to "support GML"? Is<br>that a more or less bogus claim like "this product supports CSV" or<br>
"supports ASCII"? Or is the information that something supports GML a<br>hard fact that tells me it will be able to read and meaningfully<br>process my file if it has the proper structure?<br><br>As far as I see, GML is based on "profiles" which seem to define a lot<br>
of what's in the file. Could I simply define an "OSM profile", export<br>GML using that profile and tell everybody that I now support GML?<br>Would applications that claim to support GML be able to read my data,<br>
given a proper definition of the profile - or is GML support in<br>applications usually limited to the "Simple Features" profile?<br><br>> Handling of shared topology always was a matter of controversy. The<br>
> only two big (!) GIS systems which tried it that way I know of<br>> disapeared from the market.<br><br>I have the impression that this depends on what people want to do with<br>the data. It seems to me that topology is very important if you want<br>
to *edit* the data, especially if it has some kind of network<br>structure. As long as you only process read-only data, a lack of<br>topology doesn't hurt you too much.<br><br>I could well imagine downloading map data from somewhere and<br>
instructing my GIS program to filter and display all that in a nice<br>way without topology. But downloading, modifying, and uploading again<br>seems difficult. On the other hand, distributed editing is not a<br>traditional GIS core task, so maybe those systems that did support<br>
topology were perceived to add too much complexity for too little<br>value.<br><br>> That does'nt mean it's completely wrong what you're trying to<br>> do with relations. Still I think your approach - with node-ways,<br>
> "predefined" keys and now relations - will become more and more<br>> complicated the more computational geometry artefacts you try to cope<br>> with.<br><br>I'm with you in that it would have a certain appeal to have a few<br>
extra basic types in our repertoire, instead of just nodes and ways.<br>We did have an extra area type once, but that was never used and so<br>vanished again.<br><br>On the other hand, we only have to store what our mappers map, and<br>
there are certain limits to their creativity when it comes to<br>designing complex computational geometry artifacts. They're not<br>professionals and it is difficult to force complex models on them.<br><br>Bye<br>Frederik<br>
<br>--<br>Frederik Ramm  ##  eMail <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>  ##  N4900'09" E00823'33"<br><br></blockquote>
</div><br>