Subject: [Ecrit] Service area format standards

From: Haberler Michael <[email-masked]>
Date: Mon, 22 Jan 2007 22:13:19 +0100

I am looking for references to standards, format descriptions or  
examples for PSAP service areas.

background:

Reporting service areas in a machine-readable format will be required  
by the regulator starting July 2007 for Austria, both from ESO's (as  
they want it) and by the network operators (as they actually do it).

We are engaging in a data collection effort in Austria to collate the  
status quo since this will be the input to the LoST database.

There is no "standard" in use (nobody asked for this so far) and we  
do expect a hodgepodge of different formats. So the first task might  
well be to moderate the process on the delivery format. We'd of  
course like them to deliver polygons plus attributes. I would assume  
that such data has been/is currently collected elsewhere and I rather  
go into the process with a reference to something in use rather than  
invent our own.

thanks for any pointers

-Michael

sorry if this might be a bit OT for this list, but I would assume  
people in the know are cued in.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Jan 2007 16:03:15 +0100

Hi Michael,

> they want it) and by the network operators (as they actually do it).
That's very good. Service boundaries should be public in every country.

> There is no "standard" in use (nobody asked for this so far) and we do 
> expect a hodgepodge of different formats. So the first task might well 
> be to moderate the process on the delivery format. We'd of course like 
> them to deliver polygons plus attributes. I would assume that such 
> data has been/is currently collected elsewhere and I rather go into 
> the process with a reference to something in use rather than invent 
> our own.

Ideally, it would be good to have the collected data in the same format 
as described in Section 11 (Location Profiles) of
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt

Since most of the PSAP boundary data is not available to the public I 
suspect that the formats vary substantially.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Jan 2007 10:54:00 -0500

The ones I have seen are in ESRI shape files or similar semi-standard  
GIS formats. A common exchange format would be a good thing - maybe  
something for NENA to take on.

> Since most of the PSAP boundary data is not available to the public  
> I suspect that the formats vary substantially.
>
> Ciao
> Hannes
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 24 Jan 2007 16:44:33 -0600

In NENA we are defining a file format based around the geoshapes polygon
and the revised civic format as part of the i2.5 initiative. Henning, I
would need to have another look at your forest guide interchange format
but I suspect that it is not that different.

Cheers
James

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 25 January 2007 2:54 AM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] Service area format standards
> 

------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Jan 2007 19:36:16 -0500

It would be nice to actually work on aligning them by more than  
coincidence, so that no lossy transformation is necessary (and  
preferably no transformation beyond just XML wrapping.)

As you know, LoST and the <mapping> element are likely to get frozen  
very soon, so there isn't a whole lot of time.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 24 Jan 2007 20:41:24 -0500

Is the "geoshapes polygon" somehow different than the GML polygon?

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 24 Jan 2007 20:06:21 -0600

Nope

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, 25 January 2007 12:41 PM
> To: Winterbottom, James
> Cc: Henning Schulzrinne; Hannes Tschofenig; ECRIT
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> >
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 24 Jan 2007 21:54:19 -0500

Indeed, the most common way to do this is a "shape file" which is ESRI
specific, but most other GIS systems have translators.  It is the defacto
standard.  Recently, there have been discussions in NENA and elsewhere about
changing this to be a GML based format.  Mark Berryman would have more info.

Perhaps we can let them complete this work and then adopt it, but I see this
question as addressing a small part of a larger problem of provisioning the
LoST database.  We probably need to get into an extended discussion of that,
which might begin with a discussion of whether we want to standardize a
provisioning interface at this time at all.

It does seem to me that we don't know enough yet about how one wants to do
this.  For example, it is possible to construct a LoST server from a GIS
system and not have any form of tabular data at all.   In effect, for a
civic query, you geocode it, and then do a boundary check against a set of
polygons.  Another way to construct the server is a have a hybrid of a set
of polygons used for geo queries and a table based civic query that mirrors
some existing databases.  So, then we get to ask if the provisioning
interface needs to accommodate both models or not. 

I'm inclined to let this area go without IETF attention for a while.  LoST
authoritative servers are local in nature.  It would be reasonable to, for
example, let NENA work on provisioning interfaces for North America.  After
we have some experience, we could revisit and see if having more global
standards is useful.

Brian

> Sent: Wednesday, January 24, 2007 10:54 AM
> To: Hannes Tschofenig
> Cc: ECRIT

