Re: [geonet/its] challenges proposed by Dimitri

[Alexandru Petrescu <[e-mail]>]

Le 10/01/2014 01:07, Carl Reed a écrit :
> Alex -
>
> Depends on your requirements - such as types of geometry required
> (such as point, linestring, polygon, circle, etc), requirement for
> "compactness", and so forth.

Makes sense.  Also I think we'd need to decide that these are
three-dimensional volumes from the start, not just 2D.  For example when
many highways branches pass one under another, their RSUs would be
visible from up above of the other way.

> Also, does the encoding need to be binary or is XML or JSON OK.

Right, I wonder whether any draft or RFC offers XML or JSON
representations of geography concepts at IETF.

> The best way to start is to define a content model that is encoding
> agnostic and then provide encodings.

I agree, it's a good distinction.  The content model could be something
like "GPS coordinates with WGS-84", and the encoding could be "XML".

> Check out georss.org for an example. There is also the GeoPriv
> geodetic encoding (Location Object):
> portal.opengeospatial.org/files/?artifact_id=21630‎ . This is an XML
> encoding based on GML.

Thanks.

Is this an IETF document?  (I did click on it, but I can't understand).

> I am out of the office for a couple of days. More later.

Thanks,

Alex

>
> Cheers
>
> Carl
>
>
> ----- Original Message ----- From: "Alexandru Petrescu"
> <[e-mail]> To: "Carl Reed"
> <[e-mail]>, "Dino Farinacci" <[e-mail]>
> Cc: "Georgios Karagiannis" <[e-mail]>, "dimitri
> papadimitriou" <[e-mail]>,
> [e-mail] Sent: Thursday, January 9, 2014 9:31:46 AM Subject: Re:
> [geonet/its] challenges proposed by Dimitri
>
> Le 09/01/2014 00:44, Carl Reed a écrit :
>> Dino -
>>
>> Thanks.
>>
>> I was suggesting an approach to uniquely identify a location
>> without having to use lat-long coordinates. The issue of a
>> "boundary" is different. FYI, a boundary of three of more
>> non-intersecting sides/edges (in GIS) is a polygon. All treated
>> the same. ISO 19107:Spatial Schema provides a set of mathematical
>> definitions for various types of 2d and 3d geometry. We use these
>> definitions in the OGC - as does OASIS, NENA, and a number of
>> other standards organizations that work with geometry and
>> location.
>
> Carl - that sounds interesting.
>
> I wonder whether there exist some RFC or draft that tells how to
> encode or transmit geographical coordinates?  We could look at the
> proposed way, and try to understand it?
>
> Alex
>
>>
>> Cheers
>>
>> Carl
>>
>>
>> -----Original Message----- From: Dino Farinacci Sent: Wednesday,
>> January 08, 2014 11:33 AM To: Carl Reed Cc: Alexandru Petrescu ;
>> Georgios Karagiannis ; [e-mail] ;
>> <[e-mail]> Subject: Re: [geonet/its] challenges proposed by
>> Dimitri
>>
>> Yes, but in this case, you need some other value to determine
>> boundary. Because the center of your property can include me your
>> neighbor if you don't have that other boundary. So radius,
>> triangulation, or four sets of geo-coordinates are necessary.
>>
>> And I would argue some properties are not just hexagons, but
>> octigons or nonagons as well. Depends on the granularity you want
>> or need.
>>
>> Dino
>>
>> On Jan 8, 2014, at 8:23 AM, Carl Reed <[e-mail]>
>> wrote:
>>
>>> Alex -
>>>
>>> A very common practice in the land management community is to
>>> create a unique parcel identifier based on the coordinates of the
>>> centroid of the parcel. The approach generates a single PIN based
>>> on lat/long, which in the use case below reduces the number
>>> resolution mechanisms.
>>>
>>> http://www.hendersoncountync.org/ca/howpins.html
>>>
>>> Shows an example. They use state-plane but a similar approach
>>> could be used for lat/long coordinates.
>>>
>>> And you also raise the question of coordinate reference systems
>>> (CRS) and the requirements perhaps to transform between CRS (also
>>> known as re-projection). Regardless of the approach this group
>>> decides to follow, at a minimum the documentation needs to be
>>> very clear on the CRS of the coordinate(s) being used. Simply
>>> stating lat/long is unclear and can actually result in
>>> significant absolute location errors depending on the geoid used
>>> for a given lat/long pair. The existing location object (LO)
>>> definition used in PIDF and a number of other RFCs very clearly
>>> states the relevant EPSG code for the CRS being used. The
>>> approach for specifying a CRS is defined by ISO and the OGC in a
>>> variety of documents.
>>>
>>> The above may seem a trivial point, but ambiguity in the
>>> specification of the CRS for a coordinate set can lead to a
>>> number of issues in terms of visualization, analysis, fusion,
>>> analytics and so forth.
>>>
>>> Cheers
>>>
>>> Carl
>>>
>>>
>>> -----Original Message----- From: Alexandru Petrescu Sent:
>>> Wednesday, January 08, 2014 4:33 AM To: [e-mail] ;
>>>  [e-mail] Cc: [e-mail]
>>> Subject: Re: [geonet/its] challenges proposed by Dimitri
>>>
>>> Hi Georgios,
>>>
>>> You are asking for feedback.
>>>
>>> I have some thoughts on this.  Far from me any intention to
>>> complexify things.
>>>
>>> I will be happy to read others' remarks.
>>>
>>> Le 06/01/2014 11:21, [e-mail] a écrit :
>>>> Hi Dimitri,
>>>>
>>>> Thank you very much!
>>>>
>>>> The questions that you have listed below are very useful and
>>>> therefore I am forwarding your email to the its list!
>>>>
>>>> Actually, I agree with the challenges that you described and I
>>>>  will try to integrate them in what we have up to now:
>>>>
>>>> 1. How can a geographic area be “represented”, since several IP
>>>> locators can give access to it.
>>>
>>> An area could be represented by the coordinates of some of the
>>> points on its perimeter, or other description of point
>>> coordinates and shape identifier.  A volume description would
>>> have more possibilities.  One should also consider maybe the
>>> projection alternatives.
>>>
>>>> 2. which resolution mechanism can be used at the source node
>>>> e.g. Geo-locator (name)/ Geo-Physical coord.(addr.) to IP
>>>> locator
>>>
>>> Yes, resolution mechanism may be needed.
>>>
>>> But, we currently know two kinds of resolution: - IP address <->
>>>  MAC address (ND) - IP address <-> name (DNS)
>>>
>>> With geonet we'd talk new identifiers like geographical
>>> coordinates.  If we talked only one such coordinate (say
>>> 'latitude'), then we'd need 3 new resolution mechanisms: - IP
>>> address <-> latitude (protocol IPL) - MAC address <-> latitude
>>> (protocol MACL) - name <-> latitude (protocol NL).
>>>
>>> Maybe the latitude is not sufficient, so we'd need longitude and
>>>  altitude as well.  This would give a total of 9 new resolution
>>> protocols.
>>>
>>> On another hand, one may think of combining the lat/long/alt into
>>> a single identifier.  That may appear simple at first sight, but
>>> may have its own difficulties, one of which being the necessity
>>> of the representation of precision (HDOP, VDOP).
>>>
>>> Not to mention the difficulty of coming up with an agreed way of
>>>  representing one single geographical coordinate (it's not
>>> because everybody talks GPS now that someone will not talk
>>> Baidou tomorrow, as an example).  If I want to locate all the IP
>>> sensors of water level measurements where I live I am not able to
>>> use the GPS coordinates, I must use coordinates using the
>>> Lambert projection (just another example).
>>>
>>> Yes, I am told conversion tools exist (e.g. same GNSS chipset
>>> outputs both GPS and Galileo data, using an internal conversion).
>>> But then the question is whether we need conversion tools or
>>> resolution tools (protocols).
>>>
>>> Alex
>>>
>>>> 3. which resolution mechanism can be used at IP locator (or
>>>> edges) if packets would have to transit non IP islands e.g.
>>>> Geo-locator (name) to Geo-Physical coord.
>>>>
>>>> 4. what is the rate and size of the records populating the
>>>> resolution database
>>>>
>>>> 5. at which level of “stack” this information has to be
>>>> inserted such that intermediate nodes can successfully reach
>>>> the destination as expected by the source.
>>>>
>>>> Best regards,
>>>>
>>>> Georgios
>>>>
>>>> *From:*Papadimitriou, Dimitri (Dimitri)
>>>> [mailto:[e-mail]] *Sent:*
>>>> zaterdag 14 december 2013 23:56 *To:* Karagiannis, G. (EWI)
>>>> *Subject:* RE: the uncrisp problem
>>>>
>>>> Hello,
>>>>
>>>> Reading all the discussions, I wonder why there is no item
>>>> discussing the following points:
>>>>
>>>> At the network wide level
>>>>
>>>> - Geo-locators (naming the geographic area) vs Geo-physical
>>>> coordinates (the actual coordinates of that area)
>>>>
>>>> Have the same relationship as
>>>>
>>>> - IP network locators vs none (known as of today)
>>>>
>>>> Note however at the local level there is distinction between IP
>>>> address (logical) and e.g. MAC address (physical)
>>>>
>>>> Thus there is first a question 1. what a geographic area
>>>> “represents” because several IP locators can give access to
>>>> it.
>>>>
>>>> Then the “base” problem stems as follows
>>>>
>>>> 2. which resolution mechanism at the source node e.g.
>>>> Geo-locator (name)/ Geo-Physical coord.(addr.) to IP locator
>>>>
>>>> 3. which resolution mechanism at IP locator (or edges) if
>>>> packets would have to transit non IP islands e.g. Geo-locator
>>>> (name) to Geo-Physical coord.
>>>>
>>>> 4. what is the rate and size of the records populating the
>>>> resolution database
>>>>
>>>> 5. at which level of “stack” this information has to be
>>>> inserted such that intermediate nodes can successfully reach
>>>> the destination as expected by the source.
>>>>
>>>> Thanks,
>>>>
>>>> -dimitri.
>>>>
>>>>
>>>>
>>>> _______________________________________________ its mailing
>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/its
>>>>
>>>
>>>
>>> _______________________________________________ its mailing list
>>>  [e-mail] https://www.ietf.org/mailman/listinfo/its
>>> _______________________________________________ its mailing list
>>>  [e-mail] https://www.ietf.org/mailman/listinfo/its
>>
>>
>>
>
>
>
>