RE: [Geopriv] New Version Notificationfordraft-wolf-civicaddresses-austria-00

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Thu Nov 15 2007 - 16:41:17 EST

I hope I've given you something to think on. Keep in mind that my suggestions are only suggestions; this is something that probably wont affect me.

A few more inline, but I'll be frugal with bytes.

> -----Original Message-----
> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> Sent: Thursday, 15 November 2007 9:04 PM
> To: Thomson, Martin
> Cc: Winterbottom, James; GEOPRIV
> Subject: Re: [Geopriv] New Version Notificationfordraft-wolf-
> civicaddresses-austria-00
>
> Martin, thank you very much for your comments.
>
> > It's probably more useful for your readers if you described a simple set
> of rules that they can follow for a translation _to_ PIDF-LO. I'm not
> sure that it would be easy to reverse this process, but at least with a
> clearly defined translation process this might be possible. It's hard to
> follow how this might work from the draft (as my comments will show
> later).
>
> I know this draft currently does not provide the type of rules that
> would be needed. First we wanted to collect all the problems with
> Austrian addresses related to PIDF-LO and second discuss here how
> these problems can be resolved (new PIDF-LO elements, just map to
> existing elements). If we merge all the various house number parts
> into one PIDF-LO element, there might be troubles when trying to get
> back the original elements, since not every address makes use of the
> same set of elements.

Perhaps this is something to think on. I'd recommend an attempt, which would give us more to work on. That wouldn't stop you from discussing alternatives in early documents.

> > I recommend putting the corresponding PIDF-LO field in Tables 1 to 3
> where the choice is clear. It isn't easy to infer the translation from
> the tables to the list in Section 6.1. For instance, you say that "BLD"
> can be used directly, but I can't see how this could be directly filled
> from the tables. Is this derived from Part 2 of the House number? Or is
> this more complex?
>
> I thought BLD would be used to hold an informational name of a
> building. So I did not expect BLD to be filled from the data of
> Statistik Austria.

This applies generally, but the field can either contain informal, informational data, or it can contain formal data (such as the Statistik AT codes). You have this problem for more fields than this - maybe a way forward is to allow for two civicAddress elements, one with formal, code-based data and another with the informal, textual data.

> > Less clear mappings (like where you concatenate the hausnummer fields)
> could each have a section of text describing the mapping.
>
> > Having clear mappings would highlight problems as well. In Table 4 you
> state that "Hofname" doesn't have a PIDF-LO mapping, yet it is listed
> against "LMK" in Section 6.1.
>
> Thanks for that. I just noticed that with "Vulgoname" it's the same.
>
> > I was going to suggest that "NAM" would be appropriate, unless you
> consider it likely that both "Hofname" and "Vulgoname" coexist. That
> would leave "LOC" for advisory text such as "Gebaeudeunterscheidung"
> (hotel/kirche/etc...) and "Hausnummerntext" (vor/round the side/etc...).
> >
>
> But how do you know then if LOC in a particular case holds a
> "Gebauudeunterscheidung" or a "Hausnummerntext"? Besides,
> Gebauudeunterscheidung and Hausnummerntext can coexist.
>
> It is also possible to have both, a "Hofname" and a "Vulgoname".

Oh well.

> Moreover, there may be the demand for more than one "Vulgoname".

You should probably make a point of that somewhere (or did I miss it?).
>
> > "Hausnummernbereich" (all, even, odd) is an interesting field. We have
> a similar convention, but rely on the assumption that only odd or even
> numbers exist on the same side of the road (which means that some of the
> more recent numbering systems have an interesting constraint). I assume
> that it isn't possible to make a similar inference, but is there any
> danger in the field being omitted?
>
> I really don't know. normally there are just odd or even numbers on
> one side of the street. but at least I know of one real address with
> the house number 111-112 with the "Hausnummernbereich" all numbers of
> this range.
>
> > You might like to consider A6 for the commune name/identifier. The
> field exists for that purpose.
>
> do you mean the "Katastralgemeindename" (commune subdivision name)?
> And would you prefer to put the name and identifier to the same
> element or into separate fields?

It looks like you have this problem in a few places. c.f. earlier comment on identifier/name.

> > "Tuernummer" (door number) is a prime candidate for inclusion in the
> civic format. We have that concept here for some things (theatres and
> concert venues rely on door numbers for managing large numbers of
> patrons), but it could also be useful for emergency responders.
> >
> > I think that "Topnummer" is "UNIT"; unless "hausnummer - Teil 3" is also
> unit.
>
> housenumber part 3 has nothing to do with the unit, this house number
> part may be necessary to identify a building. Inside a building, an
> apartment may have a "Topnummer" or a "Tuernummer". "Topnummer" and
> "Tuernummer" are not uniformly used, but have quite the same meaning.

OK, so could they both be put in the UNIT field?

> > "Lage" can be combined into "FLR" (define a delimiter and you can get it
> back out as necessary as well).
> >
> > Your use of "ADDCODE" is good - these sorts of codes are exactly how it
> was intended to be used.
> >
> > I don't like Section 7. This appears to be location by value in a URN.
> What do you see this being used for?
>
> this is an additional idea of address code usage. The code is the key
> to the address information. No need to worry about house number parts
> in PIDF-LO. Probably such URNs can be used in the SIP Geolocation
> header?
>
> >
> > Nit: You need to put xml:lang="de" or xml:lang="de-AT" in the example
> somewhere.
>
> ok.
>
>
> cheers
> karl heinz
>
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 15 Nov 2007 15:41:17 -0600

This archive was generated by hypermail 2.1.8 : Thu Nov 15 2007 - 16:41:34 EST