Re: Sub-properties for locn:geometry?

On 2014-01-21 22:56, Simon.Cox@csiro.au wrote:
> John -
>
> 1.
> +1 on 'representative point' over 'centroid'.
> There are many examples of real geographic features which are disconnected multi-polygons or 'gerrymander' shapes where the geometric centroid falls outside the actual geometry. Cartographers have known this for ever, so are used to choosing a representative point that is 'more characteristic' of the feature. (For cities it was traditionally the central Post Office.)
We could have both, and try to explain the difference. I think centroids 
are easier to calculate automatically, so there could be cases where a 
centroid is known but a representative point is not. Or would the 
centroid count as a representative point in such cases?
>
> 2.
> The locn:extent should be a box, rather than a generic polygon.
> There is nothing in GeoSPARQL SF that corresponds with this.
>
> In ISO 19107 it is called 'GM_Envelope' for which I made a basic OWL2 implementation here: http://def.seegrid.csiro.au/isotc211/iso19107/2003/geometry#Envelope
>
> i.e.
>    locn:extent [ a gm:Envelope ] .
>
> However, in ISO 19107 GM_Envelope is not a specialization of GM_Object.
> There are good theoretical reasons for this, but it may be inconsistent with locn:extent rdfs:subClassOf locn:geometry .
Perhaps not, because a locn:Geometry is not the same as a GM_Object.

Regarding naming of the new properties: I like the name MBR (Minimal 
Bounding Rectangle), because it really makes clear what it is. Or if we 
just use a name with 'box' or 'rectangle' somewhere in it I think it 
would be clear too.
>
> Simon
>
>
> -----Original Message-----
> From: John Goodwin [mailto:John.Goodwin@ordnancesurvey.co.uk]
> Sent: Wednesday, 22 January 2014 6:34 AM
> To: Raphaël Troncy; Andrea Perego; Frans Knibbe | Geodan
> Cc: Sven Schade; LocAdd W3C CG Public Mailing list
> Subject: RE: Sub-properties for locn:geometry?
>
> Hi all,
>
> First - thank for the link Raphael - that did make me smile. The problems mixing work and social circles together ;)
>
> Anyway, here is my concrete example starter:
>
> If you look at the OS linked data for 'Southampton':
>
> http://data.ordnancesurvey.co.uk/id/7000000000037256
>
> you will noticed that it is related to a 'Geometry' via the predicate 'extent' and it also has predicates geo:lat, geo:long and 'easting'/'northing'. geo:lat, geo:long and 'easting'/'northing' provide information about a 'representative point' for Southampton (centroid is a bit overloaded I think). This 'representative point' is just a point guaranteed to lie within Southampton. I think it is useful (in this case) to provide both the 'representative point' and the polygon for area Southampton covers. So something like:
>
> os:7000000000037256
>    a locn:Location;
>    locn:representativePoint os:1234;
>    locn:extent os:2458;
>    os:1234 a sf:Point;
>    os:2468 a sf:Polygon;
>    ...
>
> or if you prefer:
>
> os:7000000000037256
>    a locn:Location;
>    locn:representativePoint os:1234;
>    locn:extent os:2458;
>    os:1234 a neogeo:Point;
>    os:2468 a neogeo:Polygon;
>    ...
>
> Maybe then (in Manchester OWL syntax(ish)):
>
>   locn:representativePoint rdfs:range (neogeo:Point OR sf:Point or geo:Point)  locn:extent rdfs:range (neogeo:Polygon or sf:Polygon)
>
>
> (not saying representativePoint or extent are best choices for predicate names at this stage).
>
> John
>
>
> Dr John Goodwin
> Principal Scientist
> Research, Ordnance Survey
> Adanac Drive, SOUTHAMPTON, United Kingdom, SO16 0AS
> Phone: +44 (0) 23 8005 5761
> www.ordnancesurvey.co.uk | john.goodwin@ordnancesurvey.co.uk Please consider your environmental responsibility before printing this email.
>
>
> -----Original Message-----
> From: Raphaël Troncy [mailto:raphael.troncy@eurecom.fr]
> Sent: 21 January 2014 15:40
> To: Andrea Perego; Frans Knibbe | Geodan
> Cc: Sven Schade; LocAdd W3C CG Public Mailing list
> Subject: Re: Sub-properties for locn:geometry?
>
> Hello all,
>
>> In order to verify the current position of the group, could you please
>> five your vote to the following proposal:
>>
>> 1. Definition of sub-properties of locn:geometry to denote MBRs,
>> centroids, etc.
>>
>> 2. They can be used to specify the MBR, centroid, etc. of a
>> dcterms:Location
>>
>> 3. They can be used to specify the MDR, centroid, etc. of a geometry
> Before we come to a vote (I'm not sure I understand fully those proposals by the way), can we have a *concrete* example (preferably in
> turtle) of how we express those things for each of the 3 variants?
> As an example, let's pick Southampton or a smaller district (*) of the city.
>
>     Raphaël
>
> (*) For example, the district around
> https://www.foursquare.com/v/4bc1cd504cdfc9b60b0e9521 :-)
>
>     Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Multimedia Communications Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/
>
> This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person.
>
> Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice.
>
> Thank you for your cooperation.
>
> Ordnance Survey
> Adanac Drive
> Southampton SO16 0AS
> Tel: 08456 050505
> http://www.ordnancesurvey.co.uk
>   
>


-- 
--------------------------------------
*Geodan*
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
--------------------------------------

Received on Wednesday, 22 January 2014 08:58:48 UTC