Re: [Talk-us] San Diego Address Import Update

[Nathan Mills]

This is how I have always used addr:city. It reflects the postal address since 
it is a property of the address and not the parcel itself. People once used the 
is_in tag to capture the other meaning, but it seems unnecessary to me since 
one can simply check for an enclosing admin boundary.

On November 10, 2015 10:48:20 AM EST, Tod Fitch  wrote:
>

>So what is a good definition for what should go in the addr:city tag?
>If it is based on being within a formal administrative boundary then we
>may not need the tag at all as it should be easy for a data consumer to
>detect that. I have come to the conclusion that the addr:city is best
>to indicate what the locals feel their town name is. In the western US
>my impression is that has a high correlation with the USPS designation.
>Further, when dealing with any financial or government entity, it seems
>the city they want to hear about is the one the post office delivers
>to, not some subset or superset defined by a formal boundary of an
>incorporated town or city. So equating the post office town name with
>the OSM addr:city value seems proper to me.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] San Diego Address Import Update

[Richard Welty]

On 11/10/15 11:09 AM, Clifford Snow wrote:
>
> On Tue, Nov 10, 2015 at 7:48 AM, Tod Fitch  > wrote:
>
> So what is a good definition for what should go in the addr:city
> tag? If it is based on being within a formal administrative
> boundary then we may not need the tag at all as it should be easy
> for a data consumer to detect that. I have come to the conclusion
> that the addr:city is best to indicate what the locals feel their
> town name is. In the western US my impression is that has a high
> correlation with the USPS designation. Further, when dealing with
> any financial or government entity, it seems the city they want to
> hear about is the one the post office delivers to, not some subset
> or superset defined by a formal boundary of an incorporated town
> or city. So equating the post office town name with the OSM
> addr:city value seems proper to me.
>
>
> +1
>
the real problem is that the tagging scheme we are using didn't consider
the divergence between postal and administrative city names and is
insufficiently
rich to express the details.

it'd be good to consider what the actual use cases are for the data. the
most obvious
one is geocoding, and a case can be made that geocoders based on both
types of city
names are useful.

i can also imagine querying OSM for the data for other GIS style
purposes and wanting
either type.

at the present time, we can derive admin city from admin boundaries if
they are present.
if we discard the postal city name, though, we can't derive it from any
thing else in OSM,
as there are no postal boundaries that function like city admin
boundaries. you can sort
of fake it using census bureau ZCTA boundaries, but the mapping from
ZCTA to city is
missing and it would take a bit of work to put that together.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] San Diego Address Import Update

[Tod Fitch]

> On Nov 10, 2015, at 5:59 AM, Greg Troxel  wrote:
> 
> 
> Tod Fitch  writes:
> 
>> What is a “city” in US specific OSM terms?
>> 
>> I prefer a postal city definition as that is the most useful for
>> routing purposes which I feel is the primary use of address data in
>> OSM. Or are we dealing with some other concept of addr:city?
> 
> I see it as fairly clear that addr:city is about administrative
> boundaries and what the local civil government considers to be legal
> physical addresses (vs mailing addresses).
> 
> In Massachusetts this is very clear; every bit of land is in a city or
> town, and there are (mostly) granite markers at the corners.
> 
> In states with unincorporated areas, it seems like there are areas with
> cities, and then areas beyond the city where some rules apply, and then
> areas that are in a county but not really in a city, so I can see that
> this is complicated.
> 
> It would be interesting to ask the assessors or the police/fire
> department or PSAP operators how they see addresses and cities in these
> areas.
> 
> I would suggest that if we want to tag postal addresses vs legal
> addresses that those have tags that are explicitly about postal.

This is getting away from San Diego address import updates, but I think this is 
a topic that needs to be clarified. What is a city for the purposes of 
addr:city tag values in the US in the OSM database?

For what it is worth, in California (at least in the counties I have lived in) 
the legal description of a piece of land is a designation of the map book, page 
and parcel number in the county records. I believe the street name and number 
as well as the city name and ZIP code on the parcel can change over time and it 
does not change the legal description. So if addr:street, addr:housenumber, 
addr:city, etc. are not set to the legal description what should they be set to?

