GML instances can be clear and concise :-) when the content model is clear,
simple, and concise.
For example, there is an OGC GML Point Profile that encodes as follows (less
the obligatory header goo for the XML file):
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>45.256 -110.45</gml:pos>
</gml:Point>
The typical size would be 90 bytes per point with no compression.
And if WGS-84 2d is the default CRS, then the SRSname can be removed.
Just had to say so.
Also, there is an interesting comparison of file sizes using different geo
encodings on a given land and water dataset done by Andrew Turner.
Interesting results. GeoRSS GML was the most compact and efficient. GeoJSON,
KML, Shape files, and SpatialLite all created files at least 75% larger.
Interesting.
Cheers
Carl
----- Original Message -----
From: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>; "Andy Mabbett"
<andy@pigsonthewing.org.uk>
Cc: <geopriv@ietf.org>
Sent: Thursday, September 03, 2009 2:18 AM
Subject: Re: [Geopriv] New version of geo-URI
> Henning,
>
> Thanks for the comments. Some thoughts inline:
>
>> However, marking alone isn't very interesting or helpful, except to
>> recognize that all you can do is discard the information received.
>
> Exactly. That's why i was pushing for an agreed default that is well
> known and understood to any author and consumer.
>
>> (1) Either the sender re-codes the datum to WGS-84, if that is
>> possible without losing information;
>
> That's exactly the idea. If people are unhappy with that option, there's
> always GML to express nearly arbitrarly complex geometries in thousands
> of CRSes. GML documents are not simple and concise, though.
>
>> (2) Or it negotiates what datum to use, hoping to find common
>> ground -
>> only applies in certain circumstances and would point to extensions
>> of, say, HTTP;
>
> As you noted, negotiation is not possible in many situations, because it
> requires a protocol that can negotiate - therefore i don't think it's an
> option.
>
>> (3) Or it provides multiple versions, in the hope that one of them
>> will work for the receiver.
>
> Would be an option, although not an efficient one - especially
> considering that there are thousands of CRSes out there.
>
> Alex
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