---

From: Haberler Michael <[email-masked]>
Date: Thu, 25 Jan 2007 09:31:15 +0100

> preferably no transformation beyond just XML wrapping.)

that is in fact a key question, but I dont think it relates to the  
LoST shapes directly, at least how I envisage the process. Let me  
outline y current belief system...

The relevant data will come from at least ten different sources (9  
counties and state) in Austria, all with their GIS department or  
consultant on the side. We envisage that this data is collected,  
loaded into a single reference register, and this is the point where  
topological integrity is checked (I dont see these folks directly  
"provisioning" into the LoST database, I think a fail-stop process  
before that is needed). That would catch cases of overlap or non- 
coverage, or missing areas for a specific emergency call type (here  
this would be not just 911 but split into general emergency (112) and  
at least fire brigade, police and ambulance).

The "delegation process" works as follows here:
Emergency short codes are allocated by the regulator to either  
provinces or in case of police and 112 the ministery of interior  
affairs, defining resonsibility for that short code for a  
administrative region (example - 122 (fire) - allocated to province  
government of lower Austria). This allocation carries an obligation  
to publish the "desired routing" within that admin region (but see  
below). However, there was no format or indeed any requirements  
attached to that obligation.

In terms of what is needed wrt the data format to enable such checks  
I came to the following requirements:
(1) each entity needs to publish an overall "service area", against  
which the individual "service regions" can be checked. This service  
area would not be needed in the LoST server proper but it is needed  
for integrity.
(2) all individual service regions must be fully contained (no  
overlap) in this service area.
(3) the sum of service regions must cover all of the service area.
(4) service areas shall not overlap and together fully cover the  
"national service area".
(5) there should be an audit trail from each submitted region through  
the reference register into the LoST database polygon, AND BACK.

These requirements arent LoST requirements, they are requirements on  
the data collection process (except for the traceback suggestion below).

The "service area" would correspond to the area of responsibility for  
a region - typically a province or the state of Austria. However,  
there might be  exceptions for that: there's at least one case where  
neighbouring provinces agreed to move service areas outside the  
province boundaries (in this case to arrange for responsibility of a  
mountain tunnel between two provinces fully to one county even if the  
province boundary is somewhere in the middle of the tunnel). I think  
such exceptions are possible at the national level as well. So that's  
why just referring to a standard shape "Province of XX" is not  
sufficient, although in many cases it will coincide.

The "service region" of a specific service would be a polygon within  
a service area with responsibility for that service pegged to (and  
routed to) a single PSAP operator. That would be typically a county  
or commune for larger cities, but provinces might choose to just have  
a single service region within their service area as is the case in a  
single PSAP for a province.

These objects would be part of the refernce data set submitted to the  
reference register. There would be over time re-submissions because  
of  changes to this data sets. After submission integrity checks are  
performed and errors resolved between submitting entity and register  
operator. Thereafter the corrected data set is entered into the  
reference register, resulting in changes to the LoST database. There  
would be no transformation or data change between reference register  
and LoST server. That "forward process" would be easily trackable  
(logs, transaction numbers..).

Beyond that I think it would be very helpful to easily trace *back*  
each polygon in the LoST server back to a particular data set  
submission of a particular entity. That suggests that each data set  
submission is tagged with a few parameters, like: responsible  
organisation (e.g. province), created-by (e.g. GIS department, GIS  
consultant..), validity periods and a sequence number. Each object  
would have a tag pointing to a particular submission. I'd suggest add  
a backtrackURI to the serviceBoundary object to ease the backtrack  
process. Note this points "out of LoST space" - it's not for syncing  
between servers or referring to a particular service boundary object  
within the LoST server - it refers to the data source and its history.

Semantics in the context of the LoST response would be: "I tell you  
for this location the following PSAP is responsible, and this is  
because of the information <URI pointing to dataset submission  
here>". If the question ever comes up why a LoST server actually gave  
a particular answer, that would enable easy tracking to the source of  
the data. A simple idea: it's a HTTP URI pointing to an application  
ontop of the reference register, displaying the data set and its  
origin, and maybe a map of the object.

sorry if this is considered OT and I'm really treading thin air here  
for lack of references.

-Michael

>
> As you know, LoST and the <mapping> element are likely to get  
> frozen very soon, so there isn't a whole lot of time.
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Jan 2007 09:31:51 -0500

