Subject: [Geopriv] New Version Notification for draft-wolf-civicaddresses-austria-00

From: "Karl Heinz Wolf" <[email-masked]>
Date: Fri, 9 Nov 2007 10:11:13 +0100

we just submitted a draft for Civic Address Considerations for Austria:
http://www.ietf.org/internet-drafts/draft-wolf-civicaddresses-austria-00.txt

Comments and feedback appreciated.

Karl Heinz

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Friday, November 09, 2007 10:00 AM
To: Alexander Mayrhofer
Cc: Karl Heinz Wolf
Subject: New Version Notification for draft-wolf-civicaddresses-austria-00

A new version of I-D, draft-wolf-civicaddresses-austria-00.txt has
been successfuly submitted by Alexander Mayrhofer and posted to the
IETF repository.

Filename:	 draft-wolf-civicaddresses-austria
Revision:	 00
Title:		 Civic Address Considerations for Austria
Creation_date:	 2007-11-09
WG ID:		 Independent Submission
Number_of_pages: 18

Abstract:
Providing civic address considerations for individual countries is
proposed in RFC4119.  This documents provides such considerations for
Austria, and proposes a mapping of Austrian address elements to the
PIDF Location Object (PIDF-LO).

The IETF Secretariat.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 9 Nov 2007 03:46:43 -0600

Hi Karl Heinz,

This is an interesting document to be sure and shows some very good
thought patterns on how to use this information in a national context.
Thanks. The content is probably something that you need your national
regulators to approve however, rather than the IETF.

Looking at the recommendation it seems that you are using <A6> to
indicate the road or street name. If you are using the revised civic
specification as you suggest, then you should be using the <RD> element
for this.

Cheers
James

> From: Karl Heinz Wolf [mailto:[email-masked]]
> Sent: Friday, 9 November 2007 8:11 PM
> To: GEOPRIV
> Subject: [Geopriv] New Version Notification
fordraft-wolf-civicaddresses-
> austria-00

------------------------------------------------------------------------------------------------
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]

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 09 Nov 2007 10:51:51 +0100

Hi James,

I am not sure that a regulator is the right consumer for this document.

To some extend this relates to the discussion with had at the workshop 
with Jim Price where he said that there are so many fields in the 
PIDF-LO civic information and most of them are not needed in certain 
countries. We argued that specific regions would only use certain fields.

Someone needs to describe the best current practice in each country on 
how the locally used civic addresses are mapped to the PIDF-LO civic 
elements.
I wonder where one should publish such documents so that they can easily 
be found.

Ciao
Hannes

Winterbottom, James wrote:
>> we just submitted a draft for Civic Address Considerations for
>>     
> Austria:
>   
>> Subject: New Version Notification for
>>     
> draft-wolf-civicaddresses-austria-00
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 9 Nov 2007 03:56:15 -0600

Hi Hannes,

Yes and no.
I think that the regulators do need to specify how locations are to
expressed within their jurisdictions in order to ensure that they are
populated in a consistent manner. These may be done within national
standards such as ANSI in the US, or they simply be decrees from on
high, but they need to adopted by organizations with the clout to make
them happen.

I agree with you that this is very valuable work, and I praise Karl
Heinz for taking the initiative to be the first to do it. I also agree
that having a central place where all this information can be obtained
is a good idea. I would go one step further and say having a common
format is good.. *8)

Cheers
James

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, 9 November 2007 8:52 PM
> To: Winterbottom, James
> Cc: Karl Heinz Wolf; GEOPRIV
> Subject: Re: [Geopriv] New Version Notification fordraft-wolf-
> civicaddresses-austria-00
> 
> Hi James,
> 
http://www.ietf.org/internet-drafts/draft-wolf-civicaddresses-austria-
> >> 00.txt
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 12 Nov 2007 08:29:27 +0100

Hi James!

> specification as you suggest, then you should be using the <RD> element

my mistake. thanks for that.

karl heinz

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Nov 2007 21:18:38 -0600

This sort of document is quite valuable, and not just to Austrians working out how to use PIDF-LO.  It also helps highlight limitations in the format.

You highlight the fields that don't have a direct mapping, and perhaps you need better directions on what to do with them.  It seems that from the wealth of hausnummer fields that house numbering is more complex in Austria than PIDF-LO can accommodate.

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 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?

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.

Other random comments:

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...).

"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?

You might like to consider A6 for the commune name/identifier.  The field exists for that purpose.

"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.

"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?

Nit:  You need to put xml:lang="de" or xml:lang="de-AT" in the example somewhere.

Cheers,
Martin

> Sent: Monday, 12 November 2007 6:29 PM
> To: Winterbottom, James
> Cc: GEOPRIV
> Subject: Re: [Geopriv] New Version Notificationfordraft-wolf-

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 15 Nov 2007 11:04:19 +0100

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, b…

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.

> 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, yo…

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.

> 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 "Gebaeudeuntersc…

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".
Moreover, there may be the demand for more than one "Vulgoname".

> "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 mean…

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?

> 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.

> 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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 15 Nov 2007 15:41:17 -0600

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.

> Sent: Thursday, 15 November 2007 9:04 PM
> To: Thomson, Martin
> Cc: Winterbottom, James; GEOPRIV
> > 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).
> 

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?
> 

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.
> 
> > 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...).
> >
> 

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?
> 

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.
> >

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