Here are some places that I am pretty familiar with having either lived in them 
or with extended visits to family who live in them.

First, Tucson, AZ. Tucson is an incorporated city with legally defined 
boundaries. When I lived there (many years ago) we didn’t actually live within 
the city limits but in a residential subdivision between the city and the 
mountains to the north. The “city” used in the address for all those years was 
always “Tucson” even though we were never within the incorporated city limits 
and civil administration was through the county. There were no other 
incorporated cities or towns near by, so if Tucson was not an option for city 
name then the only logical choice would be an empty or blank. Nobody ever left 
the city portion of an address field blank when filling out forms, “Tucson” was 
always used but it fails the administrative boundary test.

Second, Oracle, AZ. This town has existed for over 100 years but is not 
incorporated and, near as I can tell, has no official boundaries. There is a 
CDP for it but the boundaries on that do not seem to match what the locals 
consider the town. It has a volunteer run library, a volunteer fire department, 
a post office, a county administration office including court facilities and a 
sheriff’s substation. All with “Oracle” in their names and when you call 911, 
the PSAP wants to know that you are “in” Oracle (no enhanced 911 in the area 
yet). So it passes the “duck test” for a town. But it has no administrative 
boundaries and no concrete or granite boundaries at the corners and civil 
administration is handled from the county seat (about an hour drive away) so it 
fails the formal administrative boundary test. What value should be used for 
addr:city tags in that area? “Oracle” seems correct to me.

Third, Sunnyvale, CA. seems to more closely match the Massachusetts model as 
the area is pretty well built up and has relatively clear boundaries with 
adjacent incorporated cities (Mountain View, Los Altos, Cupertino, Santa 
Clara). But it turns out that there are small parcels of land surrounded by the 
city which are not legally part of it and are under county jurisdiction. I 
don’t really know how fire and police response to those parcels work, I suspect 
the county has an agreement with the city to have the city respond but I don’t 
really know. Walking or driving by them you will not see any visible indication 
that the land is not part of the city. It is only when a builder decides to put 
something big on it do you find out that the land isn’t officially in the city 
and the permit and planning have to be approved by the county (almost always 
with city input as an interested party). So what OSM city name should be used 
on those parcels (assuming you can identify them on the ground)? “Sunnyvale” 
seems like the right answer to me but it would fail the administrative boundary 
test.

Finally, Los Angeles. The incorporated area for LA is huge and it surrounds 
other incorporated cities. But there are areas in LA like Woodland Hills, 

Re: [Talk-us] San Diego Address Import Update

[Steve Friedl]

Richard Welty wrote:
> the real problem is that the tagging scheme we are using didn't consider the 
> divergence between postal and administrative city names and is insufficiently 
> rich to express the details.

I agree.  There are areas near me in unincorporated Orange County that can go 
by multiple names, and I'm not sure how to tag them.

Ref, about a mile from my house: 
http://www.openstreetmap.org/#map=16/33.6816/-117.6279=N

This is a modern development right next to very old mountain neighborhoods, and 
though the development name is Portola Hills, and that's how most of the locals 
(including me) refer to it, the post office "prefers" Trabuco Canyon, which is 
a wider region that encompases an actual canyon some miles away. The name (and 
region) Trabuco Canyon goes back more than 200 years.

How does one decide what to call it? My inclination is to tag addr:city = 
Portola Hills, because that's how most people refer to it.

And a new development is going in right next to it known as Portola Center, and 
that's likely to add that name to the mix (and not even considering if they get 
annexed by the City of Lake Forest, where I live, which would change actual 
administrative boundaries).

Steve -- who realizes that he's helping hijack a thread about America's Finest 
City

-Original Message-
From: Richard Welty [mailto:rwe...@averillpark.net] 
Sent: Tuesday, November 10, 2015 8:24 AM
To: talk-us@openstreetmap.org
Subject: Re: [Talk-us] San Diego Address Import Update

