Re: ISA Core Location Vocabulary

On 2013-12-24 1:34, Andrea Perego wrote:
> On Mon, Dec 23, 2013 at 1:21 PM, Frans Knibbe | Geodan 
> <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>> wrote:
>
>     On 2013-12-22 1:53, Andrea Perego wrote:
>
>         Thanks, Ghislain.
>
>         Actually, the approach adopted in the Core Location Vocabulary
>         was to allow the use of any kind of geometry
>         encoding/representation (so, yes, Frans, also the NeoGeo voc
>         is supported, even though it is not included in the examples).
>         The point was that there was no agreement in the group about
>         the best way to represent geometries. Rather, the group
>         recognised that this depends on the specific use case.
>
>         I wonder whether which are views in the CG on this issue.
>
>
>     I think that in the end we need one commonly used way to encode
>     geometry. The vocabulary now allows any kind of encoding that was
>     ever invented. That allows for freedom to adapt to existing
>     systems, but it does not help interoperability much. So I think it
>     would be a good idea to try to agree on a best practice for
>     encoding geometry in this group.
>
>
> Thanks, Frans. However, before considering the revision of the LOCN 
> voc in this direction, I would kindly ask some more feedback from the 
> group.
Yes, of course.

By the way, perhaps it would help to publish something about the 
connection between LOCN and LocAdd on the LocAdd home page 
(http://www.w3.org/community/locadd/)? Perhaps that would solicit some 
more feedback.
>
>     With regard to interoperability of INSPIRE data: Isn't geometry
>     generally defined as GM_Object (from ISO 19107)  in INSPIRE?  And
>     shouldn't that mean that any geometry encoding should support all
>     subtypes of GM_Object?
>
>
> Sorry, Frans, I'm missing the point here - probably because of the 
> late hour ;)
>
> Could you please articulate it more explicitly?
Yes, I will try. I think the point I wanted to make is that GM_Object 
allows many kinds of exotic geometries that are not supported by some of 
the geometry encodings that are allowed by LOCN. So a data publisher 
having INSPIRE-compliant data, based on GM_Object, could not make use of 
encodings like KML or GeoShape because they are not able to express all 
the kinds of geometries that should be possible according to INSPIRE. So 
perhaps the ability to handle GM_Object should be a criterion in the way 
locn:geometry is defined?


>
> Andrea