Michael,

I think you have actually outlined some good requirements.  And there  
seems to be a lot of dovetailing into Henning's synchronization work  
and the whole concept of location profiles in LoST.

Contrary to Brian's statement, I do think the IETF and ECRIT should  
take this on.  First, there seems to be a lot of coordination that  
needs to go on (as I noted above).  Second, NENA is not the right  
venue as it is U.S. centric.  Such a standard would be used in many  
other places.

-andy

On Jan 25, 2007, at 3:31 AM, Haberler Michael wrote:

> loaded into a single reference register, and this is the point  
> where topological integrity is checked (I dont see these folks  
> directly "provisioning" into the LoST database, I think a fail-stop  
> process before that is needed). That would catch cases of overlap  
> or non-coverage, or missing areas for a specific emergency call  
> type (here this would be not just 911 but split into general  
> emergency (112) and at least fire brigade, police and ambulance).
>
> In terms of what is needed wrt the data format to enable such  
> checks I came to the following requirements:
> (5) there should be an audit trail from each submitted region  
> through the reference register into the LoST database polygon, AND  
> BACK.
>
> These requirements arent LoST requirements, they are requirements  
> on the data collection process (except for the traceback suggestion  
> below).
>
> The "service area" would correspond to the area of responsibility  
> for a region - typically a province or the state of Austria.  
> However, there might be  exceptions for that: there's at least one  
> case where neighbouring provinces agreed to move service areas  
> outside the province boundaries (in this case to arrange for  
> responsibility of a mountain tunnel between two provinces fully to  
> one county even if the province boundary is somewhere in the middle  
> of the tunnel). I think such exceptions are possible at the  
> national level as well. So that's why just referring to a standard  
> shape "Province of XX" is not sufficient, although in many cases it  
> will coincide.
>
> The "service region" of a specific service would be a polygon  
> within a service area with responsibility for that service pegged  
> to (and routed to) a single PSAP operator. That would be typically  
> a county or commune for larger cities, but provinces might choose  
> to just have a single service region within their service area as  
> is the case in a single PSAP for a province.
>
> These objects would be part of the refernce data set submitted to  
> the reference register. There would be over time re-submissions  
> because of  changes to this data sets. After submission integrity  
> checks are performed and errors resolved between submitting entity  
> and register operator. Thereafter the corrected data set is entered  
> into the reference register, resulting in changes to the LoST  
> database. There would be no transformation or data change between  
> reference register and LoST server. That "forward process" would be  
> easily trackable (logs, transaction numbers..).
>
> would have a tag pointing to a particular submission. I'd suggest  
> add a backtrackURI to the serviceBoundary object to ease the  
> backtrack process. Note this points "out of LoST space" - it's not  
> for syncing between servers or referring to a particular service  
> boundary object within the LoST server - it refers to the data  
> source and its history.
>
> here>". If the question ever comes up why a LoST server actually  
> gave a particular answer, that would enable easy tracking to the  
> source of the data. A simple idea: it's a HTTP URI pointing to an  
> application ontop of the reference register, displaying the data  
> set and its origin, and maybe a map of the object.
>
> sorry if this is considered OT and I'm really treading thin air  
> here for lack of references.
>
> -Michael
>
>
>
>>

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 25 Jan 2007 06:57:53 -0800

>On Wednesday, January 24, 2007 6:54 PM, Brian Rosen wrote:

>I'm inclined to let this area go without IETF attention for a 
>while.  LoST authoritative servers are local in nature.  It 
>would be reasonable to, for example, let NENA work on 
>provisioning interfaces for North America.  After we have some 
>experience, we could revisit and see if having more global 
>standards is useful.

I agree with Brian on this.  This is already an area of interest within
NENA, which will likely have some development work start in the (fairly)
near future.

Roger Marshall.

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 25 Jan 2007 10:10:44 -0500

The thing is that the complexity of the data varies all over the map, with
the U.S. (and Canada) generally considered as having the most complex data.
U.S. data will be loaded on U.S. LoST servers.  Having some regional
variation on the provisioning side doesn't strike me as a very large
problem, at least for now.  Eventually, when we understand how we actually
build and use these databases, standardizing the provisioning might be
useful.