On 11/10/15 11:09 AM, Clifford Snow wrote:
>
> On Tue, Nov 10, 2015 at 7:48 AM, Tod Fitch  > wrote:
>
> So what is a good definition for what should go in the addr:city
> tag? If it is based on being within a formal administrative
> boundary then we may not need the tag at all as it should be easy
> for a data consumer to detect that. I have come to the conclusion
> that the addr:city is best to indicate what the locals feel their
> town name is. In the western US my impression is that has a high
> correlation with the USPS designation. Further, when dealing with
> any financial or government entity, it seems the city they want to
> hear about is the one the post office delivers to, not some subset
> or superset defined by a formal boundary of an incorporated town
> or city. So equating the post office town name with the OSM
> addr:city value seems proper to me.
>
>
> +1
>
the real problem is that the tagging scheme we are using didn't consider the 
divergence between postal and administrative city names and is insufficiently 
rich to express the details.

it'd be good to consider what the actual use cases are for the data. the most 
obvious one is geocoding, and a case can be made that geocoders based on both 
types of city names are useful.

i can also imagine querying OSM for the data for other GIS style purposes and 
wanting either type.

at the present time, we can derive admin city from admin boundaries if they are 
present.
if we discard the postal city name, though, we can't derive it from any thing 
else in OSM, as there are no postal boundaries that function like city admin 
boundaries. you can sort of fake it using census bureau ZCTA boundaries, but 
the mapping from ZCTA to city is missing and it would take a bit of work to put 
that together.

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting  OpenStreetMap - PostgreSQL - 
Linux  Java - Web Applications - Search




___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] San Diego Address Import Update

[Clifford Snow]

On Tue, Nov 10, 2015 at 7:48 AM, Tod Fitch  wrote:

> So what is a good definition for what should go in the addr:city tag? If
> it is based on being within a formal administrative boundary then we may
> not need the tag at all as it should be easy for a data consumer to detect
> that. I have come to the conclusion that the addr:city is best to indicate
> what the locals feel their town name is. In the western US my impression is
> that has a high correlation with the USPS designation. Further, when
> dealing with any financial or government entity, it seems the city they
> want to hear about is the one the post office delivers to, not some subset
> or superset defined by a formal boundary of an incorporated town or city.
> So equating the post office town name with the OSM addr:city value seems
> proper to me.


+1


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] San Diego Address Import Update

[stevea]

 > On Nov 9, 2015, at 8:42 PM, Richard Welty  wrote:
 >
 > maybe but i would do some more research before making an assumption.

 i'm aware of many postal city addresses that are in different counties
 than the
 "real" cities and i believe there are at least 4 cases where postal delivery

 > crosses state lines.


In the case of Guatay and Pine Valley, I can say that those are 
exactly the names of the communities that the people who live there 
call each of them.  (My family used to own a place in Guatay about 
forty years ago and we'd go there as a getaway -- it is a serene, 
pretty place).  While both of these are certainly in San Diego County 
(the SANGIS Addresses import data don't reflect this specifically 
with an addr:county tag, as all of them are in one county), some 
SANGIS Address import nodes have addr:city=San Diego (if true) and 
others do not (if not).  Still others, as you have found, have this 
tag incorrect, and it should be corrected.


If the city is incorporated (El Cajon, La Mesa, Chula Vista...) then 
you might want to add that in a city: tag to a node or a specific set 
of nodes for completeness sake.  If not, then for these specific 
cases you might consider adding the tags of addr:village=Pine Valley 
and addr:hamlet=Guatay.  While our addr: wiki does show a tag 
addr:hamlet, it doesn't show one for addr:village.  However, I 
believe the extrapolation from place= "works" (is appropriate) on 
addr: tags, for all values of place= (suburb, town, village, 
hamlet...).


To Tod Fitch's original question:

What is a "city" in US specific OSM terms?
...So what "more research before making an assumption" should be 
done in this area? I suspect a theoretical problem with a 
hypothetical general case is be being brought up when what I see in 
the data is a pretty straight forward issue of bad data that can be 
corrected.


