>...
> Regarding your point about that Civic address elements adding
> information but does not change information.
>
> >> I agree.
>
> However, I can't agree that removing elements is safe.
Removing elements is safe. It has to be. If you create an extension (say pole number or number prefixes) then you must be able to remove the extension, because some implementations wont understand it.
> What happens if you remove the building name from Civic and leave floor
> name. The floor name is not unique without the building name. Therefore
> there is inherent structure in the civic address that must be provided
> if systems need to interoperate using floor names.
Sure, it reduced the usefulness of the location information - it now might be any of a number of different buildings - but it has only increased the region of uncertainty, not moved it.
This might be inadequate for the application in mind, but it hasn't prevented interoperability.
The worst that can happen when an application doesn't support an element is a known ambiguity.
Say someone didn't understand a house number prefix (Brian's new work). Say that element was necessary to distinguish between a-14 and b-14 Smith St. If the application doesn't understand the prefix, it sees HNO=14, which potentially identifies two houses. Now it's uncertain about which house the location refers to, but it hasn't mistakenly picked number 16.
> The Stanley-geopriv-indoor-location uses the same semantics to define a
> fully qualified indoor location where it adds additional parameters to
> the civic address in a structured way to define a position in a floor.
> Without building or floor, the indoor location is meaningless.
But there's a difference between meaningless (or useless) and misleading. Stanley-geopriv-indoor-location allows for the latter.
> So I disagree with your explanation shows that indoor location is not
> compatible with the definition of civic addresses. If you talk to any
> indoor location vendor today they all use a building based reference
> location system (campus->building->floor->etc.) where the position on
> the floor is an extension of the building based model. Many companies
> have done this because it is a "natural" fit.
We disagree. It is certainly not "natural", whatever that means. I can appreciate how it might have been convenient or expedient. Those are often the opposite of correct.
> Again, the Stanley-geopriv-indoor-location proposal does not preclude
> your proposal of using geospatial information for indoor going forward.
> That is one of the fundamental differences between yours and the
> stanley
> draft. And that is why the original recommendation was to continue both
> drafts.
You'll have to explain that. Because I don't see how that might work.
Please, let's try to create one solution for this. Two solutions is an unnecessary burden on implementations.
--Martin
> allan
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Tuesday, November 24, 2009 8:50 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Why draft-stanley-geopriv-indoor-location will
> notinteroperate
>
> draft-stanley-geopriv-indoor-location will not interoperate.
>
> I presented the same explanation in response to
> draft-linsner-geopriv-relativeloc; the two proposals are identical in
> this regard, as they are in many other aspects.
>
> --
> Existing civic definitions RFC 4776/5139 follow a simple rule:
>
> The location described by a set of civic address elements is entirely
> contained within the location described by any subset of those
> elements.
>
> Or, from a different angle:
>
> Every civic address element adds information, it does not change
> existing information.
>
> This rule is what makes the civic address definition extensible. This
> rule ensures that elements can be safely ignored by processors that do
> not support them. Applications can even choose to support a subset of
> the civic address elements safely.
>
> For instance, an application that is designed solely for use within
> Austria is able to ignore the STS element. For addresses outside of
> Austria that use STS, the application wont perform well, but at least
> it
> wont break.
>
> It also means that removing elements is safe: it might degrade the
> location but it does not fundamentally change it.
>
> draft-ietf-geopriv-policy relies on this property for its privacy
> transformation. Geocoders rely on this property - they only support a
> subset of the fields. No application can know all possible civic
> address elements (especially if we accept Brian's arbitrary INT
> containers); therefore, all applications necessarily rely on this
> property.
>
> All the extension proposals we've seen so far respect this rule, except
> draft-linsner-geopriv-relativeloc and
> draft-stanley-geopriv-indoor-location. These proposals introduce
> elements that break this cardinal rule. An application that does not
> understand the extension can be mislead if it ignores the offset
> values.
>
> --
> This really only hints at a bigger issue with draft-stanley-... in that
> it incorrectly assumes that this data forms a civic address. Indoor
> location data is a new form of location information, it is not a "small
> expansion of the definition of a civic address". In many respects,
> indoor locations more closely resemble geodetic data.
>
> In any case, it should be clear from my explanation that this extension
> is not compatible with the definition of civic addresses.
>
> --Martin
> _______________________________________________
> 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
