[OSM-dev] Relations, landuse, and gml2osm mess

[Stefan Keller]

Dear Frederik,

You wrote:
> 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?

GML 2.x are mostly user in practice. These versions are less complex as the
current version GML 3.2.1.
And in fact, ESRI for example only supports a sort of "ESRI Profile" for
GML.
So I would prefer version 2.1 of GML if I had to decide.

-- Stefan

2008/3/30, Frederik Ramm <frederik at remote.org>:
>
> 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 frederik at remote.org  ##  N49°00'09" E008°23'33"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080401/3a299602/attachment.html>