So, Tod, please correct the "bad data" as you see fit, as your 
research has enlightened you, and as this person (me) has confirmed 
Pine Valley and Guatay being a village and hamlet (respectively) and 
not part of the City of San Diego (by quite a ways), but certainly in 
San Diego County.  I think Richard Welty makes a good point to "do 
(sufficient) research" but it seems you now have, and I don't believe 
you are assuming too much here.


SteveA
California
(grew up in San Diego)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

[stevea]

Richard Welty wrote:

 the key thing, i think, is that mappers have little motivation to
 work on route relations if they don't actually get used by
 anything.


This is so, so true.  Not just about route relations, but in the 
general sense of "crowdsourced data SHOULD become visible by at least 
one renderer" whether an amenity=cafe node on mapnik, a new bicycle 
route on OpenCycleMap, freshly-defined (and tagged) rail 
infrastructure on OpenRailwayMap, AND route relations.


Renderers must be rather tightly coupled to the data they display: 
it can be challenging for OSM to receive quality data without a 
decent renderer displaying those data.  The more quality renderers we 
have, specific to their subset of displayed data, the better our data 
will become -- with as many renderers as we care to develop.  OSM is 
multi-dimensional in this sense, and we can certainly walk and chew 
gum at the same time.


The point is that these "other" renderers provide this motivation for 
mappers interested in their specific subset of tagging, beyond what 
shows up on mapnik.  Sure, novice mappers get excited to see the 
reward of their newly-added cafe node "blossom" on mapnik within a 
minute (or a few) thanks to fast tiling.  And we who map bicycle 
routes or rail infrastructure have gotten used to waiting for the 
minor delays (hours, a few days) it might take for renderers specific 
to OUR data to display our recent edits.


But to encourage volunteer editors to crowdsource OTHER data 
(addresses, better route relations) into OSM, -- which do not now 
readily render -- a nearly fundamental requirement is for a renderer 
to display those results.  These can be comprehensively managed 
volunteer efforts (OpenCycleMap, OpenRailwayMap), they can be 
something like the ItoWorld renderings, they can be a "sandbox" 
renderer like what Phil mocked up for highway shields.  But to gin up 
a renderer and keep it functioning, fed and cared for shouldn't be so 
difficult or mysterious.  Our national chapter (OSM-US) might take 
some initiative here, or it might coordinate parceling out such 
efforts to interested regional parties.  Let's both discuss and 
better manage these efforts.


Anybody up for writing a quick-and-dirty "here's how to develop an 
OSM renderer from scratch" wiki?  (Maybe I just haven't seen this if 
it already exists).  It may not be drop-dead easy, but an 
intermediate coder should be able to make one in short order (weeks, 
not months).


SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] time-conditioned turn restriction

[Martijn van Exel]

Looking at the pages for turn restrictions and conditional restrictions, I
gather that you would map a left turn restriction that is only valid
between 6am and 9am and again between 4pm and 7pm as:

type=restriction;restriction=no_left_turn; no_left_turn:conditional=no @
(Mo-Fr 06:00-19:00,16:00-19:00)

Is this the preferred way? Should it be?

Martijn
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

[Adam Franco]

>
> Anybody up for writing a quick-and-dirty "here's how to develop an OSM
> renderer from scratch" wiki?  (Maybe I just haven't seen this if it already
> exists).  It may not be drop-dead easy, but an intermediate coder should be
> able to make one in short order (weeks, not months).


I would love to volunteer to test and validate any instructions that folks
are able to write as well as provide editing and feedback.

I wrote and maintain a project called Curvature
 that analyses the
geometry of highways in the OSM data set and outputs overlays that
motorcyclists and others can use to find the most twisty roads to
ride/drive. One of the biggest hurdles to this project has been the lack of
highway-surface data in most of the US and I'd love to put together a
renderer that colors highways based on their surface=* tags, highlighting
those that are missing the tag. I've been generating this data for myself
as KML files (like this example
)
but the tool-chain is a bit too long and updates are too delayed for broad
usage by the public.

Best,
Adam