The thing to keep in mind is that while a vendor of LoST servers would
probably like a standardized provisioning interface, the users don't really
care, because they only ever use ONE.  They probably want to specify it to
match their existing systems and practice.

Brian

> Sent: Thursday, January 25, 2007 9:32 AM
> To: Haberler Michael
> Cc: ECRIT

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Jan 2007 10:39:00 -0500

> build and use these databases, standardizing the provisioning might be

Again, this is a very U.S. centric view.  I'll agree the U.S. seems  
to have a higher quantity of service boundaries, but the complexity  
of the service boundaries themselves are not specific to the U.S.   
There are certainly countries with more complex civic addresses, and  
there is nothing special about the terrestrial makeup of America nor  
the sky above it that requires the U.S. to have geodetic shapes more  
complex than anyplace else.  As James pointed out, they are using GML  
polygons and GEOPRIV revised-civic.  Just what is U.S. specific about  
that?

> match their existing systems and practice.

Given all the arguments regarding the need for a standard to  
synchronize authoritative LoST servers and forrest guides, I'm  
perplexed why you think the same does not carry over to the  
provisioning.  After all, it is much like the CD-ROM form of wire  
synchronization.  It would certainly be beneficial if an Austrian  
PSAP could purchase software built by an American vendor (or vice- 
versa) and expect compatibility.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Jan 2007 10:49:27 -0500

This is not quite true. The forest guides need to have a uniform  
interface and data format, as they are international.

Also, as for DNS, we want replication, preferably across different  
vendors (to avoid a single vulnerability taking down the whole  
system, say).

I'm also a bit lost by the "complexity varies all over the map". Are  
they using shapes other than polygons?  Frankly, I'm not convinced  
that this is rocket science and that we need to make this terribly  
complicated.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Jan 2007 10:55:30 -0500

As a somewhat related example, it has been extremely useful to have a  
single "provisioning" interface for DNS servers, zone files, even  
though there are other, proprietary database backends that might be  
more efficient. The same is true for LDAP (LDIF).

I agree with Andrew; putting up "this is really, really complicated  
and mere mortals can't understand it, only special wizards that have  
at least a NEWT" doesn't seem all that helpful.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 25 Jan 2007 11:14:54 -0500

I agree that the forest guides need a standard interface and data format.  I
don't think of that as the same as provisioning the LoST data itself.  Agree
that we want replication, but I don't think the provisioning interface
matters for that (what I want is automatic replication, and I think there
are operations defined in LoST to facilitate that, understanding that the
actual data sent in the "zone transfer equivalent" has the issues we are
talking about).

The complexity DOES vary all over the place because of the level of detail
in the civic data.  In most countries, there is very little detail (if you
know the city name, you know the PSAP.  In some countries it's more coarse
than that).  In the U.S., you have to know the number on the street to
determine the PSAP, and you better match the street name, pre/post
directional, prefix, suffix, etc.

If you are hot to do an IETF standardized provisioning interface, let's
start with how you define street addresses.  Since I advocate doing this as
a GIS system, and not as tabular data, I want a GIS layer with street
centerlines, an option for actual streets (correct placement and width), a
layer for (at least) street addresses as point plots, options for parcels.
For both points and parcels there are some provisioned settings that deal
with edge cases.  For example, in some jurisdictions, there is an algorithm
for house numbers (go up by 1 every 50 feet for example), and they want to
allow addresses that aren't actually provided as points on the centerline
data to be valid using the algorithm.  I'm not really up on how they do the
equivalent for Japanese and Chinese addresses; it's more complex in some
ways.

The actual boundaries for each service is a set of polygons (and it is a
set, not just one), which we can probably get a simple GML spec for pretty
easily.

Bring out your GIS experts, we have a lot to learn before we specify this.

Brian

> Sent: Thursday, January 25, 2007 10:49 AM
> To: Brian Rosen
> Cc: 'Andrew Newton'; 'Haberler Michael'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Jan 2007 11:23:51 -0500

We are talking about service boundaries here, not geocoding software.  
Thus, I don't see the need for more than an enumeration of civic  
street-level addresses (which presumably fit into the PIDF-LO mold or  
else we have other problems) and polygons describing the area. The  
former is necessary for civic address validation, the latter for  
boundary matching.

I don't see why I would care about parcel boundaries unless I do  
geocoding of some sort.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 25 Jan 2007 11:36:29 -0500