On Tue, Nov 10, 2015 at 12:52 PM, stevea  wrote:

> Richard Welty wrote:
>
>>  the key thing, i think, is that mappers have little motivation to
>>  work on route relations if they don't actually get used by
>>  anything.
>>
>
> This is so, so true.  Not just about route relations, but in the general
> sense of "crowdsourced data SHOULD become visible by at least one renderer"
> whether an amenity=cafe node on mapnik, a new bicycle route on
> OpenCycleMap, freshly-defined (and tagged) rail infrastructure on
> OpenRailwayMap, AND route relations.
>
> Renderers must be rather tightly coupled to the data they display: it can
> be challenging for OSM to receive quality data without a decent renderer
> displaying those data.  The more quality renderers we have, specific to
> their subset of displayed data, the better our data will become -- with as
> many renderers as we care to develop.  OSM is multi-dimensional in this
> sense, and we can certainly walk and chew gum at the same time.
>
> The point is that these "other" renderers provide this motivation for
> mappers interested in their specific subset of tagging, beyond what shows
> up on mapnik.  Sure, novice mappers get excited to see the reward of their
> newly-added cafe node "blossom" on mapnik within a minute (or a few) thanks
> to fast tiling.  And we who map bicycle routes or rail infrastructure have
> gotten used to waiting for the minor delays (hours, a few days) it might
> take for renderers specific to OUR data to display our recent edits.
>
> But to encourage volunteer editors to crowdsource OTHER data (addresses,
> better route relations) into OSM, -- which do not now readily render -- a
> nearly fundamental requirement is for a renderer to display those results.
> These can be comprehensively managed volunteer efforts (OpenCycleMap,
> OpenRailwayMap), they can be something like the ItoWorld renderings, they
> can be a "sandbox" renderer like what Phil mocked up for highway shields.
> But to gin up a renderer and keep it functioning, fed and cared for
> shouldn't be so difficult or mysterious.  Our national chapter (OSM-US)
> might take some initiative here, or it might coordinate parceling out such
> efforts to interested regional parties.  Let's both discuss and better
> manage these efforts.
>
> Anybody up for writing a quick-and-dirty "here's how to develop an OSM
> renderer from scratch" wiki?  (Maybe I just haven't seen this if it already
> exists).  It may not be drop-dead easy, but an intermediate coder should be
> able to make one in short order (weeks, not months).
>
> SteveA
> California
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] San Diego Address Import Update

[Greg Troxel]

Tod Fitch  writes:

> What is a “city” in US specific OSM terms?
>
> I prefer a postal city definition as that is the most useful for
> routing purposes which I feel is the primary use of address data in
> OSM. Or are we dealing with some other concept of addr:city?

I see it as fairly clear that addr:city is about administrative
boundaries and what the local civil government considers to be legal
physical addresses (vs mailing addresses).

In Massachusetts this is very clear; every bit of land is in a city or
town, and there are (mostly) granite markers at the corners.

In states with unincorporated areas, it seems like there are areas with
cities, and then areas beyond the city where some rules apply, and then
areas that are in a county but not really in a city, so I can see that
this is complicated.

It would be interesting to ask the assessors or the police/fire
department or PSAP operators how they see addresses and cities in these
areas.

I would suggest that if we want to tag postal addresses vs legal
addresses that those have tags that are explicitly about postal.

> So what value to use for the addr:city tag values? There is an
> administrative boundary around the area that looks like it is from the
> original Tiger import with the name of “Pine Valley” as a
> “locality”. There is a post office there with a “Pine Valley” sign on

place=locality is funny and probably a Tiger artifact.  That makes sense
for what would be a "place name" in GNIS, vs an actual admin boundary.
If there's a boundary polygon, that seems likely to have come from
something real (although would be nice to check, if someone had enough
spare time).

I don't mean to criticize in any way your fixing the Pine Valley
issues.  It certainly sounds like you have been well more than careful
enough.


signature.asc
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Whole-US Garmin Map update - 2015-11-07

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2015-11-07

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2015-11-07/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2015-11-07

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us