I'll just toss my limited knowledge of Japanese civic addresses into the 
pot: street addresses are in random order as far as an outsider is 
concerned. You find your way to a particular address by asking or by 
finding the neighbourhood map. I suppose serving areas are defined by 
neighbourhood rather than street address, because of this.

The point being that provisioning and validation procedures may well be 
country-specific.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Jan 2007 11:40:33 -0500

True, but I'm not sure this is particularly relevant here. An  
enumeration of each street address would allow full validation  
(unlike the even/odd/range validation today) and easily accommodate  
random assignment of house numbers to service areas. This is why the  
most recent version of the LoST draft allows multiple civic addresses  
as part of the service boundary.

On Jan 25, 2007, at 11:36 AM, Tom-PT Taylor wrote:

> I'll just toss my limited knowledge of Japanese civic addresses  
> into the pot: street addresses are in random order as far as an  
> outsider is concerned. You find your way to a particular address by  
> asking or by finding the neighbourhood map. I suppose serving areas  
> are defined by neighbourhood rather than street address, because of  
> this.
>
> The point being that provisioning and validation procedures may  
> well be country-specific.
>

With the generalization noted above, the mechanism can be generic.

Hennin

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 25 Jan 2007 11:53:16 -0500

What good would it do to standardize the service boundary provisioning
without standardizing the civic address data provisioning?  If you want to
do that and stop there, then I'm more amenable, because indeed with just
that, there is more agreement on what is needed.

Yes, I think if you have accurate data, which a PSAP can have, then you can
geocode to route a civic address.  This only works if the geocode data is
accurate, and any conversions are done with the same data.  That can be the
case here.  By using geocoding, you eliminate the issue of defining how you
determine the service boundaries in civic form.  This is the direction we
are heading in NENA, and it's the general direction for all of these kinds
of operations.  Geocode the civic, and use polygon boundaries.  You really
need parcel data to do this well, but they usually can choose the points
that represent the parcels well enough to make the polygons very accurate.

"Enumeration" of civic addresses is the geocode data for those addresses.

Now if you don't use geocoding for civic addresses, then you are back to
only having a solution for provisioning service boundaries for geo
locations: you can't use the polygons to determine service boundaries for
civic addresses without geocoding.

You could enumerate civic addresses and tag each address with the services.
That is what you would do if you stuck to tabular entry of civic.  I think
we should allow such a mechanism, but I want the geocode option, because
it's the way these things are evolving towards.  The problem with that
mechanism is that it makes the likelihood of a discrepancy in the service
boundaries between the geo and the civic higher, and requires a much more
complex data maintenance process to avoid such problems.

Brian

> Sent: Thursday, January 25, 2007 11:24 AM
> To: Brian Rosen

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Jan 2007 17:54:21 +0100

The process might be country specific.

The the format of the collected data could be standardized to simplify 
the provisioning of the LoST database.

Currently, you have to go through different data conversion steps and 
you might reduce the quality of the previously collected data.

Ciao
Hannes

Tom-PT Taylor wrote:
> I'll just toss my limited knowledge of Japanese civic addresses into 
> the pot: street addresses are in random order as far as an outsider is 
> The point being that provisioning and validation procedures may well 
> be country-specific.
>
>> We are talking about service boundaries here, not geocoding 
>> software.  Thus, I don't see the need for more than an enumeration of 
>> civic  street-level addresses (which presumably fit into the PIDF-LO 
>> mold or  else we have other problems) and polygons describing the 
>> area. The  former is necessary for civic address validation, the 
>> latter for  boundary matching.
>>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Jan 2007 12:41:57 -0500

On Jan 25, 2007, at 11:54 AM, Hannes Tschofenig wrote:

> The the format of the collected data could be standardized to  
> simplify the provisioning of the LoST database.
>
> Currently, you have to go through different data conversion steps  
> and you might reduce the quality of the previously collected data.

Yes.  From Michael's email, I think the process of using short codes,  
etc... sounds pretty specific to Austria.  However, none of the  
things he mentioned that are needed in the provisioning format are  
specific to Austria and they all sound like general meta data that  
nearly every country would use or the service boundaries we have  
already defined.

So I'm at a loss to know what it is they do that are mystical,  
magical incantations that cannot be shared with the rest of us.  At  
the very least, they should be able to clearly spell out what it is  
that makes their approach unique and special.  I have not seen that.

-andy