Re: [Talk-us] Washington DC place node cleanup

[Minh Nguyen]

Vào lúc 03:01 2020-12-04, Frederik Ramm đã viết:

Hi,

when reverting an edit this morning I noticed that the node for
Washington (https://www.openstreetmap.org/node/158368533) has myriad
name:xx tags, many of which seem to be some variant of "Washington D.C."
(with or without commas or dots), whereas the "local" name seems to be
just Washington, without the D.C.

As a native speaker of German I can assure you that we don't call the US
capital "Washington D.C." as the name:de tag claims; I would assume that
it is similar for most other languages. The German-language OSM map at
https://www.openstreetmap.de/karte.html?zoom=10=38.70174=-76.93764
has a mechanism where it displays the German name and then, if the local
name is different, the local name below; since the German name
"Washington D.C." and the local name "Washington" are different, this
leads to a somewhat funny display (whereas the logic works ok for other
US cities).

I could of course fix the German name but I think that it might need a
more thorough review and I don't feel competent for that.

Two name tags (and this is checking only those that use Roman letters)
look like they might be entirely wrong and refer to the District of
Columbia only:

name:lfn=Distrito de Columbia
name:mi=Takiwā o Columbia


Most of these localized names were added in changeset 76520412 [1] based 
on labels on the associated Wikidata item. [2] So this time it was not a 
case of promoting a particular minority language. In fact, I don't think 
much attention was paid to the names being added, or perhaps the Tajik 
name would've remained to the effect of "Washington District of 
Columbia" instead of being changed to "Washington (city)".


This same changeset changed the name of the District of Columbia 
relation to "Washington, D.C." in many languages, including English. [3] 
This results in Nominatim returning results like "Washington, D.C., 
Washington, D.C." I think it was inappropriate to rename the district 
this way. I think it was another oversight on the part of the 
changeset's author, because Wikidata has a distinct entity for the 
district. [4]


[1] https://www.openstreetmap.org/changeset/76520412
[2] https://www.wikidata.org/entity/Q61
[3] https://www.openstreetmap.org/relation/162069
[4] https://www.wikidata.org/wiki/Q3551781


Then again, I've heard people say "I was in D.C." and mean the city, so
perhaps that *is* a legitimate name for the city? Maybe someone in the
US community wants to have a look and do this right.

It is a bit of a conundrum in OSM - we usually say that local knowledge
tops everything, but then again for many of the languages there might
not even *be* a local Washington mapper in OSM ;)


As others have pointed out, a local would refer to the city as "D.C." 
even while acknowledging that the city's formal written name is 
"Washington" or "Washington, D.C." I think common sense would require us 
to relegate "D.C." to loc_name or short_name, just as a general-purpose, 
global map would only shorten San Francisco to the local shorthand 
"S.F." and Salt Lake City to "SLC" when space is at a premium.


Thanks in part to the D.C.-based Voice of America, I'm sure you could 
find a local to get the translated name of Washington, D.C., for many 
languages, but I'm not confident they would choose the same names as 
Wikidata.


For example, both VOA and the local Vietnamese media still generally 
call the city "Hoa Thịnh Đốn", a relic of the early 20th century when 
Vietnamese still borrowed Chinese characters for world-class cities. 
"Hoa Thịnh Đốn" is easy for a Vietnamese speaker to pronounce, but it 
only kind of sounds like "Washington" in the way that an eggcorn sounds 
like its original phrase. It's archaic and probably unknown to the 
younger generation in Vietnam. The Vietnamese government prefers the 
phonetic respelling "Oa-sinh-tơn", which conversely is unknown to older 
Vietnamese Americans.


When I originally tagged the D.C. node with Vietnamese names in 
changeset 5439052, I intended for the fallback to be "Washington", as a 
compromise between the traditional and more modern names. But I 
hesitated to explicitly tag name:vi=Washington because it's incompatible 
with the Vietnamese alphabet. I guess I should've added it as a bulwark 
against armchair linguistics. Changeset 76520412 set name:vi to 
"Washington, D.C.", which to a Vietnamese speaker is rather like 
labeling New Orleans as "New Orleans, LA" on a map.


Long story short, I find changeset 76520412 to be problematic in the 
languages I know, let alone the many languages I don't. Thanks for 
bringing it to our attention.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] While we're fixing things in iterations

[Minh Nguyen]

Vào lúc 15:56 2020-09-23, Andy Townsend đã viết:
I'm actually surprised that someone associated with the OSM US community 
hasn't created a proof-of-concept "good US road route rendering" variant 
of the OSM Carto style on a live server that people can use for 
reference (I'm guessing ongoing server costs wouldn't be huge - a couple 
of $ a day at one of the cheaper hosters).  Of the issues above (1) you 
can ignore in a proof of concept (or deal with some of the edge cases), 
(2) isn't an issue if you're just rendering the US and (3) isn't a 
problem if you can live with downtime at the occasional reload (or have 
two databases - one live, one available to be reloaded if you can't).


In 2012, Phil Gold and Richard Weait developed a "shield renderer" and 
set it up on an OSMUS server. [1] The renderer not only eschewed way 
refs in favor of route relations but also used the network=*, ref=*, and 
modifier=* keys to choose accurate shields consistent with road signage 
-- not a small feat for the U.S.


It was something of a proof of concept, apparently taking an approach to 
processing the relations and generating shields that would've been a 
nonstarter for the openstreetmap-carto project. The project did get 
pretty far in terms of supporting not only state-specific shield designs 
but even plenty of county-specific shield designs and some one-off 
shields. [2] However, the server isn't maintained. It ran out of disk 
space, so it hasn't kept up with OSM planet updates.


More recently, Kevin Kenny reimplemented the shield renderer using a 
more robust approach [3] and has discussed route relation support with 
the openstreetmap-carto developers. [4]


OSMUS is interested in offering an Americentric renderer replete with 
shields. If anyone would like to help with the server situation, let's 
get in touch. Also I'm sure Kevin would welcome any pull requests to his 
osm-shields project, which would probably be a good starting point for 
this renderer if we go with Mapnik and raster tiles.


[1] http://elrond.aperiodic.net/shields/
[2] https://bugs.launchpad.net/osm-shields/
[3] https://github.com/kennykb/osm-shields/
[4] https://github.com/gravitystorm/openstreetmap-carto/issues/596

--
m...@nguyen.cincinnati.oh.us
m...@openstreetmap.us


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

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 11:02 2020-09-23, stevea đã viết:

On Sep 23, 2020, at 10:51 AM, Brian Stromberg  wrote:

A short question of a lengthy response: What is the history behind that definition of 
'suburb'? Is it a result of the term being used that way in UK/Europe/elsewhere? Seems 
like an odd usage, since "suburbs" have had a very clear definition in the 
United States for decades now, and it has nothing to do with neighborhoods.


I believe it is UK-derived, as are many OSM "definitions" (usually / often 
clarified in wiki for that key).


If I'm not mistaken, the definition on the wiki seems to align more 
closely with the meaning of "suburb" in Australian English, in which 
it's understood to be anywhere within the city, even near the central 
business district. [1] place=suburb was originally proposed by an 
Australian mapper in 2006. [2] Also, around early 2008, Australia jumped 
from 7.8% to 29% of global place=suburb usage, which could have helped 
to reinforce that definition. [3]


The wiki says place=suburb is "in a place=town or place=city", but that 
doesn't necessarily say it has to lie within the administrative boundary 
that contains the place=town/city as a label. place=town/city is mapped 
as a POI, not as an area with distinct boundaries. But even so, it is 
pretty far from how Americans associate suburbs with distinct 
incorporated municipalities or unincorporated areas on the outskirts of 
the city.


[1] https://en.wiktionary.org/wiki/suburb#English
[2] https://wiki.openstreetmap.org/wiki/Special:Diff/55503
[3] https://ohsome.org/apps/dashboard/

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] While we're fixing things in iterations

[Minh Nguyen]

Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:

Can we finally fix two other longstanding problems, then?

1. The wiki being incorrect about not counting bicycle lanes.  That's 
not reflective of how validators deal with lanes, how data consumers 
like Osmand or Magic Earth deal with lanes, or how ground truth works.  
The whole "but you can't fit a motor vehicle down it" argument is 
facile, that's what access:lanes=* and width:lanes=* is for.


I agree that width is a poor argument for the status quo, especially 
given the common practice (in California, anyways) of bike lanes that 
double as right turn lanes for cars.


For what it's worth, the lanes=* documentation has long included a 
passage recommending that data consumers treat lanes=* as a minimum 
value rather than a reliable exact lane count. Apparently some mappers 
only count through lanes but exclude turn lanes.


I'm pretty sure existing routers would have no problem with including 
bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=* 
are both present. So I think a reasonable migration path would be to use 
the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the 
non-auto-centric approach you're advocating.


2. Tagging route information on ways.  It's about a decade too long at 
this point for ref=* on a way to be completely disconnected from the 
entity the tag applies to:  That's why route relations exist.  Biggest 
problem child on this at the moment:  OSM's own tilesets.  Let's drop 
rendering for ref=* on ways and just render the route relations already, 
this and multipolygons are why relations came to exist in the first place.


I'm as excited about route relations as anyone, especially because route 
relations are required for more nuanced route shield selection in 
renderers and routers. But for all the problems route relations solve, 
there are still some unresolved issues:


* Even once rendered maps display pictioral route shields [2], there 
will still be situations where plain text is more appropriate, just as 
on the ground. It isn't always obvious how to transform a particular 
network=* value into a human-readable ref prefix to display in prose or 
read aloud during turn-by-turn navigation. Signposted ref prefixes can 
be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly 
building up Wikidata's coverage of signposted road networks and linking 
it to OSM Wiki data items, to make it easier for data consumers to look 
up the human-readable ref prefix on demand [3] or export a lookup table 
like [4] to hard-code. Incidentally, I've also proposed a road name 
formatter property at Wikidata [5], so that data consumers can expand 
network=US:NV:Clark to "Clark County Route", but it hasn't gotten much 
traction yet.


* A way's ref=* key is an ordered list, whereas there's no explicit 
ordering of a way's membership in multiple route relations. (A relation 
explicitly contains its members but not the other way around.) A data 
consumer either has to hard-code some heuristics that may not always be 
accurate [3] or infer the order from the way refs, as OSRM does. [6] 
There's a parallel situation with route numbers associated with a bus 
stop. The route_ref=* key on the stop node makes the order explicit, 
since some agencies don't sort the routes numerically on signage.


* The destination:ref=* key uses the same prefixed syntax as way refs. 
No structured alternative has been formally proposed, but 
destination:network=* is common in Australia (where network=* is common 
on ways) and I've begun using destination:ref:wikidata=* in some parts 
of the U.S. I don't think it's too outlandish to imagine a future where 
navigation software uses destination:wikidata=* to detect street names 
that should be prefixed by "onto" instead of "toward" (instead of using 
destination:street=*, which takes some destinations out of order) and 
uses destination:ref:wikidata=* to choose the right shield to display 
and the correct ref prefix to read aloud.


[1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/508
[3] 
https://wiki.openstreetmap.org/wiki/SPARQL_examples#Human-readable_route_refs

[4] https://tinyurl.com/yxk5ux8h
[5] 
https://www.wikidata.org/wiki/Wikidata:Property_proposal/road_name_formatter

[6] https://github.com/Project-OSRM/osrm-backend/pull/4524

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 21:47 2020-09-22, Paul Johnson đã viết:
On Tue, Sep 22, 2020 at 8:56 PM stevea 
> wrote:


If you MUST tag place=neighbourhood (note the u) see if you agree
with me that this tag makes most sense in a hierarchy where
place=suburb (and perhaps quarter, if applicable, is/are above) also
exist(s).  I'm not strictly saying I believe that
place=neighbourhood CANNOT exist without place=suburb, but it makes
me wrinkle my brow a bit at it not fitting as well as a
landuse=residential (multi)polygon might rather generically and
innocently (without any hierarchy required) fit in.


Landuse=residential fits better for the lots within a place, not as a 
substitute for it.


I've never gotten into mapping individual lots, but I agree that 
landuse=residential is a reasonable tag to use in conjunction with 
place=plot. [1] I don't think that needs to be mutually exclusive of 
mapping the surrounding subdivision as a named landuse=residential area.


[1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dplot

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:



On Tue, Sep 22, 2020 at 8:36 PM Mike N 
> wrote:


On 9/22/2020 9:26 PM, Paul Johnson wrote:
 >         The extra hamlet nodes are import remainders that haven't
yet been
 >     converted to landuse areas.   The general landuse zones for
that area
 >     have been identified, but do not exactly correspond to the named
 >     subdivisions.   As I get a chance to survey, I divide the
landuse into
 >     subdivisions and convert the node to a named area for the
subdivision.
 >
 >
 > Please don't expand these as landuse, please expand them as
 > place=neighborhood instead.  Landuse polygons should be congruent
to the
 > actual land use.

That's a good point: the subdivisions often contain one or more landuse
basins, clusters of trees, etc.   I've been thinking of them as one big
blob, but it seem correct on a more micromap level to mark them as
place=, and identify the smaller landuse areas (which are sometimes all
residential).


Exactly.  My rule of thumb is if you're thinking about putting a name on 
it, and it's not a shopping center, apartment complex or similar large 
but contiguous landuse, then landuse=* probably isn't what your polygon 
should be.


It's common, intuitive, and IMO beneficial to map a planned, 
suburban-style residential development as a single named 
landuse=residential area. These developments have well-defined 
boundaries and are primarily residential in character. If there are some 
wooded lots in the subdivision, it's perfectly fine to map a 
natural=wood area inside of or partially overlapping the 
landuse=residential area, ideally without being connected to it. This 
approach is supported by longstanding documentation [1], old threads 
[2], and good support in both renderers [3] and search engines.


There have also been old discussions where folks have conflated the 
concept of landcover with landuse. [4] But I find this approach overly 
academic. Taking it to the logical extreme, landuse=residential would 
only be coincident to each house in a subdivision, given that the yards 
are non-dwellings.


I don't see the need for a fundamental distinction between planned 
residential developments consisting of multi-family apartments and those 
consisting of single-family houses, such that the former would be mapped 
as a coherent landuse area but the latter would be a shapeless place 
point. Where there's no such distinction, the landuse areas lend 
themselves to ab intuitive rendering that's good for navigating suburban 
sprawl. [5]


If a planned development truly is actually mixed-use, and not only in a 
garden-level micromapping sense, then something other than landuse=* 
would be reasonable, since a particular landuse doesn't characterize 
that development anyways. Named landuse=residential areas also don't 
tend to make as much sense in urban areas, older inner suburbs, and 
rural areas. But the areas in changeset 91255294 aren't mixed-use 
developments; they're residential areas in a suburban setting.


[1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
[2] I previously wrote on this topic in 
 and 
it seemed like other respondents were taking the same approach.

[3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
[4] 
https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html

[5] https://osm.org/go/ZTVSa4OB

--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] OpenStreetMap U.S.: Connect 2020 -- registration and call for proposals

[Minh Nguyen]

Please join the rest of the OpenStreetMap U.S. community for Connect 
2020 -- a free*, virtual event sharing cool ideas and celebrating our 
community from October 29 to 31. Registration is open:


https://www.openstreetmap.us/connect2020/

This isn't quite a State of the Map U.S. We're trying something new this 
year, and we can't pull it off without your help. Please consider 
proposing a session or volunteering as a facilitator. The deadline for 
session proposals is September 20. Here's the detailed call for proposals:


https://www.openstreetmap.us/2020/08/connect2020/

Looking forward to connecting with all of you!







* Free as in freeform tagging. Also free of charge.

--
m...@nguyen.cincinnati.oh.us
On behalf of the OpenStreetMap U.S.: Connect 2020 organizing committee


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Minh Nguyen]

Vào lúc 06:17 2020-09-01, Matthew Woehlke đã viết:
On a related note: I use service=driveway (for lack of anything better) 
for access ways to parking lots that don't have parking spaces (hence, 
not service=parking_aisle). These are likely *not* public right-of-ways 
(the lots themselves are usually "private"), but they are also certainly 
not access=private.


The access roads that form the backbone of a parking lot layout 
shouldn't be tagged service=driveway. [1] You're right that there isn't 
a more appropriate, well-established service=* tag, since no one seems 
to know of a concise, intuitive term for these access roads. But there's 
also no requirement that every highway=service way have a service=* tag. 
(Shared driveways also commonly lack service=*, but there are at least 
some tagging ideas floating about.)


Routers that understand service=driveway treat it as the very bottommost 
rung in a hierarchy of road classifications, applying penalties similar 
to the penalties for parking aisles. These penalties generally ensure 
you'd never use a driveway as a shortcut between two non-driveways. But 
around a parking lot, they may lead to suboptimal routing to a loading 
dock or drop-off area, traversing ordinary parking aisles instead of 
these access roads that are likely to be wider and more traversible.


If we do someday come up with a good tag for the access roads you're 
describing, it'll be easier to identify and retag them if they lack a 
service=* tag than if they're tagged service=driveway. After all, 
service=driveway would be more appropriate for a drop-off area coming 
off a parking lot. In the meantime, it's rather nice that some renderers 
and editors give service roads deemphasize service=parking_aisle ways 
while leaving these bare highway=service ways a little more prominent by 
comparison.


So, no, service=driveway should *not* imply 
access=private. If anything, lacking other information, it should imply 
access=yes just like it does on any other way, and I suspect routing 
engines route accordingly.


This is my understanding as well. It's OK that a router generally treats 
driveways as accessible: most driveways are dead-ends, so a router would 
only lead a delivery driver down a driveway if they have a package to 
deliver to that house. (Clearly Amazon's intention is to know how to go 
down the driveway instead of stopping at the curbside mailbox.) On the 
other hand, if the driveway isn't a dead end, a penalty should prevent 
it from being used as a Waze-style shortcut around a more easily 
traversible public road.


This, BTW, is a large part of why we're having this conversation in the 
first place. The problem with overusing access=private is that we're 
effectively teaching routing engines to ignore that, which makes such 
tagging much less useful.


Exactly. As a mapper, I'd be concerned about a logistics company such as 
Amazon needing to route to the front door, so to speak, and therefore 
tossing out a convenient way to distinguish between two common kinds of 
driveways that can't be used in the same manner.


Vào lúc 12:56 2020-08-31, Kevin Broderick đã viết:
> Second, I'd like to point out that there *are* driveways in New England
> that are actually public right-of-ways.
> https://www.openstreetmap.org/way/19685143
>  is one such example; the
> southernmost portion of the way is arguably service=driveway, except
> that it is actually a public right-of-way that continues south,
> eventually connecting to Lincoln Gap Road. While they are certainly the
> exception and not the rule, the number of such setups in Vermont is
> non-trivial due to the ancient roads laws there. There are probably some
> similar cases in New Hampshire and possibly Maine, I believe, but I
> can't cite any off the top of my head (the documentation of unmaintained
> public-right-of-ways isn't as good as it is in Vermont, making things a
> bit more murky).

Penalties aren't absolute prohibitions, so if there's no other way to 
get to that public road, or if the alternative would take much, much 
longer, the router will hold its nose and use the driveway. But it can't 
do that if the road is marked as impassable via access=no or restricted 
via access=private.


It can be a bit unintuitive to think about routing penalties when 
mapping. During a navigation mapping workshop at State of the Map 2018 
in Milan, my colleague Kajari and I walked through a very basic 
application of a routing penalty to illustrate the concept. The workshop 
wasn't recorded, but the notes and slides are available at [2], with the 
explanation starting on slide 12.


[1] 
[2] 



--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Minh Nguyen]

Vào lúc 07:00 2020-08-30, Greg Troxel đã viết:

What is the actual problem with other people's driveways being marked
access=private on the map?  yes, driving on is usually technically not
illegal, but unless you are going there because you were invited for
have a reason they'd approve of, it's basically not ok.


I expressed support for the proposed mechanical edit because the 
distinctions being debated in this thread didn't factor into the 
workflow that originally added these access=private tags. All the posted 
driveways I've mapped are now tagged identically to every other 
driveway. Lesson learned: I should map the posting distinction more 
explicitly in the future, such as using traffic_sign=*. But if I map an 
adjacent traffic_sign=* feature while leaving the way's access=* set to 
the same value as every other driveway, that still strikes me as a bit 
of a trap for data consumers. Access is too important to simply coin an 
ad-hoc tag for without having data consumers on board.



If you object to pink dots on driveways, I'd say that access=private is
what is expected so the renderer should be fixed to not show that and
show other access values.


The status quo ante had been that most driveways lacked an access tag. 
Unlike with highway=residential or whatnot, I don't think there was much 
of an end user expectation that driveways in general would indicate 
restricted access. I don't think people were likely to have stumbled 
upon these driveways just because they lacked a dotted pattern on a map.


Meanwhile, from a routing standpoint, these blanket access=private tags 
are problematic. For example, OSRM tries to snap an origin or 
destination waypoint to a roadway to avoid returning no route. [1] 
However, this snapping only takes the road topography into account and 
can unfortunately snap across barriers such as fences, ravines, and 
railroad tracks. Overuse of access=private exacerbates this problem by 
forcing the router to snap even greater distances to a public road. [2] 
Most property owners would prefer that you use their driveway as you 
leave their property instead of making a beeline dash for the nearest 
public road across their petunias.


I favor stripping the access tags from the Amazon-tagged driveways (not 
all driveways) and starting over. Going forward, we can document the 
reasons for a driveway's access tag on a case by case basis by mapping 
things like gates and no trespassing signs.



A further issue we haven't talk about:

  How much detail is ok on residential property, from a privacy
  viewpoint?  Is mapping of "no trespassing signs" going too far?

We show structures, and we show driveways.  These don't feel invasive
given imagery.  They are very useful for navigation, particularly with
long driveways.   We don't map much else.

To me, marking individual driveways about whether they have a no
trespassing sign or not, is a bit much.  It feels a bit dangerous, in
terms of getting it wrong and expectations.  Yes, you can see them from
the road, but still.

I also don't think it's all that useful.  When you are going somewhere,
you need to pay attention, regardless of the map.  And you know why you
are going, and if you have some kind of permission, and we are not going
to automate that.


No trespassing signs seem more useful to map than front yard flagpoles 
and backyard swimming pools, but I map those already.


A couple scenarios to consider:

* An office building has a small parking lot and a sign at the driveway 
that says, "Private property -- Enter driveway by appointment only". [3] 
To me, this driveway would be a natural case for access=private. One 
could argue that it's customers who would be making the appointments, 
thus access=customers on both the driveway and parking lot, but that 
would be indistinguishable from the great many strip mall parking lots 
with "Customer Parking Only" signs that we tag as access=customers. As 
far as I know, no router uses the accessibility of a parking lot to 
decide whether the driveway that leads to it is also accessible.


* A homeowner is the victim of a county GIS database that erroneously 
extended their narrow driveway up a hill to connect to a large 
subdivision. Apparently large vehicles have attempted to use the 
driveway as a shortcut, only to have trouble backing out. Before the 
owner installed a gate out of desperation, they tried posting a no 
trespassing sign. They also tried repeatedly to edit OpenStreetMap, 
going as far as to delete their driveway, thinking it would influence 
drivers. [4] I think it's safe to say that any owner who posts a no 
trespassing sign would appreciate OSM respecting that sign. Granted, it 
would be less clear-cut if the sign bears a facetious message. (There 
are many examples in Google Image Search.)


[1] 
https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8

[2] https://f.zz.de/posts/201910152010.access_private_on_driveways/
[3] 

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Minh Nguyen]

Vào lúc 11:55 2020-08-22, Volker Schmidt đã viết:



On Sat, 22 Aug 2020 at 19:31, > 
wrote:

I've
even encountered signs that threaten people who attempt to use their
driveway as a U-turn.


This seems to be the rule in England, UK. When I took my driving license 
many years back (1978) there, I remember that the driving instructor 
reminded me explicitly that that a U-turn backing the car into a 
driveway would mean my failing the test (I am from Germany where that is 
the preferred approach as it's safer than the the 3-point-turn which 
they tought me in England).
So there are places in the world where the driveways are implicitly 
"private" without any additional sign.


I was referring to signs that threaten that the owner will come out and 
pull a gun out on you if you back into the driveway. Fortunately, these 
signs are relatively rare in the U.S. But they are quite different than 
the usual rule against backing into a driveway that would fail a driving 
test, hence my preference for making this distinction in the database.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Minh Nguyen]

Vào lúc 12:01 2020-08-16, Alex Weech đã viết:

Hello all,
I'm planning a mechanical edit to remove the access=private tag that 
Amazon Logistics mappers added in New Hampshire. They originally added 
the tag without using street-level imagery to look for no trespassing 
signs, and they made so, so many mistakes. The group has finally yielded 
to the community feedback to stop adding the tag, and I want to quickly 
remove as many of the instances as possible. I believe it is worthwhile 
to remove the tag because it is important to distinguish between houses 
that accept visitors and those that do not, and currently access=private 
is the best way to indicate it, but it is diluted by all of the Amazon 
Logistics driveways. Ihave written up my proposal here 
. 
It's pretty much copy-paste from the project with the same goals for 
neighboring Maine, and that one has been well received, so I am hoping 
this one is well received as well. (I'd be in favor of a nationwide 
greenlighting of such projects, but since that hasn't happened yet I'm 
doing my due diligence contacting the community ).

Sincerely,
Alex (aweech)


I'm glad to see efforts toward distinguishing between posted and 
unposted driveways. I've encountered plenty of no trespassing signs on 
driveways over the years, some of them more menacing than others. I've 
even encountered signs that threaten people who attempt to use their 
driveway as a U-turn. So I'd imagine this distinction would be 
beneficial to any logistics company as well.


The proposal says it'll be limited to features edited by Amazon 
Logistics users, which is a good idea. Since there may have been 
turnover on the team since the first driveways were mapped, ideally 
you'd include former team members too. Unfortunately, 
 doesn't list 
former team members, but you could comb through the page's revision 
history if you wanted to be extra thorough.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Underground railways, indoor mapping, and overlapping features

[Minh Nguyen]

Vào lúc 10:28 2020-05-05, Michael Reichert đã viết:

Using the same nodes (like mapping to adjacent landuse polygons) breaks
routing because routing engines would allow trains to switch between the
levels. Using duplicated nodes at the same location is likely to trigger
quality assurance services and therefore mappers trying to "repair" it
by merging them. Using two identical geometries in straight sections
with nodes at different locations, will likely provoke the same as
duplicated nodes.


Just as a double-decker bridge requires layer tags on each deck, so 
would a double-decker subway tunnel, whether the ways are coincident or 
offset by some arbitrarily small amount. Adding layer tags, as suggested 
in [1], would likely suppress any validator warnings about coincident 
ways. But it's true that mappers could still be confused by coincident 
ways if editors don’t provide intuitive ways to navigate among them.



Regarding option 2: GraphHopper assembles its routing graph by relying
on the node IDs in OSM. It would not suffer from using this option but I
doubt that it is safe for the future. If OSM adopts to drop its 64 bit
node IDs in favour of the location (32 bit latitude + 32 bit longitude),
such cases will cause difficulties.


This is an intriguing notion I had not come across before. Has it ever 
been seriously considered? It seems to me that distinguishing nodes only 
by their coordinates would be tantamount to merging all coincident nodes 
everywhere, which we probably would never allow as part of a mechanical 
edit, much less a history-less database schema update. (For one thing, 
everyone who dislikes joining borders to roadways would be appalled to 
see just about every CDP boundary consistently joined that way.)


[1] https://lists.openstreetmap.org/pipermail/talk-us/2020-May/020015.html

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Geocoding for Individual States.

[Minh Nguyen]

On 2019-09-15 09:50, David Ankin wrote:

Hello all,

I was hoping to hear what worked for other folks who were trying to get 
a local nominatim instance installed for house number level geocoding in 
the US (or, in my case, a particular state). I setup 3.3 nominatim by 
checking out from the branch, and downloading PA excerpt from planet.osm 
from geofabrik, and used import-full.style.


The end result for me was that i could look up streets, but not house 
numbers. some house numbers were present, but most houses were missing. 
I am trying to import TIGER data next, to see if that works. But it 
really should be in the regular planet file, in theory, right? without 
having to rely on an out-of-band data source.


TIGER roads and boundaries have been systematically imported into OSM, 
but TIGER addresses (house numbers) have not. To the extent OSM contains 
any addresses in Pennsylvania, they were either entered manually or 
imported separately (possibly from TIGER but much more likely from 
another government source).


Local mapping communities across the U.S. are working on imports that 
will eventually improve address coverage. In the meantime, I've heard 
that the main Nominatim instance does pull in address ranges from TIGER 
as a fallback. You might also take a look at pulling in data from 
OpenAddresses .


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Mapping rail trails

[Minh Nguyen via Talk-us]

On 2019-07-11 17:27, Greg Troxel wrote:

Thanks for the nice summary.  I have one minor issue to raise a question
about:

stevea  writes:


As for rail trails, very nice work, Richard!  Rail trails are usually
classified as local (lcn) if they are for cyclists, although some are
sponsored at a state-level: these are properly tagged rcn (regional
generally means "state-level" in the USA).  I don't know this for sure
(Minh?) but I might imagine that the C Canal Trail over and above
the USBR 50 relation might be properly tagged rcn instead of lcn.
Such decisions are best determined with more-local consensus by
Contributors who are familiar with the local / state statutes which
define the route.  The Bicycle_Networks wiki describe (MUTCD-standard)
signage for NUMBERED routes which disambiguate the network-level tag
that should be used.  For routes which happen to be signed
on-the-ground as non-governmental (non-MUTCD-standard signage), please
consider these on a case-by-case basis, starting (as Richard did) at
the local (lcn) level.  If network=rcn is actually a better value,
this is likely to emerge with strong consensus at a more-local (state)
level within OSM.


The notion of state sponsorship is interesting, and there is the aspect
of a state bicycle route number, akin to a state numbered highway.  I
can certainly see that being rcn.  Then there is the aspect that in MA,
most things called "rail trails" end up getting built with state funds,
and built to state construction standards, both avoiding the towns
having to say and making the resulting trail much more costly (but nicer
in some ways).  These trails tend to have names, like "Nashua River Rail
Trail", "Assabet River Rail Trail", "Bruce Freeman Rail Trail", but they
don't have a "MA Bicycle 29" designation, or if so nobody knows that.

Most of them go over fairly short distances; the Nashua River one is
about 12 miles and is in the towns of Ayer, Groton, Pepperell, MA and a
bit in Nashua, NH.  To me, that feels local in scope rather than
statewide, so I'd want to see it as lcn.  The fact that it was funded
with state rather than local money doesn't seem important.  (Actually,
state money pays for local roads in complicated scheme.)

Now, if the Central Mass Rail Trail were somehow complete in a Cambridge
to Northhampton sort of way, or even half of that, it's obviously rcn,
regardless of who organizes it.

This gets fuzzy.  Perhaps, in a US-centric northest-centric way, it
feels like rcn is 100 km.

I'm not sure this ended up being useful.  I think I more or less agree
with where I think you ended up, saying that other than federal and
state numbered routes, all routes are lcn, unless there is really clear
local consensus that they are very important and of state-level scope,
in which case they can be promoted to rcn.


I think this speaks to the utility of the cycle_network [1] and operator 
tags. The network=lcn/rcn/ncn/icn tagging scheme may've sufficed in the 
early days in the UK, but increasingly more nuance is needed on both 
sides of the pond.


As with the network tag on bus routes, what's important for both network 
and cycle_network is that the route is intended to form part of a 
coherent *network* (almost like a brand, but not quite). A given route's 
actual length, connectivity, build quality, or ownership on its own is 
perhaps less important, but consistent signage or ownership is how an 
organization might establish a set of routes as a network.


Long ago, Ohio's transportation department set up a state system of 
lettered bicycle routes along rural roads, which no practically no one 
knows about. But local bike advocacy groups also coordinated on a system 
of numbered routes over state- and county-maintained trails.


Over time, Dayton-area counties took up the task of signposting the 
unofficial numeric routes with the same kind of signage as the official 
statewide system. Then adjacent counties up and down the state followed 
suit, to the point that the numbered routes are the state system for all 
intents and purposes. A few years ago, all the routes in the state were 
renumbered, something that has happened many times to state road route 
networks. [2] But IIRC it was carried out by trail managers and 
coordinated by regional planning commissions rather than the state.


The numeric network includes some spur routes that are shorter than many 
city-maintained local routes but bear state route signage, such as route 
3E. [3] The alphabetic and numeric routes alike are tagged with the same 
cycle_network=US:OH, though the operator tag can be used to distinguish 
if necessary. It's all a bit chaotic, but hey, that's reality.


[1] https://wiki.openstreetmap.org/wiki/Key:cycle_network
[2] 
https://en.wikipedia.org/wiki/Category:Highway_renumbering_in_the_United_States

[3] https://www.openstreetmap.org/way/128492582

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list

Re: [Talk-us] The San Jose / Santa Clara border

[Minh Nguyen]

On 2019-01-28 12:40, OSM Volunteer stevea wrote:

(Lengthy reply alert)
Hi Minh:

Thanks for your (always thorough and well-researched) pointers and history — though I don't recall 
"impressing LAFCO" upon you, I did mention it in the context of admin_level, so, OK, 
whatever!  Good for Santa Clara LAFCO for publishing municipal boundaries into the PD.  I am again 
thankful we live in a state with excellent public data in the PD along with our "sunshine 
laws."

I like that you made Seven Trees an admin_level=10 for reasons you did, even as you've 
described other SJ neighborhoods as "amorphous" (exactly the right word, imo!)  
I wouldn't have noticed had you not sent me links [1].

"Urban islands as a LAFCO high priority to streamline" is something I've never heard of before.  Notwithstanding the 
letter LAFCO sent City of San José nearly eight years ago [3], I believe it is the City of San José itself which "serves as 
the authority on" its own municipal boundary.  LAFCO might have something to say (keeping accurate maps / GIS data, for 
example) about all cities in Santa Clara County, but I don't think anyone contends that LAFCO doesn't define municipal 
boundaries, the cities themselves do.  Indeed, LAFCO's letter says it can "encourage" annexations (of islands) and 
waive its fees (to incentivize a "streamlined process" for islands 150 acres or less) but it cannot force a city to do 
so, whether this is a "high priority" for the LAFCO or not.

Using link [4] and blending with the instant topic (which I volunteered to remedy), I examined the five pages of City of Santa Clara.  The first four 
(pages 45-48) are "islands" which share a boundary with City of San José (the fifth is an island solely inside of the City of Santa Clara). 
 None of these involve the area around the airport / Westfield Valley Fair, which was Andy Townsend's "area of concern," prompting me to 
answer that I'd take a look.  (SC05, page 48, is pretty close, but is north of the airport and involves a creek edge near Trimble and Orchard).  
Those four "islands" probably could be used to (rather crudely) "hand draw modify" the Santa Clara City Limit boundary in OSM 
(relation 2221647) but it isn't clear to me how what these maps define as Urban Service Boundary is or isn't the actual city limit boundary for Santa 
Clara.  As I think about it, the identification of these four islands (the fifth might become an "inner" member of that relation) in this 
document COULD be used to exclude these islands from the City Limit, but I'm not sure that is accurate (it likely is, I'm simply not sure).  So while 
these resources might qualify as "interesting," I don't find them wholly relevant to what I volunteered to do "near the airport."

However, links [5] and especially [6] yield dense, recent, tasty data.  Having used 
ArcGIS layers before like this (largely while mapping to fix TIGER rail), I can set a 
basemap of OSM while viewing these data.  Doing so allows me to find where there are some 
relatively minor differences, so I elected to fix these, "manually" using JOSM.

These (minor) changes were along the "grass edge" NW of the 101-Trimble interchange, westerly to the UP Coast 
Subdivision rail bridge crossing 101, southerly to just north of Central Expressway (not south, a significant change 
making OSM's representation of CE W of Trimble/De La Cruz to the rail bridge now in Santa Clara, not San José).  This 
continues easterly across Trimble into the airport, as far as Taxiway Y, includes better-traced (though likely not 
perfectly accurate) rectangular and triangular areas of northern portions of runways and taxiways, south along De La 
Cruz and excludes Memorial Cross Park (in San José, not Santa Clara).  The barrier=fence had to be node-by-node unglued 
from the city limit (but kept glued to the parking lot) to be better characterized as "along Martin Avenue" 
(and so was), SE on Martin Avenue (with some "jogs") to a bit further SE on Aviation Avenue, southerly (with 
"jogs") to Campbell Avenue near Stephen Schott Stadium.

 From there, the boundary needed to be moved easterly by about 10 meters, so it 
was, past Sherwood and along Portola Avenue.  Adjustments were made to better 
align with The Alameda, past Morse and Idaho and to I-880, where a 90-degree 
westerly boundary continues to Newhall and Monroe, where as it follows the 
southern boundary of Santa Clara Mission Cemetery, it is correct (enough for 
now).

The ways I changed have IDs 166659029 and 97341711 (recently reverted by Andy Townsend), 
part of the Santa Clara (city) municipal boundary relation.  I believe this is moderately 
better, which is "moderately better."

SteveA


Thanks for making these improvements! I've added an item to our local 
to-do lists for refining the rest of the city boundary as needed:


https://github.com/codeforsanjose/OSM-SouthBay/issues/19
https://wiki.openstreetmap.org/wiki/Special:Diff/1782398

--
m...@nguyen.cincinnati.oh.us

Re: [Talk-us] The San Jose / Santa Clara border

[Minh Nguyen]

On 2019-01-26 17:13, OSM Volunteer stevea wrote:

While I don't know quite who to call, exactly, if somebody wants to "release to me" ODbL-compatible 
data which need to be harmonized with what are now in OSM, I'll volunteer to be the "nexus of citizen 
entry" to assure they find their way into our wonderful map.  Send me a pointer to the data, assure me 
they are ODbL-OK and I'll "merge" these into OSM.


Any help maintaining San José’s sprawling, unwieldy city limits would be 
most welcome. A few years ago, I incorporated the Seven Trees 
annexations into San José [1] but didn't go much further to correct the 
crude, outdated data we imported from TIGER.


Thankfully, over the years, Steve has impressed upon me the importance 
of Santa Clara County's Local Agency Formation Commission (LAFCO), which 
serves as the authority on municipal boundaries in the county and 
conveniently releases all its work into the public domain, by virtue of 
being a state agency. The commission's Island Annexation Program page 
[2] links to a memorandum from May 2011 [3] and an atlas from 2015 [4] 
that include detailed maps of the remaining islands.


The county planning department handles GIS for the LAFCO. They have an 
ArcGIS application and layer indicating all the city and town limits in 
the county. [5][6] The planning department is also subject to state 
sunshine laws regarding the public domain.


[1] https://www.openstreetmap.org/changeset/32278082 and 
https://www.openstreetmap.org/changeset/32402544
[2] 
https://www.santaclaralafco.org/specialdistricts/island-annexation-program
[3] 
https://www.santaclaralafco.org/file/IslandAnnexations/Item10A_SanJose.pdf
[4] 
https://www.sccgov.org/sites/dpd/DocsForms/Documents/UrbanIslands_2015_Atlas.pdf
[5] 
https://sccplanning.maps.arcgis.com/home/item.html?id=35968e7124f04807bd1ed70b31fab4fd
[6] 
https://services2.arcgis.com/tcv2cMrq63AgvbHF/ArcGIS/rest/services/PlanningOfficeDataService2/FeatureServer/2


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Forest Routes

[Minh Nguyen]

On 2018-11-28 06:49, Martijn van Exel wrote:

On Wed, 28 Nov 2018 02:07:45 -0800
Minh Nguyen  wrote:


On 2018-11-28 01:57, Minh Nguyen wrote:

On 2018-11-20 08:57, Martijn van Exel wrote:

When I map these roads I include the FS number (just the number)
as a ref, since that is how they are signposted in the field.


I think the ref tag on the ways should have a prefix and not just
consist of a bare number. Otherwise, it's just as ambiguous for
data consumers as the (123) refs all over New Jersey, since the
U.S. doesn't have a highway tag that corresponds one-for-one with
forest routes.


(I hit send too soon.) Lots of shields show only the number and no
prefix, such as the U.S. Route shield, but we still use the "US"
prefix anyways.

Data consumers really should be using route relations instead of ref
tags on ways whenever possible. Some ambiguity is unavoidable on way
refs, which IMO should reflect what's on plain-text signage or in
publications. If one thinks of the way refs as a compatibility shim,
then "FS" doesn't seem unreasonable as a prefix.


I think you are right. It would be good if we can arrive at a common
prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
page dedicated to roads that are maintained directly by federal agencies
(NPS, USDA, others?) would make sense. I'd be happy to help set it up.


One page already documented an "NFH" prefix on ways and 
network=US:NFSR: on relations. [1] I think I added that entry to 
the table after seeing it on some forest routes in California. [2] But 
I've changed it to an "FS" prefix since so many more ways are tagged 
with that prefix. [3]


[1] https://wiki.openstreetmap.org/wiki/United_States_roads_tagging/Routes
[2] http://overpass-turbo.eu/s/E5V
[3] http://overpass-turbo.eu/s/E5W
--
m...@nguyen.cincinnati.oh.us



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

Re: [Talk-us] Forest Routes

[Minh Nguyen]

On 2018-11-28 01:57, Minh Nguyen wrote:

On 2018-11-20 08:57, Martijn van Exel wrote:
When I map these roads I include the FS number (just the number) as a 
ref, since that is how they are signposted in the field. 


I think the ref tag on the ways should have a prefix and not just 
consist of a bare number. Otherwise, it's just as ambiguous for data 
consumers as the (123) refs all over New Jersey, since the U.S. doesn't 
have a highway tag that corresponds one-for-one with forest routes.


(I hit send too soon.) Lots of shields show only the number and no 
prefix, such as the U.S. Route shield, but we still use the "US" prefix 
anyways.


Data consumers really should be using route relations instead of ref 
tags on ways whenever possible. Some ambiguity is unavoidable on way 
refs, which IMO should reflect what's on plain-text signage or in 
publications. If one thinks of the way refs as a compatibility shim, 
then "FS" doesn't seem unreasonable as a prefix.

--
m...@nguyen.cincinnati.oh.us



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

[Talk-us] Population during mandatory evacuations

[Minh Nguyen]

(Crossposted to the talk-us and tagging lists.)

Due to the ongoing Camp Fire in Northern California [1], the place POI 
for the town of Paradise got tagged with population=0 before the change 
was reverted. Following some discussion about this changeset in OSMUS 
Slack [2], I started a discussion on the wiki about preferring more 
stable population figures over supposition about temporary 
circumstances. [3]


[1] 
[2] 
[3] 



--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Possible roundabouts?

[Minh Nguyen]

On 2018-09-06 23:27, Marian Poara wrote:

40.5234202, -111.8762446


Despite its size, the standard roundabout rules normally apply on these 
decorative or traffic calming circles -- there simply isn't enough room 
for a driver inside the circle to yield to a driver entering the circle. 
So junction=roundabout is still justified.


This roundabout is small enough that OSRM classifies it as a "roundabout 
turn", but only if the circular way is tagged junction=roundabout. 
Otherwise, you'd get confusing guidance like "Turn right, then turn right".



35.8497728, -86.4547473


This is definitely a roundabout, to be tagged junction=roundabout. Bing 
imagery shows a yield sign at each of the four approaches. Even without 
street-level imagery, you can see pedestrian islands in the middle of 
all four approaches, a hallmark of modern roundabouts in the U.S.



42.6811136, -73.6987507


This could either be considered a roundabout (junction=roundabout) or a 
turning loop that happens to have two driveways sprouting out from it. 
Either way, given the width of the loop, the loop is one-way.


Incidentally, it's kind of awful that a four-lane road would abruptly 
end in a one-lane turning circle without any signage at all.



40.22109, -76.874981


This is ambiguous. Based on the road width alone, you wouldn't be able 
to tell that the circular road is even one-way. But in Mapbox imagery, 
you can clearly see from the wear on the pavement that drivers are 
treating it like a one-way road, only turning right onto it from each of 
the three approaches. As long as it's a one-way road, it would most 
likely be a junction=roundabout as well.


And if we have OSC or Mapillary street level 
images and it is confirmed that they don’t have any roundabout sign? In 
many residential areas (but not only), there isn’t any one way sign 
inside the small “roundabouts” and it seems that both directions are used.


In residential areas, you'll often find cases where the rules are 
considered obvious to drivers and the speed limit isn't high enough to 
warrant the additional cost of regulatory signage. But that shouldn't 
change how we use tags like junction=roundabout that significantly 
affect guidance instructions.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Proposition for changing the common name tag

[Minh Nguyen]

On 2018-08-16 09:51, Daniel Koć wrote:

Hi,

I wanted to let you know about proposed change in tagging the name of 
USA and I seek for the feedback about it - see the proposition here:


https://forum.openstreetmap.org/viewtopic.php?id=63384 


There are arguments to be made for either name, but `name=United States` 
`official_name=United States of America` seems like a perfectly 
common-sense way to tag it.


I had always assumed it was tagged `name=United States of America` 
because of the vastness and blankness of this country in the 
openstreetmap-carto style at zoom level 3 in Web Mercator projection. 
(Canada needs a longer name, clearly.) But that would be mapping for the 
renderer, so by all means shorten it.


Some of the `name:*` tags on the U.S. relation seem to have taken after 
`name` by unnecessarily including the equivalent of "of America". For 
example, `name:es=Estados Unidos de América` and `name:fr=États-Unis 
d'Amérique`. By contrast, there are few `official_name:*` tags on the 
U.S. relation. These tags might need to be reviewed -- perhaps checked 
against Wikipedia article titles -- to ensure that they too follow 
common practice in the respective languages.


On 2018-08-16 10:33, Jack Burke wrote:
> I am opposed to this suggestion, because there are two countries called
> "United States" in North America: the United States of America, and the
> United States of Mexico.

To be pedantic, the official name in Spanish is "Estados Unidos 
Mexicanos", rather than "Estados Unidos de México". So the official 
English name is "United Mexican States", not "United States of Mexico".


Even if Venezuela hadn't changed its official name from "United States 
of Venezuela" (Estados Unidos de Venezuela), I'd still stick to "United 
States" for the U.S., because it wouldn't cause any confusion between 
the two countries. It would be very different if someone were to propose 
`name=America`, reasoning that it's the most common name.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Cardinal directions on highways & foreign languages

[Minh Nguyen]

On 2018-02-27 19:22, Angela Morley wrote:
I've come across an issue with the current implementation of cardinal 
directions in roles of relations. In certain areas of the world, roles 
are being used to determine the cardinal direction of a way in 
accordance with the AASHTO requirements, however those locales change 
the official name of the cardinal direction to the name of the direction 
in their local languages on road signage. Examples include highways in 
Puerto Rico and Quebec.


Should the tags north, south, east, and west be assigned in these 
locations according to the official language used on the road signs for 
those locations (precedent exists like this with Key:name), or should 
they remain English worldwide, regardless of country?


Given that these values are lowercase, they're best thought of as 
machine-readable values rather than freeform, human-readable values. So 
they should remain in English, like any other formal tag value, 
regardless of the sign's language. Taginfo shows that this has been the 
case so far in OSM:


 (tags on 
unidirectional child route relations)
 (roles on 
bidirectional route relations)


This problem has come up in a bug report I was filing with OSRM where 
they are currently just spitting out values like $north directly into 
the end user instructions because they don't know what the best way to 
handle the problem is yet. I had asked for it to be rendered as North, 
however the question of internationalization came up, and was so valid 
and pressing I thought it prudent to start a conversation about the 
topic. ( If you're curious, the original bug report: 
https://github.com/Project-OSRM/osrm-backend/issues/4918 
)


The OSRM library currently leaves it up to client code to replace the 
token with something more presentable. For example, the Mapbox 
Directions API currently replaces these $north tokens with English 
cardinal directions. It's a known issue that the API doesn't use French 
and Spanish cardinal directions in Québec and Puerto Rico, respectively, 
even though the rest of the instructions can be localized.




(Incidentally, this stretch of roadway is a concurrency of US 29 North, 
US 460 East, and US 501 South.)


Note that the behavior described above applies only to cardinal 
directions inserted based on route relations. However, most of the time, 
when you encounter a numbered route in OSRM's guidance instructions, 
it's due to a human-readable cardinal direction in the destination:ref 
tag, which is customarily written in the local language. So in Québec, 
it's currently possible for OSRM-based navigation software to announce 
an on-ramp onto "A-5 Nord" and then announce a merge onto "A-5 North".


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] I 85 Express Lane (Atlanta, Georgia)

[Minh Nguyen]

On 22/09/2017 09:46, Jack Burke wrote:

My questions are:

* Should this lane be drawn as a separate way?  Legally, you cannot 
enter or exit the lane except at the designated sections, so drawing it 
separately makes things simpler for routers.  If it's drawn separately, 
a pair of motorway_link roads would need to be added at several places 
(the dashed-stripe sections).  The Lanes wiki page[4] seems to say that 
it should be drawn separately:  "If one or more lanes of the road are 
restricted to high-occupancy vehicles (typically vehicles with 2+ 
occupants, although this varies by jurisdiction). Most useful if 
entrance/egress is permitted at any point along the route; if entering 
or exiting the HOV lane(s) is only permitted at certain locations, 
modeling the HOV lane(s) as separate ways is preferable."  (Even though 
that says HOV, the same reasoning appears relevant for toll.)  Does 
everyone concur with this construction?


I might be inclined to map the lane as a separate way, but only because 
I don't know of any routers that currently recognize the change:lanes 
tag. [1] Either way, it makes sense to treat HOV and toll lanes similarly.


[1] https://wiki.openstreetmap.org/wiki/Key:change

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Uploading sidewalks in San Jose, California, US

[Minh Nguyen]

On 19/09/2017 23:44, OSM Volunteer stevea wrote:

Vivek Bansal <3viv...@gmail.com> writes:

We are using the San Jose data which has an ODbL compliant license (and any 
government data in California has the same).


I'm following the San José discussion and don't wish to get too technically legal:  I am not an attorney, though I have paid attention to the legal 
situation with state (of California) produced geo data and how our state "Open Data/Open Records" laws plus two fairly recent California 
Supreme Court decisions make state-published data roughly if not essentially equivalent to public domain.  These legal circumstances taken together 
with OSM's ODBL result in "be free to use the data, OSM, they are ODbL compliant."  It isn't exactly correct to use the word 
"license" in how California publishes geo data.  It IS correct that such data are "ODBL compliant."  It isn't a license that 
grants this, it is case law or stare decisis (Latin for "let the decision stand") which confirm such data published by the state comply 
with both statutory law (California Public Records Act, CPRA) and California's state constitution.  The bottom line is "the data are ODbL 
compliant" though it isn't via "license."


Yes, we're aware of County of Santa Clara v. California First Amendment 
Coalition as it relates to the CPRA. The wiki page describing the import 
[1] currently states the source data's _copyright status_ as being in 
the public domain, steering clear of the term "license". Hopefully 
that'll be clear enough for the purposes of this import project.



From an OSM perspective, I suppose it can be said we are fortunate to have as 
much state (of California) published geo data available to us as we do; I 
certainly am grateful for these circumstances!


Well said -- as someone who also maps in states with more restrictive 
copyright laws, it's been refreshing to be able to say "public domain", 
end of story.


[1] 
https://wiki.openstreetmap.org/wiki/Santa_Clara_County,_California/San_Jose_Sidewalk_Import


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

[Talk-us] talk-us-sfbay

[Minh Nguyen]

There's a new talk-us-sfbay mailing list for discussing issues specific 
to the San Francisco Bay Area and Northern California in general:


https://lists.openstreetmap.org/listinfo/talk-us-sfbay/

You're welcome to join regardless of where you live or map, but be 
forewarned that you may have to put up with hyperlocal discussions at 
times. ;-)


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] South Bay community meetup, Sept. 23 in San Jose

[Minh Nguyen]

We're (re)starting an OpenStreetMap community in the South Bay, starting 
with a meetup in San Jose next month. Code for San Jose is sponsoring 
the event as part of the National Day of Civic Hacking.


Please RSVP and invite anyone you know who might be interested in OSM. 
Here are the details:


Saturday, September 23, 2017
10:00 AM to 5:00 PM

The Tech Museum Design Challenge Learning Institute
145 West San Carlos Street, San Jose, CA
https://www.openstreetmap.org/way/499736149

More information:
https://www.meetup.com/Code-for-San-Jose/events/242474711/

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pittsburgh neighborhood boundaries mapped with admin_level 9?

[Minh Nguyen]

On 25/08/2017 12:18, OSM Volunteer stevea wrote:

The point of admin_level is that each member in the hierarchy is a distinct "government" offering 
specific government services by the consent of the governed.  (By several-years-ago OSM consensus, 
special-purpose districts like parks, schools, COGs or MPOs don't get tagged with admin_level).  I very much 
like the way Minh Nguyen describes "Municipal Subdivisions" (below Municipalities or cities/towns) 
in WikiProject_United States/Boundaries:  "Where these subdivisions serve as a system of general-purpose 
units of government with well-defined boundaries, they are tagged boundary=administrative 
admin_level=10."  SOME cities (we agree, and virtually all of them relatively large) truly do have two 
such levels, such as New Orleans which has wards AND neighborhoods, both well-established.  Good we have 9!

In short, larger cities MIGHT have truly administrative neighborhoods, which it 
is emerging in the USA should be tagged admin_level=10.  For cities with two 
administrative subdivisions below cities (like New Orleans), we have and should 
tag both 9 and 10, obviously the lower/lowest gets 10.  In smaller cities, 
especially suburbs, consider mapping (sometimes homeowner association–managed) 
residential subdivisions with landuse=residential ways (often closed polygons), 
omitting admin_level altogether.  Admin_level tagging (especially below 8) 
continues to become better-defined in the USA, and I am pleased to see us 
continue to discuss it well right here.


I'd like to remind the list that the "well-established" New Orleans 
neighborhoods that Steve refers to conflates two concepts. Indeed, New 
Orleans does have well-established neighborhood names, many with 
boundaries defined well enough for inclusion in OSM. There's also a set 
of neighborhood boundaries used for planning purposes by the City 
Planning Commission. [1] The latter are inspired by the traditional 
neighborhoods and boundaries, in exactly the same way that 
census-designated places are inspired by traditional neighborhoods.


Just a couple examples from my own experience:

I was born in what the planning commission apparently calls "Read 
Boulevard East". You would be hard-pressed to find any such designation 
on the ground, and a local will give you a weird look if you refer to 
it. I suppose some New Orleanians do refer to "the Read Boulevard area", 
just as you would refer to the area around any major thoroughfare. But 
in common usage, there aren't precise boundaries for that area and no 
one divides it between east and west.


What you will find on the ground in that area are prominent neighborhood 
entrance signs in the neutral ground of major arterial streets. (These 
signs are posted all over Greater New Orleans, including on the Westbank.)


Eastover: https://goo.gl/maps/pAYqEVc2qn62
Fauberg: https://goo.gl/maps/2XPwuyXXbmy
Idlewood: https://goo.gl/maps/ZfwaroyHDmt
Lake Bullard: https://goo.gl/maps/nM6kHoBZ8tB2
Lake Forest Estates: https://goo.gl/maps/1gafzH6k3TP2
McKendall Estates: https://goo.gl/maps/HmENbSJWxZF2

I've mapped some of these residential neighborhoods as 
landuse=residential areas. When it comes to the less historic parts of 
New Orleans, at least, I think that approach is far more appropriate 
than mapping administrative boundaries based on the planning 
commission's neighborhood boundaries.


[1] https://en.wikipedia.org/wiki/Neighborhoods_in_New_Orleans


SteveA
California
(a big fan of "let's get admin_level as correct as we can in the USA")



From: Peter Dobratz <pe...@dobratz.us>
To: Albert Pundt <roadsgu...@gmail.com>
Cc: "talk-us@openstreetmap.org" <talk-us@openstreetmap.org>
Sent: Thursday, 27 July 2017, 18:29
Subject: Re: [Talk-us] Pittsburgh neighborhood boundaries mapped with admin 
level 9?

(Appologies as I was in the middle of writing my reply when inadvertantly 
hitting send.  Here's the whole message)

Boundaries below admin_level=8 are still being discussed.  There was some 
discussion on this list as well as the OSM wiki

https://wiki.openstreetmap. org/wiki/Talk:United_States_ 
admin_level#Nine_state_ improvement

Having lived in Pittsburgh, I remember that the neighborhood boundaries are 
well defined and many of the street signs have the neighborhood names printed 
across the top of them (epecially on more major roads with bigger signs).

If you were to divide up Pittsburgh into smaller administrative units, how 
would you do it?

Pittsburgh resides within Allegheny County.  Allegheny County is divided into 
Wards and districts, some of which could be used to divide up Pittsburgh:
http://apps.alleghenycounty.us/website/MuniPgh.asp

Pittsburgh city council is made up of 9 people who each represent a council 
district of the city.  It looks like each council district covers a group of 
neighborhoods (that might lend itself to making

Re: [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Minh Nguyen]

On 27/08/2017 06:49, Frederik Ramm wrote:

Here's a list of way IDs affected, with country and state:

http://www.remote.org/frederik/tmp/chdr.details


In case it helps, I dumped this CSV into a spreadsheet and sorted it by 
country and region:




This spreadsheet is currently open for anyone to edit or comment on.

I was primarily interested in two U.S. states, so I dumped the way IDs 
for those states into an Overpass query to get an idea of which part of 
the state would be most affected. The resulting query has a URL too long 
to share, but here's a template you can follow:




Here's how you'd narrow down the results to a particular county:



Some other tips that may be helpful for anyone trying to hand-verify 
these ways:


* Level0 has a box where you can enter a list of way IDs and get their 
tags: 

* Similarly, in iD, type w1234 into the search bar to jump to way 1234.



I hand-reviewed the 63 affected ways in Ohio and 37 in Indiana. Each of 
chdr's edits can easily be explained as one or more of:


1. Expanding preexisting, TIGER-imported abbreviations in name
2. Copying preexisting, TIGER-imported name_1 or name_2 tags to name
3. Copying name tags from nearby streets whose names were imported from 
TIGER


Virtually all the instances of #1 could be filtered out by running the 
preexisting name through the TIGER expansion bot code.


None of the occurrences of #2 matches Google Maps.

Of the occurrences of #3, only one way matches Google Maps. I think that 
was a coincidence, but in any case, both chdr's edit and Google Maps 
were wrong, so I corrected the name.


See the spreadsheet for details on each way in these two states, and 
feel free to perform a similar review for other areas.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Differences with USA admin_level tagging

[Minh Nguyen]

On 11/07/2017 11:46, Kerry Irons wrote:

If all of you want to have some fun with jurisdictional boundaries, take a look 
at College Corner, OH/IN.  It is a village purposefully straddling the OH/IN 
state lines with the main street being the state line.  It has two zip codes, 
is in three counties (two in OH, one in IN) and school district issues to 
match.  It puts paid to a lot of ideas we all have about jurisdictional 
hierarchies and boundaries.  Delmar in Delaware/Maryland has similar, though 
not quite as complicated issues.  I'm sure there are other examples


In terms of administration, West College Corner, Indiana, and College 
Corner, Ohio, are two distinct municipalities incorporated under the 
laws of their respective states, even though they form a single 
community. There's a West College Corner welcome sign as you cross into 
Indiana on U.S. 27. [1]


There are other "twinned" cities along the Ohio-Indiana border -- 
namely, Union City and Harrison (with West Harrison) -- but this is the 
only pair that shares a school district (in practice, if not on paper). [2]


[1] https://goo.gl/maps/R91qvcRj16m
[2] 
https://en.wikipedia.org/wiki/Union_County–College_Corner_Joint_School_District


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Best practice in Singpost Editing

[Minh Nguyen]

On 17/07/2017 02:13, Horea Meleg wrote:

Hello all,

Me and my Telenav colleagues are editing Signposts in Detroit area. We 
were wondering which would be the complete information in this case, 
when a secondary(primary) road and a motorway_link intersect - should a 
motorway_junction tag be added?


42.482377, -83.259498


I assume you're referring to 
. This node should not be 
tagged highway=motorway_junction, because the motorway_link in this case 
is an on-ramp (motorway entrance). highway=motorway_junction is only 
used at the beginning of an off-ramp (exit) -- that is, a link way that 
leads away from the motorway.


However, it is a good idea to add destination and destination:ref tags 
based on any signage you see near the beginning of this ramp. Navigation 
software needs these tags to be used with on-ramps and off-ramps alike.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Differences with USA admin_level tagging

[Minh Nguyen]

On 08/07/2017 12:32, OSM Volunteer stevea wrote:

Kind of long and complex ahead; apologies in advance for the length.

I've been documenting our 
https://wiki.openstreetmap.org/wiki/United_States_admin_level wiki over much of 
the last year with careful research on how US states and territories carve 
themselves up into administrative subdivisions.  My thrust has been how states 
actually do this via their state constitutions, state legislation, real-world 
practice and in some cases on-the-ground signage (e.g. city limit or township 
boundary signs).  Research indicates minor differences in the way that the US 
Census bureau does something quite similar, and as noted in that wiki, OSM 
largely aligns, but there are minor exceptions (e.g. census boundaries in 
Alaska may be valuable enough to keep, but let's not call them administrative 
boundaries, they are not, but it's OK if the Census Bureau does so if we note 
that minor difference and tag in a way we discuss and document).

Whether those results (that wiki and its necessarily complex table and Notes) are fortunate or 
unfortunate, this prompted another OSM mapper (Minh Nguyen, he has kindly given me implicit 
permission to name him and explicit permission to cite his recent WikiProject addition) to create 
"his" https://wiki.openstreetmap.org/wiki/WikiProject_United_States/Boundaries wiki.  
Minh's thrust there has been to carefully document what admin_level tags OSM actually DOES HAVE.  
Even if those tags are "incorrect" in some legal sense, he documents what actually IS in 
the map.  OK, fine:  that is a noble goal and he has largely achieved it with this wiki in short 
order.

Without going through the sausage-making details of the flurry of our recent dialog (in wiki, talk-pages and private 
email exchanges), I am taking Minh up on his offer to "propose a change on the mailing list. Rally the OSM 
community behind your cause. You can even hold up the WikiProject United States/Boundaries page as a testament to how 
incorrect the map is right now."  (I quote Minh exactly there).  By doing so, I hope to generate more light than 
heat, essentially harmonizing both of our efforts and as a result, significantly improving our map.  Perhaps along the 
way, we hopefully better clarify what we mean by consensus:  what "the People" say via law and practice and 
what "we actually do in OSM as we put data into our map."  These are not and should not be fundamentally 
disharmonious, but the distinction seems to have created some friction I'd like to "solve."


Thank you for starting this discussion, Steve. I hope looping in the 
community will get us past the impasse that occurred in private e-mail. 
Whatever the outcome, I hope it'll result in a more accurate wiki. After 
all, the wiki works best when its pages closely reflect the state of the 
map, tagging proposals are clearly marked as such, and retagging 
proposals come with a gameplan. (The wiki has a reputation of being a 
blue-sky wishlist among some software developers, but I'd like to change 
that.)


Just to avoid misunderstanding: the quotes are around "his" because I 
don't own the "WikiProject United States/Boundaries" page, I merely 
wrote the first draft. It and "United States admin level" are two 
different wiki pages with different goals, but anyone can contribute 
towards those goals.



Briefly (re-)stated, Minh characterizes this dichotomy as "prescriptive vs. descriptive." 
 In other words, Minh and I both claim the US_admin_level wiki prescribes how we SHOULD tag 
admin_level in the USA and the US/Boundaries wiki describes how OSM now DOES map them.  Our dialog 
has allowed me to identify specific differences, what appear to be deficiencies in our map, 
actually.  These are limited to nine US states (eight with deficiencies, a ninth with what appears 
to be a deficiency and perhaps an "off-by-one" error).  I now list these issues.

Here are what exist in state constitutions/statutes/the real world, map well 
onto OSM's admin_level scheme, yet do not exist in OSM's data:

Rhode Island 7/Town, 9/Village:  all are marked as 8/City when perhaps some are 
7/Town or 9/Village
Massachusetts 7/Town:  all are marked as 8/City when perhaps some are 7/Town
Maine 6/Unorganized territory and 6/(unincorporated) Plantation
Vermont 8/Village:  all are marked as 8/City when perhaps there are 9/Villages 
in some 8/Cities
Pennsylvania 7/Township, 7/Borough are missing throughout, 8/Town subordinates 
to Borough, 8/Village and 8/Hamlet both subordinate to 7/Township
Connecticut 6/Region (not County), or both?  Harmonize these
Minnesota 7/Township, 7/Town (it appears simply that none have been entered)
Illinois 7/Township, 7/Precinct?

New Hampshire, 8/Town:  shouldn't these be 7/Town (as inTownship)?  Are there 
7/Organized Locations?


I want to call attention to three additional regions, beyon

Re: [Talk-us] Need advice on a project i've taken on

[Minh Nguyen]

On 11/06/2017 16:19, Hans De Kryger wrote:


On Sun, Jun 11, 2017 at 1:38 PM, Shawn K. Quinn > wrote:


What exactly is the rationale behind removing the zip code data?


​The usefulness is nonexistent ​


In the past, I've used these tags to sanity-check addr:postcode tags on 
nearby POIs. I'm aware that ZIP codes are more complex than meets the 
eye [1], although the left/right modeling used in the TIGER import is at 
least consistent with ZIPs-as-routes. It was handy, but there are other 
ways to sanity-check addr:postcode tags anyhow.


[1] https://github.com/iandees/wtf-zipcodes

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] .... finding areas that are underserved

[Minh Nguyen]

On 2016-11-12 14:44, Markus Fischer wrote:

Hi,

I am new to this and the area where I live is very well mapped (probably
due to high density of tech workers). Where do I go to start mapping
areas that are less well mapped (me aimlessly poking at this does not
sound like a good approach)?


The entire state of West Virginia -- no exaggeration. The original data 
imported from TIGER is badly misaligned throughout this state and rarely 
resembles the road network at all. Making matters worse, many public 
roads wind through hollows that even in the best aerial imagery are 
obscured by the surrounding mountains' shadows. Fortunately, newer TIGER 
data (available as an overlay in iD) is very good and makes it possible 
to clean up the mess.


While you're there, West Virginia's hilltop mining roads and power lines 
are much easier to trace from aerial imagery. I personally find mapping 
these features to be a good break from the stress of untangling TIGER roads.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Rail rendering support in our wiki?

[Minh Nguyen]

On 2016-10-24 17:31, OSM Volunteer stevea wrote:

As I also make USA rail contributions, is there any way that our wiki might allow similar 
"layer=rail" syntax to display OpenRailwayMap (.org), for example to display an 
appropriate rendering at the top of our California/Railroads wiki page?


The  tag comes from the Simple Image MediaWiki extension. [1] 
You can specify layer="transport" to get the same rail- and bus-focused 
style as the Transport layer on osm.org. (Incidentally, layer="cycle" 
also works.)


The extension's source code is on GitHub, if anyone is interested in 
improving it. [2] However, at this point, it sure would be nice to be 
able to use the Kartographer extension's slippy maps instead. [3][4]


[1] https://wiki.openstreetmap.org/wiki/Simple_image_MediaWiki_Extension
[2] https://github.com/Firefishy/SimpleMap
[3] https://www.mediawiki.org/wiki/Extension:Kartographer
[4] https://trac.openstreetmap.org/ticket/5431

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another state route shield renderer and tutorial

[Minh Nguyen]

As I mentioned in the diary post, it doesn't handle any of those cases. To be 
sure, there is a regular expression behind the scenes to ensure that Texas Loop 
highways for instance aren't given the us-state shield value. On the other 
hand, there isn't any logic to sort out true edge cases like Arkansas Highway 
43.

I still believe combining that regular expression with the spatial query is a 
step up from the common practice of using only a regular expression, and in 
optimistic that, if nothing else, this demonstration will spur others to keep 
working toward true route relation support.

Minh Nguyễn
Sent from my autocorrect-ennobled device

> On Jul 27, 2016, at 11:43, Paul Johnson <ba...@ursamundi.org> wrote:
> 
> OK, but how does it handle literal edge cases?  Such as WA 433 in Oregon, OK 
> 20 in Arkansas, or AR 43 in Oklahoma?  Or not-so-edge cases such as Texas' 
> infamous multitude of state highway networks, or the two state highway 
> systems in Oklahoma, Kansas and Missouri?
> 
>> On Wed, Jul 27, 2016 at 2:12 AM, Minh Nguyen <m...@nguyen.cincinnati.oh.us> 
>> wrote:
>> A couple days ago, I posted a diary entry about rendering state-specific 
>> highway shields using Mapbox tools. It's a topic of special interest to the 
>> U.S. community, so I figured I'd give the talk-us list a heads-up since not 
>> everyone reads the diaries regularly:
>> 
>> <http://www.openstreetmap.org/user/Minh%20Nguyen/diary/39123>
>> 
>> The diary entry begins with a summary of the arguments for pictographic 
>> shield rendering and the challenges facing renderers that attempt to 
>> differentiate between each state's design. I also argued against using 
>> regular expressions to select state route shields.
>> 
>> I developed a demonstration vector renderer, called Interstate, that 
>> differentiates between the Ohio, Kentucky, and Indiana state route shields, 
>> despite ambiguous `ref=SR 123` tagging in both Ohio and Indiana:
>> 
>> <http://nguyen.cincinnati.oh.us/minh/osm/interstate/>
>> 
>> Though Interstate is only a proof of concept design-wise, it runs on 
>> production servers and mainstream software. The second half of the diary 
>> entry walks you through the steps to create your own, prettier version of 
>> Interstate using free Mapbox tools.
>> 
>> (Full disclosure: I work at Mapbox. But my motivation for posting the 
>> tutorial is to nudge the community away from relying on regular expressions 
>> to select shields and towards eventually using route relations for that 
>> purpose.)
>> 
>> For now, I continue to point people to 
>> <http://elrond.aperiodic.net/shields/> when I want to show them what route 
>> relations are good for, but Interstate is another option when the issue of 
>> way `ref` formats comes up.
>> 
>> -- 
>> m...@nguyen.cincinnati.oh.us
>> 
>> 
>> ___
>> 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

[Talk-us] Another state route shield renderer and tutorial

[Minh Nguyen]

A couple days ago, I posted a diary entry about rendering state-specific 
highway shields using Mapbox tools. It's a topic of special interest to 
the U.S. community, so I figured I'd give the talk-us list a heads-up 
since not everyone reads the diaries regularly:




The diary entry begins with a summary of the arguments for pictographic 
shield rendering and the challenges facing renderers that attempt to 
differentiate between each state's design. I also argued against using 
regular expressions to select state route shields.


I developed a demonstration vector renderer, called Interstate, that 
differentiates between the Ohio, Kentucky, and Indiana state route 
shields, despite ambiguous `ref=SR 123` tagging in both Ohio and Indiana:




Though Interstate is only a proof of concept design-wise, it runs on 
production servers and mainstream software. The second half of the diary 
entry walks you through the steps to create your own, prettier version 
of Interstate using free Mapbox tools.


(Full disclosure: I work at Mapbox. But my motivation for posting the 
tutorial is to nudge the community away from relying on regular 
expressions to select shields and towards eventually using route 
relations for that purpose.)


For now, I continue to point people to 
 when I want to show them what 
route relations are good for, but Interstate is another option when the 
issue of way `ref` formats comes up.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Common names of highways do not match road signs.

[Minh Nguyen]

Kevin Morgan  writes:

> 
> 
> Here is an idea. An additional tag is added called signage. The tag use
the following format  name;ref;text. Each item is added to the tag if the
information is in clued on road signs. The tag has the following sub tags
color, icon, description, direction and text. The text sub tag is used to
add additional text that is not a part of the name or ref. For example the
city a road way leads to often include on a road sign. Description is for
descriptive information that needs to be interpreted by a person rather map
generation software. Direction is north,south, east,west. 

There is a separate tagging scheme for destination and directional
information. [1] Many major highways have been tagged this way. Hopefully
OSM-based navigation software would begin to make use of these tags, because
relying solely on names and refs on ways would lead to a lot of missed
turns, regardless of the criteria for using the `name` tag.

[1] http://wiki.openstreetmap.org/wiki/Exit_Info

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

Re: [Talk-us] Common names of highways do not match road signs.

[Minh Nguyen]

Paul Johnson  writes:

> 
> On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan
 wrote:It is confusing
to use open street maps in my area(Central Ohio) for
> driving directions since the "common names" of high ways do not match
> road signs. The common names are used by open map chest for road names.
> For example when turning on to State Route 315 with OpenMapChest loaded
> on my GPS I am directed to turn on to Olentangy Freeway. However the
> tiger name on open street maps is State route 315. Would it make more
> sense to configure driving maps to use tiger names for driving
> directions,  change commons names to include the state route number or
> interstate number, or add state route number/ interstate number as a
> different tag?
> 
> 
> ref=* isn't name=*, don't tag for the renderer.  I'd go with the official
name for name=*.  If you're inclined to do something like, name=State Route
315, you really want ref=OH 315.

You mean `ref=SR 315` and "don't tag for the router". ;-)

The established tagging conventions are designed so that any software that
needs to say something more sophisticated based on the route designation
would parse `network=US:OH` and `ref=315` from the associated route relation
and expand it into "State Route 315". You can find out more about tagging
Ohio route relations on the wiki. [1] The TIGER name Kevin refers to is a
vestige of an import; it isn't customary to tag this way when mapping by hand.

Ohio's DOT makes a point of avoiding names for any Interstate or state route
on signage, in favor of listing control cities. This is different than, say,
Kentucky, which tends to place the highway name next to the route marker on
overhead guide signage.

But Ohio highways still often have official names which are still known
locally, even if they aren't signposted. One example in the Cincinnati area
is the freeway portion of SR 562. The official name is "Norwood Lateral
Expressway", and Cincinnatians universally refer to it as the "Norwood
Lateral", to the point that pretty much no one knows what "SR 562" refers
to. It's clear that `official_name=Norwood Lateral Expressway` and
`loc_name=Norwood Lateral` would be appropriate. `unsigned_name=Norwood
Lateral` is another option.

(Incidentally, a nearby highway was exempted from ODOT's policy after being
renamed for Ronald Reagan. So the signs do include the road name. [2])

If you take the position that `name` should reflect signage, perhaps because
finding signage is more verifiable than asking someone at the nearby gas
station, then `name=Norwood Lateral` would clearly be inappropriate. (A part
of the world that doesn't signpost this way must look rather bare on the
map.) On the other hand, if your reasoning is that `name` should be whatever
name is most useful to someone attempting to use OSM for navigation, then
"Norwood Lateral" isn't entirely useless for that purpose. (You'll never
hear "562" on the traffic report.)

[1] http://wiki.openstreetmap.org/wiki/Ohio/Route_relations
[2] https://en.wikipedia.org/wiki/Ronald_Reagan_Cross_County_Highway

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

Re: [Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

[Minh Nguyen]

On 2016-07-05 10:08, Peter Dobratz wrote:

After arriving at a local drugstore chain with a prescription in hand,
walking past the shampoo aisle, only to find that the pharmacy counter
is closed for the day, I've been updating tagging of drugstores and
pharmacies as described here.

For example, there is a Walgreens:

http://www.openstreetmap.org/way/266495943

The building outline has shop=chemist.

Inside the building, there are 2 Nodes, one for the pharmacy and one for
a clinic:

amenity=pharmacy
dispensing=yes
drive_through=yes
http://www.openstreetmap.org/node/4064469934

amenity=doctors
http://www.openstreetmap.org/node/4064469933

In this case, all of these entities have different opening hours.  Other
contact info like phone and website may be different as well.


This is the approach that's been proposed informally, and iD's change 
would be a part of it. But I don't see how this practice becomes 
commonplace with the shop=chemist preset being labeled "Drugstore" and 
no other UI changes. Where's the reminder to also map the pharmacy 
counter or clinic if the store has one?


There's certainly something to be said for micromapping a drugstore as a 
collection of counters with different opening hours, just as one might 
micromap a supermarket with its florist and bakery, or a department 
store with its café and photography studio. At the same time, the 
pharmacy counter is the defining characteristic of an American 
drugstore. That's why the largest U.S. chain signs each of its stores 
with the name "CVS Pharmacy" (except for the handful that lack pharmacy 
counters). A renderer or search engine that conflates a drugstore with 
its pharmacy counter isn't doing as much a disservice as one that omits 
the pharmacy counter because the mapper didn't know to add one.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

[Minh Nguyen]

On 2016-07-05 08:45, Minh Nguyen wrote:

This change to iD came about due to a discussion in the Name Suggestion
Index project, which is the component in iD that suggests tags when you
fill in a commonly used name. [2] I happened to notice the change
because it caused Transifex to prompt me to update iD's Vietnamese
localization. To my knowledge, there has been no discussion on the
mailing lists or formal proposal on the wiki, though the iD maintainer
intends to edit the wiki to match iD's interpretation. iD is the only
software that has made this change.


Sorry, I got a little ahead of myself there. iD's maintainer assures me 
he won't be the one to edit the wiki. :-)


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

[Minh Nguyen]

Recently, iD was changed so that shop=chemist is labeled as "Drugstore" 
for American English users (and continues to be labeled "Chemist" for 
British English users). [1] An American mapping a Walgreens, CVS, or 
Rite Aid who searches for "drugs" will see the following choices, in order:


* Drugstore (shop=chemist, marked with a shopping cart icon)
* Pharmacy (amenity=pharmacy, marked with a pill bottle)

Meanwhile, searching for "pharmacy" -- a synonym of "drugstore" in 
American English -- produces only the amenity=pharmacy preset.


The rationale is that amenity=pharmacy should be used only for pharmacy 
counters (which can be found at both drugstores and inside 
supermarkets), while shop=chemist should be used for full-service 
drugstores that *may* contain pharmacy counters. Currently, this is at 
odds with the wiki and longstanding practice, which stipulates that a 
shop=chemist *may not* fill prescriptions.


This change to iD came about due to a discussion in the Name Suggestion 
Index project, which is the component in iD that suggests tags when you 
fill in a commonly used name. [2] I happened to notice the change 
because it caused Transifex to prompt me to update iD's Vietnamese 
localization. To my knowledge, there has been no discussion on the 
mailing lists or formal proposal on the wiki, though the iD maintainer 
intends to edit the wiki to match iD's interpretation. iD is the only 
software that has made this change.


On the one hand, I've come around to liking the proposal, because it 
makes it easier for data consumers to distinguish between pharmacy 
counters and full-fledged drugstores. On the other hand, I think it's 
problematic because an American mapping a Walgreens or CVS could 
potentially tag a "drugstore" and be unaware that they'd need to 
separately map the pharmacy counter in order to indicate that 
prescriptions may be filled on-site.


Currently, amenity=pharmacy is far and away more common than 
shop=chemist in the U.S. as a way to tag drugstores. Certainly anyone 
retagging amenity=pharmacy to shop=chemist would be careful to add an 
additional amenity=pharmacy POI where the pharmacy counter would be. 
(For a typical Walgreens or CVS, it'd be next to the drive-through 
canopy.) However, I have little faith that the average iD user would 
know to do the same, since the word "drugstore", like "pharmacy", 
implies the sale of prescription drugs.


I've hashed out many of these points in [3], but I think the discussion 
needs to involve the wider OSM community now. There's little chance of 
data consumers and other editors updating their logic if the change is 
only discussed in the iD project.


[1] https://github.com/openstreetmap/iD/issues/3201
[2] https://github.com/osmlab/name-suggestion-index/issues/30
[3] https://github.com/openstreetmap/iD/issues/3213

--
m...@nguyen.cincinnati.oh.us


___
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

[Minh Nguyen]

On 2015-11-13 02:42, Paul Johnson wrote:

On Sun, Nov 8, 2015 at 8:04 PM, Paul Norman
> wrote:

On 11/7/2015 10:18 AM, Kevin Kenny wrote:

I find lately that it needs a patched Mapnik, because Mapnik
(sensibly)
went to a read-only database connection, and one of Phil's stored
procedures modifies the database the first time that a shield
cluster
is requested. One of these times I'll fix it.

I'm a little disappointed that none of the 'standard' renderers
picked this up.


Phil's demo was an excellent proof of concept of pictorial shields
from route relations, but isn't something that can be reasonably
incorporated into a stylesheet as-is.
https://github.com/gravitystorm/openstreetmap-carto/issues/596 is
the OpenStreetMap Carto issue for shields from relations,
https://github.com/gravitystorm/openstreetmap-carto/issues/508 is
the one for pictorial shields.


There's been a lot of productive talk thus far about potentially moving
this forward, but I'm curious if it makes any difference if we preserve
the existing legends for ref right now, but start rendering the route
relations for the existing style legends where available and just skip
shields until a viable read-only method is developed on the back
burner.  Or is the problem not necessarily depending on shield legends
but something more central?


I'm not very familiar with the toolchain involved here, but this is what 
I gather after racking my brain on the issue for some time:


osm-carto and lots of other styles rely on osm2pgsql to import OSM data 
into a Postgres database. There's already rudimentary support in 
osm2pgsql for generating geometries based on route relations. 
Specifically, it reads in each cycling or walking route and turns it 
into a linestring that coincides with the member ways.


This is fine for OpenCycleMap, which represents routes as translucent, 
badged overlays on roads and trails. But that won't necessarily work for 
road shields. You have to somehow conflate shields on ways with shields 
on the overlaid route. My impression is that that could be expensive, 
though I haven't looked deeply into it. So you'd have to ignore all refs 
on all ways, which could be a nonstarter in parts of the world that have 
yet to see the relation light.


So this osm2pgsql issue asks for a way to apply the relation's tags on 
the member ways:


https://github.com/openstreetmap/osm2pgsql/issues/230

It's a great idea, but it depends on keeping all potential route member 
ways in memory until the relations are all done processing. Or issuing 
lots and lots of UPDATEs. Either way, it sounds expensive, but I really 
hope I'm wrong.


At a higher level, this openstreetmap-carto ticket covers the overall 
enhancement:


https://github.com/gravitystorm/openstreetmap-carto/issues/596

The question then becomes: what sort of shield do you display? Obviously 
switching to pictoral shields is a large undertaking in itself, due to 
the amount of artwork required. But if we instead stick to the textual 
badges for now, we have some additional complications: in the U.S., a 
badge with just a number is horribly ambiguous. Out in Logan County, 
Ohio, there's a state route, county route, and township route all with 
the same number, and two of them intersect.


http://www.openstreetmap.org/relation/184351
http://www.openstreetmap.org/relation/2599900
http://www.openstreetmap.org/relation/2605494

So we need alphabetic prefixes on badges. Unfortunately, it isn't 
straightforward to map `network` values to familiar alphabetic prefixes:


network=US:I  => I ###
network=US:US:Business=> US ### Business
network=US:CA => CA ###
network=US:OH => SR ###
network=US:TX:Beltway => Beltway #
network=US:KY:Parkway `short_name`?
network=US:NY:Onondaga=> CR ###
network=US:OH:MED:Harrisville => T-###

Then there's the issue of concurrencies, where the relations aren't in 
any particular order. You'd need rules for prioritizing one network over 
another in badges or shields. The best heuristic I've come up with is to 
sort by the number of colons, but that doesn't work in Europe (where 
they don't use the same format) or even for some of the examples above.


So in short, it's complicated, and that conclusion comes from someone 
who's both enamored with route shields and very naïve. But no one said 
it was easy. :-)


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Self Storage Places

[Minh Nguyen]

On 2015-10-04 00:59, Paul Johnson wrote:

One could argue for industrial since we're talking about rental
warehouse space.  Is there a shop or (ugh) amenity for this?


I've never been quite sure how to tag self storage facilities. Taginfo 
[1] shows significant usage of the following tags, each of which I've 
probably tried out at some point:


amenity=self_storage
amenity=storage
building=self_storage
building=storage
building:use=storage
landuse=self_storage
landuse=storage
man_made=storage
shop=self_storage
shop=storage
shop=storage_rental
shop=storage_units

So yeah, some consensus would be great...

[1] http://taginfo.openstreetmap.org/search?q=storage#values

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

[Minh Nguyen]

On 2015-10-03 07:45, Mike Thompson wrote:


By removing access=private you would be removing a valuable piece of
information. Maybe the community can come up with a better tag, but we
should not just delete the "private" tag.


How do people here feel about using access=destination on driveways that 
aren't posted? It more or less captures "who is allowed", if not "who 
owns the road". The tag is designed for streets posted with "no through 
traffic" signs, but that's pretty much what's been described in this thread.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

[Minh Nguyen]

On 2015-10-03 16:58, Greg Troxel wrote:


What's wrong with the private tag?  Is the only objection that it shows
up pink on the map?  That's a clue that the rendering is wrong, not the
tag.


I was asking more out of curiosity. Personally, I'm fine with the way 
access=private driveways are rendered, and tagging driveways off 
cul-de-sacs as access=private matches how I tag the parking lots of 
apartment complexes and corporate headquarters.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

[Minh Nguyen]

On 2015-09-30 08:34, Greg Morgan wrote:

On Mon, Sep 28, 2015 at 8:48 AM, Toby Murray  wrote:

I run into this as well. If I don't see anything close to the way on
imagery I definitely have very little problem deleting them.

I also question the access=private tagging although not because of the
rendering. I mean technically it is correct I suppose but if you are
trying to route to an address at the end of a long driveway, the
router should tell you to go down the driveway. Tagging it as



If this really is true, then perhaps you should file a bug report.  If
I accurately map a residential gated community with access=private,
show the gates, then wouldn't that be more valuable to set what
expectations are required to get into the area.
http://www.openstreetmap.org/way/16842943#map=18/33.78757/-111.98892


Toby is suggesting that service=driveway should imply access=destination 
unless otherwise specified. The wiki is full of statements that one tag 
implies another tag. For example, highway=motorway_link implies 
surface=paved. [1]


But you do have a point: a router could route over access=private and 
access=destination if there's no other possible route, yet avoid 
access=private otherwise (to avoid riding roughshod over a private drive 
that happens to make a good shortcut). The user interface would have to 
make clear that the route includes a private drive, similar to the toll 
road warnings that some routers give.


[1] http://wiki.openstreetmap.org/wiki/Tag:highway=motorway_link


Who are these data consumers that you speak of?  If they are
freeloaders, I could careless about them.  One of shifts that I have
noticed over the years is that we appear to no longer care about what
mappers do or how we improve the ecosystem for mappers but I hear all
about data consumers.  The data consumers need to adapt to OSM and not
the other way around.


Data consumers are part of the OSM ecosystem; we don't map in a vacuum. 
All the renderers and routers available from the osm.org front page are 
data consumers, after all. For better or worse, renderers and routers 
already "adapt to OSM" by normalizing diverse tagging styles and 
preprocessing away common errors. (A highly opinionated data consumer 
would fail to support a good chunk of the dataset.) That's not to say 
the current crop of routers is unimpeachable, but I don't think they 
should be viewed in an adversarial light.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] what happened to Sacramento?

[Minh Nguyen]

Jack Burke  writes:

> 
> You're not crazy. Just using the regular OSM website interface, I can find
the city node, and the county boundary, but not a city boundary. AFAICT, it
isn't a consolidated city-County, so it should exist. 

Looks like the original TIGER boundary way got deleted back in 2010, and I
can't find any traces of ways that superseded it:

http://www.openstreetmap.org/changeset/4084221

As a first step, I undeleted that way using Potlatch 1:

http://www.openstreetmap.org/way/33135846

Now it needs to be turned into a relation and integrated with the adjacent
boundary ways.

-- 
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

[Minh Nguyen]

Nate Wessel  writes:

> 
> 
> I delete plenty of TIGER driveways myself (mostly in the midwest,
> *highfive*!), but I wouldn't say that the accurate ones should be
> removed. If they can be identified as private driveways, they could
> more easily just not be rendered on a map with no loss of accurate
> data for people who might find that sort of thing useful. My general
> approach has been to leave the truly accurate ones untouched, but to
> delete anything who's deletion leaves the map more accurate. I just
> don't feel inclined to redraw them.
> I should specify, this is my (personal) policy only for untouched
> TIGER imports.

*Highfive!*

I'd only add that, while I've never found it a priority to map most
driveways, I do try to map every shared driveway I encounter. (I look for at
least two houses attached to the same driveway.) Shared driveways are the
rural/suburban functional equivalent to urban alleys, and some subdivisions
are chock full of them. I'd want routers to be able to direct their users a
bit beyond the mailbox in those cases. To me, shared driveways are less
tedious to map and more important for routing than aisles in parking lots.

-- 
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

[Minh Nguyen]

Marc Gemis  writes:

> 
> 
> They can be mapped, especially the long ones and tagged as
highway=service, service=driveway, and typically access=private.I don't care
for the appearance of the map, it's more important to connect houses that
are further away from the main road via the proper driveway to allow
navigation to the front door.
> They have been mapped in several places around the world, also in places
where there was no Tiger import.

The Standard style omits service=driveway until z16, whereas ordinary
highway=service shows up at z13. At z16, you're close enough to see any
other micromapping that might take place around the house, like fences and
backyard swimming pools. :-)

-- 
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

[Minh Nguyen]

On 2015-09-17 15:56, Toby Murray wrote:

I went through and upgraded all roads marked as "Minor collectors" and
"Major collectors" from residential to tertiary. The result can best
be seen at zoom level 12:
http://www.openstreetmap.org/relation/1070359#map=12/39.4386/-96.7724


This area looks pretty reasonable to me, except for some disconnected 
tertiaries in Fancy Creek State Park. [1]



There are a few places where I diverged from the map a bit. For
example the city of Riley has no collectors marked on the KDOT map but
I still bumped the main road through it to highway=tertiary. There
were a couple of places where I didn't really think an upgrade to
tertiary was warranted but at the time I just went with it anyway.


In cases like this, I would probably go with my own intuition. In places 
I've mapped, the DOT is less concerned about making a hierarchical map 
than about allocating funding based on the official route network. But 
it sounds like KDOT is really good about classifying based on the same 
criteria as us mappers, in which case HFCS makes for a great secondary 
source.


[1] http://www.openstreetmap.org/way/295768204

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

[Minh Nguyen]

On 2015-09-06 01:24, Toby Murray wrote:

This user has also upgraded a lot of unpaved county roads in eastern
Kansas to secondary because of HFCS which also strikes me as wrong.
You can clearly see where he has done this at zoom level 9 [6].


When I started mapping in San Jose, CA, after years of mapping in 
Cincinnati, I encountered similar problems with highway classifications. 
There were `highway=secondary` ways that, in reality, are tree-lined 
residential roads with 25 mph speed limits, Child at Play signs, and 
unsignalized crosswalks. Presumably that's because they're designated 
"major collectors" in HFCS. Residents along those streets would probably 
disagree.


Parts of downtown San Francisco and downtown Houston consist entirely of 
`highway=primary` ways with a few `highway=service`s sprinkled in. That 
kind of classification doesn't seem incredibly useful for routing, and 
it makes it more difficult to establish a visual hierarchy when styling 
a map.


In the Cincinnati area, we reserved `secondary` for good cross-town 
roads, for consistency with `secondary` state routes in rural areas. We 
demoted a grand boulevard (Central Pky., an HFCS "principal arterial" 
that's part of three U.S. routes) from `primary` to `secondary`, because 
a nearby Interstate has long obsoleted it for cross-town travel.


As I recently argued in a diary entry [1], high road classifications, 
along with umbrella landuse areas, mean that potential contributors 
won't see a blank slate where they probably should (since there may be 
little other than streets). Can we tone down these cities a bit? I think 
it would help the project.


I've come to the same conclusion as NE2 [2] that we should classify 
roads "from scratch" on a case-by-case basis and only consider systems 
like HFCS as a hint, just as we treated the TIGER import's 
classifications as a starting point. We have enough information before 
us, including aerial imagery and the overall road topology, to 
contradict HFCS when necessary.


[1] 
[2] 

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

[Minh Nguyen]

On 2015-09-06 09:49, 
richiekenned...@gmail.com wrote:

As to Mr. Fairhurst’s comment regarding routing, I’ll remind you it is
frowned upon to tag for a routing engine.


There is often confusion about the "don't tag for the x" rule. We must 
not tag *misleadingly* for a *specific* x. We absolutely should consider 
the needs of all x's in existence. [1]


[1] http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] TIGER tracing layer updated to 2015 release

[Minh Nguyen]

On 2015-08-25 20:48, Greg Morgan wrote:

I clicked on the link you provided and received:
{message:Not Found}


Hi Greg, this URL template isn't meant to be opened directly. You can 
paste it into an editor's custom layer URL field; the editor will fill 
in the {x}, {y}, and {z} variables for each tile on screen.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Rendering of tracks

[Minh Nguyen]

On 2015-08-25 19:07, Mark Bradley wrote:

I noticed that tracks (leisure - track) are still being rendered as
polygons instead of linear features, despite this having been reported
as a bug on Github.


Hi Mark, I'm not sure if the openstreetmap-carto developers read this 
mailing list. I believe you're referring to this GitHub issue:


https://github.com/gravitystorm/openstreetmap-carto/issues/574

When it comes to software like the openstreetmap-carto stylesheet, an 
issue gains more traction when someone steps forward with proposed 
source changes in a pull request. For this particular issue, it sounds 
like the developers are waiting for community consensus about how 
leisure=track should be mapped. Here's some recent discussion:


https://wiki.openstreetmap.org/wiki/Talk:Tag:leisure%3Dtrack

It may also be helpful to start a thread on the tagging@ list, if there 
isn't already one.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Survey Township Sections

[Minh Nguyen]

On 2015-08-02 06:43, Jerry Clough - OSM wrote:


A quick question: Are there any guidelines for tagging of public land
survey township sections?
I found a clear description of mapping civil townships for Ohio on the
wiki: http://wiki.openstreetmap.org/wiki/Ohio/Boundaries/Townships, but
have failed to find anything on survey townships and their sections.


Civil townships are being mapped because they correspond to actual 
governmental structures that have definite boundaries. Survey townships 
themselves don't have governments, so there's less of a case for putting 
them in OSM, especially where the boundary between one section and 
another is unclear from aerial imagery or on-the-ground observation.


In any case, if you map survey townships and sections, avoid using the 
boundary=administrative tag. Something like boundary=survey would be 
more appropriate.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Naming Ramps

[Minh Nguyen]

On 2015-07-30 13:51, Paul Norman wrote:

On 7/30/2015 7:15 AM, Brett Lord-Castillo wrote:

Related to this, I also wanted to look for some ideas on how to
generate names for the unnamed ramps in an OSM extract.

Most ramps in parts of the US I've traveled don't have name. What they
do have is destinations, which indicate the information on the signs.


Incidentally, the Ohio Department of Transportation does post a blue 
sign on every highway ramp, bearing a heavily abbreviated (devowelized, 
actually) name of the ramp, for example:


Ramp
E 275
 To
N 75

or:

  Ramp
  E 275
   To
Lvldmdra

In cases where the ramp belongs to multiplexed routes, you may see 
multiple ramp name signs side by side: http://www.roadfan.com/3bluemrk.JPG


These signs are specifically intended to help motorists pinpoint their 
location when calling for help. (If emergency responders look for the 
wrong ramp in a given junction, they might end up wasting precious 
minutes trying to circle back.)


I've been hesitant to put these names in the `name` tag because they 
clutter up ordinary use cases like map display and navigation. I'm 
inclined to use `official_name` here and expand all abbreviations (per 
OSM convention).


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pequot Terrace

[Minh Nguyen]

Clifford Snow clifford@... writes:

 
 I'm vacationing near Nisswa, MN. In the city of Nisswa, there is a hamlet
node for Pequot Terrace just a short distance from the City of Nisswa node.
As far as I can discover, there is no Pequot Terrace
here. http://www.openstreetmap.org/node/151467331
 Since I don't live in Minnesota, I'd like to hear from some locals if it
is ok to delete the node. It was imported from GNIS in 2007 with a
modification a year later to add the county. 

Apparently it’s a retirement community:

http://pequotterrace.com/

The GNIS import brought in lots of mobile home parks, housing projects, and
retirement communities as hamlets. If you can figure out where in Nisswa
that community is located, a landuse=residential area might be in order.

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

Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER

[Minh Nguyen]

On 2015-06-13 17:08, Harald Kliems wrote:

Very nice, Richard! One quick comment: I might not be the only who
doesn't always change the tiger:reviewed tag when fixing TIGER-imported
roads. I don't know if that's technically feasible, but maybe it would
be better to check if a way has been modified since import, independent
of the tiger:reviewed tag. I guess you could assign those a slightly
lower priority than the ones that have tiger:reviewed=yes.


You aren't alone. I stopped bothering with tiger:reviewed tags back in 
the Potlatch 1 days. It just isn't a well-designed tag:


- not very discoverable to mappers who weren't around in 2008
- not automatic enough
- doesn't say whether the names, classification, or geometry was 
reviewed, or whether the review covered the entire way


I think we generally treat tiger:* tags as cruft these days. (I 
sometimes use tiger:name_* in cleaning up erroneously merged ways or 
ways lossily unduplicated along county lines, but that's about it.)


On the other hand, ways without tiger:reviewed tags are more likely to 
have been entered by hand or rigorously reviewed, so it does make sense 
to reward such ways. But I think it'd be unfortunate to totally discount 
tiger:reviewed=no ways.


FWIW, I also leave a lot of usable paved roads as highway=residential in 
rural areas, but there are plenty of considerations that vary from 
region to region (even within a state).



On Sat, Jun 13, 2015 at 1:38 PM Richard Fairhurst
rich...@systemed.net
mailto:rich...@systemed.net wrote:

Hi all,

At State of the Map US last weekend I was really pleased to unveil
bicycle routing for the US (and Canada) at my site, cycle.travel
http://cycle.travel.

The planner, at http://cycle.travel/map , will plan a bike route for you
between any two points - whether in the same city or on opposite sides
of the continent. It's all based on OSM data but also takes account of
elevation and other factors.

I dogfooded it with a three-day ride around New York state after
SOTM-US, and it found me some lovely quiet roads in and around the
Catskills. I hope it'll be equally useful for the other two-wheelers
amongst us. There's still a lot I want to add (as detailed at
http://cycle.travel/news/new_cycle_travel_directions_for_the_us_and_canada)
but I hope you enjoy it.

Plug aside, there's a couple of things might be relevant to US mappers.


First of all, I'm aiming high with this - the aim isn't just to make the
best OSM-powered bike router of the US, but the best bike router full
stop for commuters, leisure cyclists and tourers. (I leave the
athletes to Strava!)

Here in Britain, experience over the years has been that good bike
routing and good bike cartography - historically via CycleStreets and
OpenCycleMap - are a really effective way of driving contributions to
OSM. So if you know cyclists who aren't yet contributing to OSM, maybe
throw this at them - and if it doesn't find the route they'd recommend,
maybe there's some unmapped infrastructure they could be persuaded
to add!


Second, the routing and cartography both heavily distrust unreviewed
TIGER.

In other words, it won't route over a rural road tagged as
 highway=residential
 tiger:reviewed=no

Any road with tiger:reviewed removed or altered, any road in urban
areas, and any road with highway=unclassified or greater is assumed to
be a usable paved road. (There are a few additional bits of logic but
that's the general principle.)

Unreviewed rural residentials are shown on the map (high zoom levels) as
a faint grey dashed line, explained in the key as Unsurveyed road.

I've been finding this a really useful way of locating unreviewed TIGER
and fixing it... it's actually quite addictive. :) Looking for roads
which cross rivers, or with long sweeping curves, is an easy way of
identifying quick wins. My modus operandi is to retag 2+-lane roads with
painted centrelines as tertiary, smaller paved roads as unclassified,
and just to take the tiger:reviewed tag off paved residential roads.
Anything unpaved gets a surface tag and/or highway=track.

I can't promise minutely updates I'm afraid - the routing/map update
process takes two full days to run so it'll be more monthly than
minutely. But I hope you find it as useful as I do. You'll see there's a
tiny little pen icon at the bottom right of http://cycle.travel/map
which takes you to edit the current location in OSM.


Finally, many thanks to everyone who's tested it so far, particularly
Steve All - your feedback was and continues to be enormously useful.

cheers
Richard

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

Re: [Talk-us] a plea to armchair mappers

[Minh Nguyen]

On 2015-06-11 06:42, Richard Welty wrote:

please, please when doing the armchair mapping thing, be aware
that aerial imagery may be several years out of date.

yesterday i discovered that a highway reconfiguration i'd mapped
in Rensselaer, NY had been realigned with the out-of-date bing
aerial imagery. i was able to locate my GPX tracks and put it back,
but i still had to revisit the site to re-verify some connecting roads.

i had even put a README tag on the roads warning that the
imagery was out of date, but the armchair mapper didn't bother
to, you know, read the README.


With both outdated imagery and the Ohio River [1], I've had better luck 
placing redundant `note` tags on every way that such a mapper would be 
inclined to delete. iD shows `note` in a big box in the sidebar. It's a 
bit harder to miss than a (heretofore) ad-hoc tag that would be 
relegated to the All Tags section. Potlatch 2 doesn't support anything 
like it, unfortunately.


If it gets really bad, you could try spelling out DO NOT ERASE in 
aerialway=contrail ways. :-P


[1] http://wiki.openstreetmap.org/wiki/Ohio_River

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Facts about the world

[Minh Nguyen]

On 2015-04-03 22:25, Russ Nelson wrote:

Greg Morgan writes:
   * In my case, TIGER isn't all the that bad.

In some NY counties, TIGER is very good. In other places it is like
Stevie Wonder was in charge of quality control. What I've heard is
that the maps they were digitizing off were of MUCH lower resolution
than we have available now.


I wonder if it was even about the resolution in some counties. It's as 
if the data was traced off a cartogram, or maybe reconstructed from a 
table of intersections.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

[Minh Nguyen]

On 2015-04-04 05:23, Serge Wroclawski wrote:

On Sat, Apr 4, 2015 at 12:31 AM, Russ Nelson nel...@crynwr.com wrote:

Brad Neuhauser writes:
If you want to know how serious abandonfans are, I've see people go
looking in farmer's fields with a metal detector looking for spikes,
and dig down 12 to find one. I've seen people go into a farmer's field
looking for chunks of coal that fell off coal trains. I've knocked on
people's doors to ask them if they know anything about the railroad in
their backyard.


That shows an incredible level of dedication, but in OSM we generally
don't require specialized equipment to contribute, including
validation.


The evidence of dismantled railroads is out there, and it should be in
OSM to help people find it.


What would you do about someone who was cleverly adding tracks that
didn't exist?

Imagine if there was a vandal who was clever. We'll call this vandal
User V. User V decides to have a bit of fun and makes dismantled
railroad ways.

How do you propose we, as a community, handle User V? My normal way of
handling such a matter, in or out of a DWG context, would be to go to
the place and see if I see what they see. But my understanding from
your mail (and you can correct me if I'm wrong) is that I personally
have the expertise to make that determination?

Who does? What makes one mapper more qualified than another mapper?
This question gets to the heart of this project, which is that we
don't make people take tests to map in OSM. This is such a generalist
project that anyone can contribute. Now you're saying that, in
essence, some features can only be evaluated by certain users.

I don't think that's really what you mean, but that's what I'm hearing.

Let me reframe the question. Instead of Yes they should be in OSM or
No they shouldn't be in OSM, here's the new question:

If a user deleted an object that a layperson can't see in OSM, what do
you think the process be for evaluating that edit should be?


I appreciate your emphasis on verification. The community necessarily 
puts in a lot of effort into data integrity, but we don't really promote 
the more manual side of QA. As OSM grows in profile, our defenses 
against vandalism will increasingly be tested. Personally, I don't find 
ground verification to be nearly as fun as mapping, but if someone's 
going to volunteer to do that work, we shouldn't throw needless 
obstacles in their way.


We should assume that verifiers are every bit as diverse as the OSM 
community at large, rather than a lowest common denominator group of 
laypeople. I'd be much better at verifying administrative boundaries 
than mountain biking trails. You shouldn't trust me to make good calls 
on mtb:scale= values, but don't stop a skilled cyclist from using that 
important tag and another skilled cyclist from verifying it.


On the other hand, mappers who feel the need to rely on detective work 
should document that work, for example by adding a note= tag or 
accompanying that railway=abandoned with some additional clues. If it 
really comes down to spikes you've dug out of the ground, an OSM diary 
post with photos can go a long way. We all love a good story!


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Facts about the world

[Minh Nguyen]

On 2015-04-02 17:41, stevea wrote:

Simon Poole writes:

Up to now OSM has drawn the line in such a way that stuff that is
signposted and is observable on the ground is fair game (with some
exceptions, I believe the GR issue is still unsolved).


Yes, all of that is fair game.  Though I don't know what the GR issue
is, and ask you to please clarify.


If you are using
a collection of facts, be it a list, a map, a file on a computer or
whatever, we have to now always taken the, fairly high ground, position
that you either need explicit permission (by agreement, licence or
similar) or that the use of the source is clearly not subject to
copyright any longer. Forgetting about other rights, regulations etc
that may exist for the purpose of this discussion.


When a collection of facts about the world are data published by a
government (around here, those are our employees), ESPECIALLY if/as one
is in a jurisdiction where geo data published by us (via the government)
are explicitly prohibited to be encumbered by copyright or onerous
Terms -- as I do -- then use of those data flowing into OSM should be
absolutely uncontroversial.  As the explicit example I used in the
instant case, road/rail crossing data published by our PUC that became
reverse-engineered names of subdivisions sufficient to tag
nastily-tagged TIGER data (just plain wrong, but better than nothing and
an OK starting place) so they are more correct is a perfectly valid use
of such data.  I believe anybody in any of the 49 other states can do
this, but I am not as familiar with their Public Records Acts (or/stare
decisis/) as I am California's.  Nor am I an attorney.  But I can read
and make these determinations.  In fact, I believe any reasonably
intelligent adult can do so.  If we can't, it is incumbent upon OSM to
help us do better.  Erring on the side of high ground safety might be
a good place to plant an initial flag, but if it's location is wrong and
we need to move it to a more accurate place, we must do so.


Not every state's public records law is as generous as California's. For 
instance, the Ohio Attorney General's office publishes an annual 
Sunshine Laws Manual [1] that interprets the sunshine law as providing a 
right for public inspection and authorized copying of public records, 
but not necessarily a right to create and distribute unauthorized 
derivative works. Assuming that position is correct, we can't 
automatically treat a PUCO publication as a potential import source. 
Unfortunately, Ohio is no exception. That said, I'm nobody's idea of an 
IP lawyer and I'd love to be proven wrong in this instance.


Moreover, I think Simon and Frederik are arguing from the perspective 
that compliance with U.S. copyright law is necessary but insufficient 
for OSM. To European contributors, concerns over copyright are 
compounded by concerns over moral rights and database rights, hence the 
requirement for explicit permission. I'm uncomfortable with the notion 
of imposing European legal restrictions on American imports, but this 
discussion is more about what *should* be included than what *may* be 
included. A Wikipedia administrator would swiftly delete a perfectly 
copyright-free article about your backyard swing set for being 
unencyclopedic; likewise, the OSM community can decide that 
large-scale inclusion of certain outside sources would take the project 
too far from its founding mission.


OSM started out with the do-it-yourself, clean room approach of 
on-the-ground surveying. It offers the strongest guarantee of legal 
compliance and appropriateness for OSM -- no legal analysis required. 
All of us certainly hold such efforts in the highest esteem, but I do 
see an argument for letting contributors be resourceful in other ways, 
to *carefully and judiciously* incorporate other sources, as long as 
they do their best to document their work.


[1] http://www.ohioattorneygeneral.gov/YellowBook

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

[Minh Nguyen]

On 2015-03-31 23:12, Bryce Nesbitt wrote:

For background, in the USA there is an intermediate step to
abandonment.  A corridor can be railbanked,
meaning the easements don't expire.  It's not an active railway, but
it can be returned to rail service
via an administrative procedure.  And in fact, that's happened.
Usually however these become trails,
a process that can take decades.


I'd imagine that most railbanked rights of way would be mapped with 
railway=disused (inactive tracks, possibly overgrown) or 
railway=abandoned (no tracks but an embankment, greenway, or clearing 
still present), as opposed to something like railway=razed. [1] The 
tags' definitions acknowledge physical characteristics rather than 
ownership. I don't think we need a tag about railbanking specifically, 
although a note tag may be helpful as a reminder to future mappers. The 
nice thing about railway=abandoned is that it can be combined with 
highway=cycleway once a rail trail is built on the old grade.


[1] http://wiki.openstreetmap.org/wiki/Demolished_Railway

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

[Minh Nguyen]

On 2015-03-31 00:36, Frederik Ramm wrote:

Hi,

On 03/31/2015 08:04 AM, Natfoot wrote:

There is so many situations where to his naked eye on the ground he may
not be able to see it.  To a person like myself I can still find the
signs on the earth of where the railroad once was.


Then map the signs that *are*, but not the railroad which - as you
correctly say - once *was*.


For many rights of way, the main remaining feature is a greenway cutting 
across farmland -- something you can easily armchair map, even. 
Personally, I'd rather map that ROW as a railway=abandoned way than as a 
natural=wood area, just as I avoid mapping roads as areas. On the 
ground, meanwhile, you'd tend to find no trespassing signs on railbanked 
ROWs, no?


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

[Minh Nguyen]

On 2015-03-29 05:00, Mark Bradley wrote:

Hello list.  I have been communicating with a mapper who says he has
been deleting abandoned railroads (the ones where the infrastructure is
totally removed).  As the premise of OSM is to only map
ground-verifiable features (other than certain boundaries), I didn't
want to argue with him, but I don't want to see this information lost
either.  I said I would look into transferring those ways to
OpenHistoricalMap.  Yesterday he sent me a message, saying he's
identified two more abandoned railroads and he's giving me the
opportunity to act on them before they get deleted.  Can I export these
ways from OSM and then import them into OHM?  Or is there a better way
or some other solution?


Just wanted to point out that there's still a place in OSM for mapping 
railroad rights-of-way where the tracks have been pulled out but the ROW 
is still reserved and discernible. The Standard style no longer renders 
railway=abandoned, but it can still be a useful navigational landmark.


In any case, I've CC'd the OpenHistoricalMap list, where all the experts 
hang out these days.


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

On 2015-03-25 09:54, Bryce Nesbitt wrote:

There are many defacto boundaries created by roads, hedges, powerlines,
ridges or bodies of water.

I argue the most appropriate boundary in OSM is indeed the defacto
boundary.  If people are using, paving, weeding
and farming the boundary, that's the one we can map.

The legal boundary is not something OSM can adjudicate.  Finding that
boundary is a complex process involving survey points, land
descriptions, and often handwritten records stored in dark basements.
It also hardy ever matters, at least to a mapper or map reader.


That may be true when it comes to private property, but the de jure 
boundary of a given village, county, etc. matters to many members of the 
general public, all of whom could wind up reading our map. To the extent 
that a given place has a de facto boundary -- which I take to mean a 
boundary not *administered* by a government -- we shouldn't map it as an 
*administrative* boundary, and we should avoid mapping overly subjective 
data in fine detail anyways.


I would imagine that administrative boundaries like city limits are a 
matter of public record. Granted, the public record isn't necessarily 
free or online, and the city may well store it in a dark basement. But 
where we can ascertain the legal definition of a city limit while 
respecting our copyright policies, we provide a valuable service by 
turning that prose into free geodata correlated with other features like 
roads. TIGER gets us most of the way there for city limits but not for a 
major city's political subdivisions.


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

On 2015-03-25 08:12, Martijn van Exel wrote:

On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen wrote:

On 2015-03-24 13:57, Martijn van Exel wrote:

More importantly though, there is an authoritative source for
official administrative boundaries that can be easily accessed by
anyone: TIGER[1]


You mean the way TIGER is an authoritative source for road
centerlines? TIGER's boundaries vary in quality just as its roads
and railroads do. I've taken quite a few imported municipal
boundaries, lined them up with road easements or hedges between
farms _when that is obviously the intent_, and deleted extra nodes.
These borders become far more accurate and precise in OSM than in
commercial maps, which regurgitate TIGER boundaries verbatim.


The most authoritative source for most U.S. land borders, going all
the way down to the parcel level, is a legal prose definition in
conjunction with any number of monuments on the ground. Both metes
and bounds and the Public Land Survey System rely on monumentation.
A monument may be a major road or as obscure as a small iron pin
embedded in that road, but even that pin is verifiable if not
particularly armchair-mappable.


If you're lucky, you can find an Ohio city limit's legal definition
in county commissioners' minutes when an annexation is proposed. The
most authoritative data representation is the county GIS database,
which anyone can easily access -- for a fee. After paying the county
for that database, you might well forget about OSM, because it's
also the authoritative source for road centerlines and names.


That is actually not what I meant, but I could have been more precise. I
guess this turns into a discussion of what 'authoritative' actually
means. This is different things to different people. As OSM becomes
better, increasingly folks will start looking at us for
authoritativeness, which would make sense because everything is
(supposed to be) verified on the ground. Because administrative
boundaries have legal implications, the authoritative source will need
to be someplace outside of OSM. It may actually hurt OSM down the line
if we include information that suggests authoritativeness we cannot
provide.


OK, thanks for clarifying. One risky use of administrative boundary data 
at the local level would be for tax purposes. Obviously we don't want 
people relying on OSM to decide whom to pay taxes to. That's why we have 
a disclaimer. [1] It should get more prominence. Wikipedia's legal and 
medical disclaimers are two hops away from every article, but ours is 
two hops from the wiki's main page only. At least consumer-focused 
redistributors of OSM data tend to have more accessible disclaimers.


[1] http://wiki.osm.org/wiki/Disclaimer


Sure, but vernacular and official neighborhood objects would then need
to be represented differently so folks can tell them apart and know what
they are dealing with.


I agree entirely, and I think OSM is already set up for these 
distinctions. If you see a boundary=administrative admin_level=10 
relation on the map, you'd expect it to be an official (aka 
administrative) boundary, not a vernacular one. If you see a 
place=neighborhood POI with the name tag, you'd expect both definitions 
to be roughly equivalent. A purely vernacular neighborhood would be a 
POI probably tagged with loc_name instead of name.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] user damages administrative boundaries around Rapid City

[Minh Nguyen]

arch_arch@... arch_arch@... writes:

 I've detected a user who damages administrative boundaries around Rapid
City. I've tried to contact the
 user but I got no reaction. I've told the mapper that iD editor is
inappropriate, as it has no built in
 validator but he didn't stop the edits.
 
 I want to ask someone from the US to take care of the case and to involve
the Data Working Group if necessary.
 
 This boundary got deleted: http://www.openstreetmap.org/relation/194816
 invalid geometry: http://www.openstreetmap.org/relation/195005
 invalid geometry: http://www.openstreetmap.org/relation/194808
 deleted relation: http://www.openstreetmap.org/relation/194807

It's clear that the user simply meant to remove the CDP boundaries (194816
and 194807), an action that many of us on this list (but maybe not all)
would approve of. [1] Unfortunately, the user removed the CDP boundaries by
deleting all the ways that belong to the CDP's relation, roping in members
of neighboring non-CDP boundary relations.

The good news is that Richard Fairhurst patched iD to prevent errors like
this in the future. [2] The bad news is that the fix didn't make it into
1.7.0, the version currently on osm.org. So in the meantime we'll have to
rely on user education.

Echoing Greg's comments, even experienced mappers sometimes hop into iD or
Potlatch to make quick edits. These editors may not be as mature as JOSM
when it comes to relations, but it isn't necessary to dismiss them out of
hand. When it comes to educating new mappers about data entry errors, I've
found them to be more receptive to messages like please be careful; here's
what to watch out for.

Thanks for bringing up this topic. It's an opportunity to remind mappers new
and old to review their changesets before saving. iD's save panel lists
changes along with validator warnings for some common errors. [3] If iD's
validator is missing a check you consider useful, I'm sure the developers
would appreciate a bug report. [4]

[1] For example, see this thread:
https://lists.openstreetmap.org/pipermail/talk-us/2015-January/014075.html
[2] https://github.com/openstreetmap/iD/pull/2526
[3] https://github.com/openstreetmap/iD/blob/master/js/id/validate.js
[4] https://github.com/openstreetmap/iD/issues


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

[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

On 2015-03-24 13:57, Martijn van Exel wrote:

I have long been on the fence about boundaries in OSM, and while I don't
feel as strongly about it any longer, it still feels wrong to make this
sweeping exception to one of the fundamental conventions of OSM mapping:
verifiability. For many types of land use, anyone would be able to
verify boundaries on the ground: a forest, a corn field, even a retail
zone in most cases. But administrative boundaries can only be observed
in a limited number of places: wherever there is a sign or a physical
boundary in place, and rare other cases.


Admittedly, a given border can be observable along one segment but not 
another. However, we tend to map the entire border for the sake of 
completeness, convention, and technical reasons -- closed areas are much 
more useful than stray lines. OSM has long gone to extremes on this 
point, going so far as to enclose all continents and island nations in 
maritime borders.


Hopefully you had the chance to read my case study on Illinois, Indiana, 
Ohio, Kentucky, and West Virginia earlier in this thread. [1] You can 
observe much of the Ohio-Indiana state line quite precisely, both on the 
ground via welcome signs and mile markers and from the air via changes 
in land use and pavement quality. But you cannot observe the 
Ohio-Kentucky state line except by visiting a library, and the 
Ohio-Ontario border is an imaginary line. Which of the five options 
would you have chosen for Ohio?


[1] https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014485.html


More importantly though, there is an authoritative source for
official administrative boundaries that can be easily accessed by
anyone: TIGER[1]


You mean the way TIGER is an authoritative source for road centerlines? 
TIGER's boundaries vary in quality just as its roads and railroads do. 
I've taken quite a few imported municipal boundaries, lined them up with 
road easements or hedges between farms _when that is obviously the 
intent_, and deleted extra nodes. These borders become far more accurate 
and precise in OSM than in commercial maps, which regurgitate TIGER 
boundaries verbatim.


The most authoritative source for most U.S. land borders, going all the 
way down to the parcel level, is a legal prose definition in conjunction 
with any number of monuments on the ground. Both metes and bounds and 
the Public Land Survey System rely on monumentation. A monument may be a 
major road or as obscure as a small iron pin embedded in that road, but 
even that pin is verifiable if not particularly armchair-mappable.


If you're lucky, you can find an Ohio city limit's legal definition in 
county commissioners' minutes when an annexation is proposed. The most 
authoritative data representation is the county GIS database, which 
anyone can easily access -- for a fee. After paying the county for that 
database, you might well forget about OSM, because it's also the 
authoritative source for road centerlines and names.



All of this has little to do with neighborhoods, which are mostly (?)
vernacular in naming and delineation, and even when there are official
neighborhood designations, in my own experience they do not always match
the vernacular names. I support point mapping of vernacular
neighborhoods. If you really want to have shapes for vernacular
neighborhoods, you can look at the now-ancient-but-still-cool flickr
Alpha Shapes[2], last updated in 2011 but still available for
download[3]. But please don't upload 'em to OSM :)


As a political boundary (in the political map sense), an official 
neighborhood designation can be distinct from the neighborhood with a 
vernacular name, but that's an argument to map both rather than favoring 
one over the other. They coexist and might share a name but aren't 
necessarily the same thing. People should be able to get the concrete, 
objective boundary of an official neighborhood from OSM and an 
amorphous, subjective boundary of an informal neighborhood from Alpha 
Shapes.


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

tl;dr: I'm against a blanket rule when it comes to administrative 
boundaries. They're really nuanced, and so should we.


On 2015-03-22 04:32, Serge Wroclawski wrote:

Imagine if Bob and Alice conflict on where a neighborhood boundary is
inside OSM. The issue escalates to an edit war and the DWG is called
in to resolve the conflict. Let's say that Frank is our DWG member.
How is Frank supposed to resolve the conflict between Alice and Bob?
Often neighborhoods don't have administrative recognition, or
administrative recognition is not in alignment with the people. I
imagine this would be especially an issue with neighborhoods where
lots of the under-represented populations live.


This is an important consideration. As I mentioned in a footnote 
earlier, even a city with strong neighborhood organization can have 
boundary disputes. However, the problem exists for administrative 
boundaries in general, all the way up to admin_level=2 boundaries that 
cut right across ethnic fault lines.


My point was that we should map neighborhood boundaries in cities where 
doing so requires little editorial judgment, thanks to signage, 
distinctive lamp posts, etc. And we are quite clear (via the tag value 
administrative) that this isn't the only way by which a community can 
be delimited. As numerous threads have pointed out, the USPS has very 
different ideas of location (ZIP codes), but that's OK.


When it comes to all our discussions around *administrative* boundaries, 
I like this two-point test as a rule of thumb:


1. Are people or property governed differently on one side versus the other?

2. Is this distinction observable on the ground?

Municipalities generally pass both points. Congressional districts pass 
#1 but not #2. CDPs generally fail both. School districts can be 
observed, but not with the granularity required for mapping a boundary. 
City neighborhoods may pass one, both, or neither. Maybe all the locals 
you interview can agree on the name of a neighborhood but not its shape 
-- in which case it should be nothing more than a POI.


Which brings me to Serge's other point:


First, there are a growing number of people who believe that
administrative data is very useful, but breaks OSM's ground
observable rule. That is, someone who is present on the ground should
be able to observe the data in OSM. It's usually not possible to do
that with administrative boundaries.


SteveA has responded more forcefully on this point, and so have I in the 
past. [1] Fortunately, Alice and Bob's disagreement sounds pretty 
clear-cut. If the city didn't go through the trouble of demarcating any 
part of the boundary in some way, perhaps the general public shouldn't 
expect OSM to reproduce their two neighborhoods' boundaries at all. But 
I see no reason why such a decision would impact boundaries with very 
different characteristics.


-*-*-*-

Serge's focus on verifiability relates to a boundary I've spent a lot of 
time on lately, so I'm going to go way over my word limit.


Last month, I reminded this list that state borders along the Ohio River 
actually follow the river's historical northern bank, not its 
present-day thalweg or centerline. [2] Even if you send a diver into the 
river, there isn't always going to be a natural feature to verify OSM 
data against. We have a few options:


1. Try to be as accurate as possible by tracing USGS topo maps. Treat 
these borders as a practical exception to the on-the-ground rule. Use 
the source tag rigorously.


2a. Conflate the state borders with the current thalweg. We'd give Ohio 
and Indiana various islands and dams that actually belong to Kentucky 
and West Virginia, ignoring the Supreme Court ruling. We'd be putting 
intentionally inaccurate data into OSM.


2b. Conflate the state borders with the current northern bank, siding 
with Kentucky and again ignoring the Supreme Court ruling. We'd give the 
entire river to Kentucky and West Virginia, including riverboat casinos 
that keep to the Indiana side but are illegal in Kentucky.


3. Omit the river boundaries but leave the rest of the state lines 
intact. This approach introduces technical problems like broken 
multipolygon relations and just confuses people. Where does West 
Virginia end?


4. Omit the entire boundaries of states that border the Ohio River. 
It'll look like a mistake, so people will helpfully and sloppily add the 
boundaries back in.


5. Omit all state lines, everywhere, throwing away lots and lots of 
fixup work done with care by volunteer mappers. And all because Kentucky 
wanted the whole river.


Everyone agrees the river is the boundary, just not what the river 
means. In this case, I say we hold our noses and go with #1 as the most 
accurate, least disruptive approach. [3]


[1] 
https://lists.openstreetmap.org/pipermail/talk-us/2013-January/010162.html
[2] 
https://lists.openstreetmap.org/pipermail/talk-us/2015-February/014307.html

[3] 

[Talk-us] Ohio River and state lines

[Minh Nguyen]

A heads-up to anyone working on state lines: Ohio River ways and administrative 
boundaries should be kept separate. Kentucky and West Virginia own most of the 
river, including just about all of the islands and public bridges and ferries, 
irrespective of the present-day thalweg. You can read a full explanation here:

http://wiki.openstreetmap.org/wiki/Ohio_River

I've been retracing much of the state lines based on the USGS Topographic Maps 
layer, but a more up-to-date source would be welcome.

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Why does the USA currently lag in OSM map quality?

[Minh Nguyen]

On 2015-02-17 12:30, Bryce Nesbitt wrote:

Mapilariy is fun... but collecting more data is not necessarily the
avenue to a better map.

Instead, consider how many people use the map.
Consider how many people garden a particular area of the map.
Consider how many people enthusiastically map a given feature (e.g. RV
Dump Stations, Dog Parks, Smoking Zones, Bike Repair Stations, Bear Boxes).

A pile of automatically imported or collected data is really not all
that interesting or complete.
I think in the USA the way forward involves finding user communities not
served by other maps (e.g. Bear Boxes, above).


Reaching out to these communities is right up there with welcoming new mappers. As 
someone who largely gardens a limited region, I was disappointed that some 
local cycling enthusiasts couldn't be persuaded to contribute to OSM instead of or in 
addition to Map Maker. But along come enthusiasts for things I'd never thought would have 
enthusiasts. Add a few city-maintained stairways and someone draws the other 390. Add 
pylons to a power line and someone quickly adds the voltage. Wheelchair access. Bike polo 
courts.

Topical mapping can spur local mapping too. I loved the baseball field mapping 
contest we did a few years ago. [1] It was fun and very easy to hop around the 
countryside scavenging for baseball fields, and the resulting green diamonds in 
the middle of nowhere broadcast OSM's micromapping ambition. If a mapper added 
baseball fields but neglected to improve the surrounding map, the lonely fields 
sometimes tickled locals into mapping the rest of the park or school.

A modicum of guerrilla mapping can have a huge effect. A few athletic fields 
and building outlines can quickly snowball into almost every building and 
driveway in town. [2]

[1] http://bit.ly/OSMbaseball
[2] http://osm.org/go/ZUruk1AO

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-27 22:42, Greg Morgan wrote:

OSM Inspector[1] has a nice tool to check issues with these
city/town/village/hamlet  POIs.  I updated a bunch of the POIs in
Arizona to the 2010 numbers.  I see that some mappers changed the
values to the estimated value.  Another mapper would change it back to
the 2010 actual numbers.  I have don't have an issue with the
mechanical edits unless the edits would remove gnis id tags or other
useful data.  Just as with the manual edits both the estimated value
and actual 2010 values were close enough.  They correctly raised the
value closer to the 2010 number from the 2000 number.


The original GNIS import was also wildly incorrect in some cases. For 
example, Mount Pleasant, Delaware County, Indiana [1], was given a 
population of 12,459, but it's really an unincorporated community with a 
couple hundred residents at most. The Census doesn't keep any data on 
its population.


Should the mechanical edit remove population tags on places that don't 
correspond to any Census division? Or maybe just flag them for manual 
followup? I guess a local could unofficially guesstimate the population 
of a community like Mount Pleasant.


[1] https://osm.org/changeset/28225500


Deleting?  I question this.  I am not in favor of it.  I think there
is a mismatch between rural America and Metro America areas.  I have a
sense that Metro mappers have a lower value of some POIs that are
essential to rural areas. Vicksburg Junction[2] could be a possible
deletion target.  I am not sure if there is an actual boundary for the
area. Cleator Arizona[3] is another example.  People live there with
real addresses even though it looks like a ghost town.  The best I
could do is make a residential landuse area. There are any number of
small named areas from the Census that are significant names that the
locals use. How do you know that you are not deleting valuable named
data?  Moreover, you can query on Moon Valley Arizona and find a
well known area in metro Phoenix.  Sure someday that POI can be made
into an area.  I have wondered what kind of a polygon would be the
correct one for this area. There's no real legal boundary for the
area.  I have already had to dig that POI out of the trash bin once.


It doesn't sound like Paul was proposing to systematically eliminate 
place=hamlet POIs. It sounds like he was evaluating each one on its merits.


I do delete GNIS POIs fairly regularly, but not just because they're 
tagged place=hamlet. It's usually because it's a mobile home park that I 
can turn into a more accurate landuse=residential. Or it's the name of a 
railroad junction torn out a century ago that now sits in the middle of 
wilderness. (There is place=isolated_dwelling in the event that a small 
cluster of houses is still called by that name.)


On the other hand, I have been aggressive about preventing TIGER CDP 
boundaries from rendering, but they're a whole different animal than 
GNIS POIs. They usually end up being so precise as to be inaccurate. 
When I delete a CDP boundary, the map usually continues to show the 
local name thanks to a well-placed GNIS POI.



Finally, why would you want to dash the hopes of a new mapper[1]?  I
shared the excite with a mapper as he talked about his recent project.
He had just put in the Phoenix Urban Planning Villages or whatever
they are called.  Now you can look for alhambra arizona and find one
of these areas as a POI.  I am afraid that his victory would fall prey
to your deletions.  If you don't know the area or are not sure, then
just leave it alone.


Phoenix's distinction between Urban Planning Villages and council 
districts reminds me of how other cities distinguish between 
neighborhoods and electoral wards. I favor mapping the former as 
boundary=administrative and admin_level=10, or as a place=suburb POI if 
the boundary is unknown. But I'd leave the latter out of the picture, 
just as I'd avoid mapping state legislative districts. Alhambra [2] 
looks good to me.


[2] https://osm.org/node/150948276

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-28 07:52, Simon Poole wrote:

According to overpass turbo there is the small number of 394 such nodes
(historical hospitals) remaining in the US (excluding Alaska and
Hawaii). Given that this is bad data that actually might have disastrous
consequences, I would suggest that fixing these (and other GNIS junk
that might be misleading) has a slightly higher priority than updating
population numbers.


Eventually we'll have to review every hospital imported from GNIS. 
Since the GNIS data was collected, lots of hospitals in smaller towns 
have been closed or turned into outpatient facilities, with emergency 
services being consolidated into a regional facility. According to the 
wiki, amenity=hospital doesn't imply emergency=yes, but I wonder if that 
nuance is made clear in any OSM clients.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] fun with tagging: it's a raceway and an airstrip

[Minh Nguyen]

On 2015-01-15 20:36, Paul Johnson wrote:

Given that aeronautical features and road vehicle features have
different namespace, tag it as runway and raceway?   This is a
surprisingly common arrangement in the ground truth and plays a
prominent role in the original, US, AU (and very probably, all)
versions of Top Gear.


The Transportation Research Center is an automotive proving ground in 
Central Ohio, used by the National Highway Traffic Safety 
Administration, Honda, and others. [1] It's currently tagged as a 
landuse=industrial area [2] with lots of highway=raceways traversing it. 
There's also an aeroway=aerodrome POI imported from GNIS. [3] TRC does 
have an FAA code [4], but I can't find any indication that it's actually 
used as an airfield.


TRC would make for a great emergency landing site -- could that be why 
it's in the FAA's database as an operational private airport? I could 
give it some ad-hoc tag like aeroway:emergency=aerodrome, but in that 
case any sufficiently straight stretch of an Interstate might qualify.


I just think it would be misleading for TRC to come up in Nominatim 
searches for airports. Then again, such a search would turn up so many 
cornfields doubling as private airstrips (with improbable names like 
Nulltown Wingnuts and Hallelujah) that maybe it wouldn't matter. :-)


[1] http://www.trcpg.com/
[2] http://osm.org/way/266434455
[3] http://osm.org/node/368965761
[4] 
https://nfdc.faa.gov/nfdcApps/airportLookup/airportDisplay.jsp?category=nasrairportId=9OI5


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pennsylvania's quadrant routes

[Minh Nguyen]

On 2015-01-19 01:30, Minh Nguyen wrote:

On 2015-01-19 00:50, Paul Johnson wrote:

Are they actually separate networks, though?  Just because there's more
digits doesn't a different network make.


What distinguishes the various networks that a given agency maintains?
For our purposes, I think we're most interested in:

1. Significant differences in signage (signage type, shield designs,
bannered routes)
2. Potential overlaps in numbering

Given the extra digits, #2 is unlikely, but the quadrant routes are
signed very differently than ordinary state routes. It looks like
they're only indicated as secondary information on out-of-the-way
mile-markerish signs. (It also appears that conventionally one is
prefixed PA while the other is prefixed SR.)

For example, here's a directional sign for PA 443:

https://www.flickr.com/photos/dougtone/4176740362/

There's a quadrant route number on the marker beneath it. It's the
four-digit number next to SR, above 210. Unlike PA 443, SR 3009
is inappropriate for how OSM clients use the `ref` tag. It might be
worth mapping inasmuch as bridge inventory numbers are worth mapping,
but I agree with James that we should keep mappers from conflating the
two systems. And if the solution starts with `ref:penndot`, there's no
need to square that with route networks in other states. :-)


Forgot to mention: 3009 was just a guess based on [1]. My vision isn't 
*that* good.


[1] https://en.wikipedia.org/wiki/PA_443

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pennsylvania's quadrant routes

[Minh Nguyen]

On 2015-01-19 00:50, Paul Johnson wrote:

Are they actually separate networks, though?  Just because there's more
digits doesn't a different network make.


What distinguishes the various networks that a given agency maintains? 
For our purposes, I think we're most interested in:


1. Significant differences in signage (signage type, shield designs, 
bannered routes)

2. Potential overlaps in numbering

Given the extra digits, #2 is unlikely, but the quadrant routes are 
signed very differently than ordinary state routes. It looks like 
they're only indicated as secondary information on out-of-the-way 
mile-markerish signs. (It also appears that conventionally one is 
prefixed PA while the other is prefixed SR.)


For example, here's a directional sign for PA 443:

https://www.flickr.com/photos/dougtone/4176740362/

There's a quadrant route number on the marker beneath it. It's the 
four-digit number next to SR, above 210. Unlike PA 443, SR 3009 
is inappropriate for how OSM clients use the `ref` tag. It might be 
worth mapping inasmuch as bridge inventory numbers are worth mapping, 
but I agree with James that we should keep mappers from conflating the 
two systems. And if the solution starts with `ref:penndot`, there's no 
need to square that with route networks in other states. :-)


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pennsylvania's quadrant routes

[Minh Nguyen]

On 2015-01-16 00:14, James Mast wrote:

So, I've come up with a possible replacement tag of 'ref:penndot=SR
' [3] for these routes that are only signed with the white mileage
signs.  With this tag, it still allows the quadrant routes to be added,
but not to take up the normal 'ref' tag when it's needed for another
route (there are a few normal state routes on quadrant routes, like PA-3
for a small area in Philadelphia, or US-19 Truck in Pittsburgh, or even
the Allegheny County Belt System [3] in some areas).


If PennDOT also maintains the actual state routes, `ref:penndot` may 
still lead mappers to conflate the two systems. Alternatively, you could 
use `loc_ref`, unless the Allegheny County belts use it already, or 
`ref:penndot:quadrant` to be really explicit.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pennsylvania's quadrant routes

[Minh Nguyen]

On 2015-01-16 07:52, Paul Johnson wrote:

I'm very much in favor of PA instead of SR for disambiguation purposes.


With James' proposal to change `ref` to `ref:penndot` (or something even 
more explicit like `ref:penndot:quadrant`), there's no need for 
disambiguation. A prefix of PA isn't going to solve the problem of 
mappers conflating PennDOT's two networks either.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Place classifications

[Minh Nguyen]

On 2015-01-13 05:28, Minh Nguyen wrote:

On 2015-01-12 11:23, Elliott Plack wrote:

Great start on this Minh,

I tried to tackle this in the Baltimore Washington region last year.
After reading the wiki, I decided on the following classifications:

* hamlet: census population was less than 200
* village: census pop. between 200 and 1
* town: census pop. between 10001 and 5
* city: major hub urban centers above 5


I like the idea of lowering the bar for place=city somewhat, to rope in
smaller cities that have their own suburbs as part of a micropolitan
area. However, if we just go by population, the map ends still ends up
rather sparse, making OSM look undermapped.

Most rural counties have a center of commercial activity, often the
county seat (or a former county seat). Even though its population may
not reach 10,000, it's significant enough to be labeled at the same zoom
levels as those that do. For example, I made an exception for Hillsboro,
OH. [1] Nowhere else in the county comes close to its population of
6,605. As a county seat, it has its own daily newspaper, radio station,
fairgrounds, general aviation airport, high school, and two U.S.
highways. I cite attributes like these in the changeset comment or note
tag whenever making an exception.

[1] http://osm.org/relation/183049


There are some CDPs though that would be a city by population alone, but
really don't have a true city feel, and cartographically would look bad
as being a city on a map. The tricky one is Glen Burnie, sprawl area
south of Baltimore with no urban core, yet the pop is over 65k. It is
marked as a city now, but really should be town I think. I like your one
city per metropolis idea.


In suburban areas, even a city in the official sense may lack a downtown
core. But yes, if you'd consider Glen Burnie to be subordinate to
Baltimore, place=city is probably too prominent. You wouldn't consider
any town to be a suburb of Glen Burnie.

The unincorporated places I referred to the other day are different than
CDPs. They came from the GNIS database and likely originated as
century-ago post offices, cemeteries, or railroad stops. Wikipedia and
the Census Bureau are mum on most of these places, but it's entirely
possible that they're marked on the ground with signs. I haven't heard
back from the mapper who made them into towns, but I'd like to revert
their changes soon.


Fortunately it was just a misunderstanding. They explained that 
place=hamlet appeared wrong, since no one uses the word hamlet in this 
part of the country. They're using mostly Potlatch 2 and JOSM. P2's 
basic mode does have human-friendly preset names, but none of the 
popular editors attempts to bridge this particular Britishism/New-Yorkism.


Though some of these POIs look so obscure they might not even qualify 
for place=isolated_dwelling...


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-14 01:29, Paul Norman wrote:

On 1/13/2015 5:34 AM, Minh Nguyen wrote:

It looks like most of the place=city/town/village/hamlet POIs from
GNIS are tagged with 2000 Census populations in the population tag.
These population tags allow renderers to label places with font sizes
corresponding to population, which is a pretty common use case.


I had done a PR which would have added population sorting for place
names, but as a style maintainer I'm interested in what styles use
population for sizes.


Here are a couple that use it:

https://github.com/Citytracking/Terrain
as seen at: http://maps.stamen.com/terrain/
https://github.com/migurski/OSM-Solar

I do see quite a few instances of population-based sorting on GitHub:

https://github.com/search?q=planet_osm_point+populationtype=Code

But the difference between 2006 and 2010 populations is unlikely to be 
large enough to matter much for this use case.


Still, weighting city labels by population is a common enough practice 
dating back to the days of paper maps. Someone trying to emulate it with 
OSM data would find the `population` tag much more convenient than 
conflating with an external source, since precision would be less 
important than accuracy.



I think we should consider a mechanical edit to update these tags to
the 2010 Census figures en masse. I've been updating individual places
as I edit them for other reasons, but this tag is most useful when its
vintage is consistent across the board.

Although I somewhat like the idea of updating the population tags, I
think we should give higher priority to fixing their tagging. When I did
some cleanup of Washington place=city POIs I found that I ended up
retagging most, deleting many, and only a few were place=city.


In Ohio and surrounding states, I've seen lots of incorrect `place=city` 
on boundary relations, but all the `place=city` POIs were correct. I 
think the `place` tags on those relations were set to whatever the TIGER 
classification happened to be. On the other hand, there are plenty of 
`place=hamlet`s on POIs that should either be deleted or turned into 
named landuse areas (mostly trailer parks).


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-13 10:50, Richard Fairhurst wrote:

I'd do it myself but this is about the one area where you _do_ need JOSM
rather than P2. ;)


That makes two of us. ;-)

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Place classifications

[Minh Nguyen]

On 2015-01-12 11:23, Elliott Plack wrote:

Great start on this Minh,

I tried to tackle this in the Baltimore Washington region last year.
After reading the wiki, I decided on the following classifications:

* hamlet: census population was less than 200
* village: census pop. between 200 and 1
* town: census pop. between 10001 and 5
* city: major hub urban centers above 5


I like the idea of lowering the bar for place=city somewhat, to rope in 
smaller cities that have their own suburbs as part of a micropolitan 
area. However, if we just go by population, the map ends still ends up 
rather sparse, making OSM look undermapped.


Most rural counties have a center of commercial activity, often the 
county seat (or a former county seat). Even though its population may 
not reach 10,000, it's significant enough to be labeled at the same zoom 
levels as those that do. For example, I made an exception for Hillsboro, 
OH. [1] Nowhere else in the county comes close to its population of 
6,605. As a county seat, it has its own daily newspaper, radio station, 
fairgrounds, general aviation airport, high school, and two U.S. 
highways. I cite attributes like these in the changeset comment or note 
tag whenever making an exception.


[1] http://osm.org/relation/183049


There are some CDPs though that would be a city by population alone, but
really don't have a true city feel, and cartographically would look bad
as being a city on a map. The tricky one is Glen Burnie, sprawl area
south of Baltimore with no urban core, yet the pop is over 65k. It is
marked as a city now, but really should be town I think. I like your one
city per metropolis idea.


In suburban areas, even a city in the official sense may lack a downtown 
core. But yes, if you'd consider Glen Burnie to be subordinate to 
Baltimore, place=city is probably too prominent. You wouldn't consider 
any town to be a suburb of Glen Burnie.


The unincorporated places I referred to the other day are different than 
CDPs. They came from the GNIS database and likely originated as 
century-ago post offices, cemeteries, or railroad stops. Wikipedia and 
the Census Bureau are mum on most of these places, but it's entirely 
possible that they're marked on the ground with signs. I haven't heard 
back from the mapper who made them into towns, but I'd like to revert 
their changes soon.


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] GNIS POI populations

[Minh Nguyen]

It looks like most of the place=city/town/village/hamlet POIs from GNIS 
are tagged with 2000 Census populations in the population tag. These 
population tags allow renderers to label places with font sizes 
corresponding to population, which is a pretty common use case.


I think we should consider a mechanical edit to update these tags to the 
2010 Census figures en masse. I've been updating individual places as I 
edit them for other reasons, but this tag is most useful when its 
vintage is consistent across the board.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-13 07:22, Serge Wroclawski wrote:

Mihn,

If we do any en-mass edit, there are a few things I think we want to consider:

1. Before anything else, we need to make sure it's community approved,
source data and code examined and approved by the community.


Sure. The code isn't ready yet. My e-mail was more of an early-morning 
musing. :-)


In particular, I noticed that plenty of POIs have an additional 
`census:population` tag that takes the form 1234;2006, where 2006 is a 
year and 1234 is a number that usually doesn't match the value in 
`population`. I'd like to update `population` and replace 
`census:population` with `population:date`, which is far more common 
worldwide.



2. I think that in principle this is a good idea, but we'll also
encounter some issues where census data shows that objects:

a. Have moved
b. Have been renamed
c. Are present in one dataset but not the other


We want to flag these for secondary processing (likely manual).

3. I think it'd be nice, if we're doing en mass mechanical edits, to
connect objects to Wikidata


At the moment, boundary relations are mostly linked to Wikipedia, but 
unfortunately few POIs are part of those relations. (They'd have a role 
of label, which I think is poorly named, but that's a topic for 
another day.) Since they come from TIGER, the boundary relations also 
generally have the official census name in `tiger:NAMELSAD`, which would 
make step 2 easier.



While it makes sense to keep our own copy of various attributes (like
town/city classifications) in OSM, if we connect the data with
Wikidata, in the future we could pull the data out of Wikidata for
what's classified as what.

They're going to be more inclined to have this kind of data updated
regularly than we are, so this seems like a good way of moving towards
this model, even if today we don't have a way of retrieving the data
from the two datasets and reconciling them.


I'd be okay with #3 being left to a separate task, but I think it
deserves some thought.

- Serge

On Tue, Jan 13, 2015 at 8:34 AM, Minh Nguyen
m...@nguyen.cincinnati.oh.us wrote:

It looks like most of the place=city/town/village/hamlet POIs from GNIS are
tagged with 2000 Census populations in the population tag. These population
tags allow renderers to label places with font sizes corresponding to
population, which is a pretty common use case.

I think we should consider a mechanical edit to update these tags to the
2010 Census figures en masse. I've been updating individual places as I edit
them for other reasons, but this tag is most useful when its vintage is
consistent across the board.

--
m...@nguyen.cincinnati.oh.us


___
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




--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] Place classifications

[Minh Nguyen]

Recently I've been trying to improve the distribution of place=village 
versus place=town in my area. Originally municipalities were tagged 
based on their populations, resulting in clusters of place=cities in 
urban and suburban areas and a desert of place=hamlets everywhere else. 
And there's a lot of everywhere else in Ohio and Kentucky.


Generally speaking, I've been promoting the county seat and other 
significant municipalities in each county from place=village to 
place=town. The result is 1-2 place=towns in each rural county, a bit 
more along Interstates. It looks nice on the standard map, but more 
importantly, it accurately reflects what going to town means in the 
surrounding area. That seems to be the idea behind the wiki's nebulous 
definitions. [1]


Meanwhile, over in Indiana, one mapper has been turning virtually every 
place POI into place=town, even unincorporated places with nothing but a 
house or two. [2] I'm sure that's too extreme, and I just reached out to 
the mapper to say as much. But after browsing various parts of the U.S., 
I think we've all got different ideas of what a city, town, and village 
ought to be. Some metropolitan areas have lots of place=city POIs, while 
in other places 3-4 U.S. routes converge on a place=village.


I think we should reserve place=city for the focal point of each 
metropolitan area and distribute place=town more evenly across the 
landscape. Just as the highway tag summarizes disparate tags like 
surface, maxspeed, and lanes, the place tag holistically sums up 
admin_level, border_type, and population (and the admin_centre role for 
county seats). So for example, the Walden County seat (population 900) 
and a Bigopolis suburb of 15,000 should both be place=town.


Or has everyone settled on a different standard? Sometimes it's hard to 
tell whether the state of the map is due to a long-ago import to be 
fixed or a community consensus to be respected, and the wiki hedges too 
much to be helpful.


[1] http://wiki.osm.org/wiki/Key:place
[2] http://overpass-turbo.eu/s/6VW

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] CDP tagging

[Minh Nguyen]

On 2015-01-08 18:43, James Mast wrote:

A user today just happened to change the 'Carnot-Moon' [1] ways [2] and
relation boundary [3] from a 'boundary=administrative' 'admin_level=8'
to 'boundary=census'.  Is this the correct way we have been tagging
stuff like this?  I've pretty much stayed away from these types of edits
(unless it's something obvious that needs to be reverted), and was just
curious to what the rest of the US was doing before I either reverted
the changesets this was done in, or contact the user (or if somebody who
has more 'knowledge' on these types of edits wants to contact him
instead, be my guest).

-James

[1] -
http://en.wikipedia.org/wiki/en:Carnot-Moon,%20Pennsylvania?uselang=en-US
[2] - https://www.openstreetmap.org/way/38518599
[3] - https://www.openstreetmap.org/relation/189136


Taginfo currently shows over 2,000 instances of boundary=census, both 
for CDPs and for statistical boundaries in other countries. [1]


I use boundary=census. If it weren't already in such wide use, I 
would've gone with the more generic-sounding boundary=statistical, but 
whatever. Another mapper in Ohio prefers to delete the boundary and 
admin_level tags but leave place=locality in place. [2] IMO the 
important thing is to remove the misleading administrative tags.


The TIGERcnl import apparently only brought in CDPs, but the Census 
defines a whole hierarchy of areas, including metropolitan statistical 
areas (MSAs), census county divisions (CCDs), and census tracts. [3] If 
we ever attempted to map them, boundary=census and boundary=statistical 
would be equally ambiguous and a tag similar to admin_level would be 
required. However, there doesn't seem to have been much demand for 
including these other Census features in OSM. (For that matter, if 
TIGERcnl had left out CDPs, I would've preferred to seem them mapped as 
POIs at centroids rather than as areas. Even where the CDP name is 
widely used, the boundary is less clear-cut than a city limit.)


[1] http://taginfo.osm.org/tags/boundary=census
[2] http://wiki.osm.org/wiki/Ohio/Boundaries/CDPs
[3] https://en.wikipedia.org/wiki/Template:USCensus_Geography

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Rail westerly

[Minh Nguyen]

On 2014-12-20 18:59, Natfoot wrote:

Steve,
If you are finding PCIX those are the call letters for the railroad that
is the owner, they may also be the operator.

Now here is the tricky bit, I will use the example of a local short line
railroad.

This railroad the property is owned by the county and the port; one
railroad (GNPX) has the operating rights who then contracts with a
second company that is a railroad (BDTL) yet the line in which they are
running is known as another railroad (ESFR).

If any of you can sort this out into the proper categories I think it
will help a few many people.


I'm also trying to get my head around a slightly simpler case. The 
Cincinnati Southern Railway [1] is owned by the City of Cincinnati and 
leased out to the Cincinnati, New Orleans  Texas Pacific Railway 
(CNTP), a subsidiary of Norfolk Southern (NS).


The relations -- one for each subdivision [2][3][4] -- don't indicate 
their ownership by the city anywhere. (`name` contains CNOTP and 
`operator=NS`.) It sounds like I would just need to add `owner=City of 
Cincinnati` to the relations. Would that be correct, or would the lessee 
go in `owner`?


[1] https://en.wikipedia.org/wiki/Cincinnati_Southern_Railway
[2] http://osm.org/relation/2250839
[3] http://osm.org/relation/2250840
[4] http://osm.org/relation/1441409

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Edits near Lexington, KY?

[Minh Nguyen]

On 2014-12-16 04:04, Shawn K. Quinn wrote:

Does anyone know anything about a school course (middle or high school
most likely) incorporating OSM in or near Lexington, KY? I saw one
changeset comment mentioning something about extra credit but not
mentioning what the edit actually was. In addition I cleaned up plenty
of vandalism: a road on top of another road labeled Short cut to
school, three exclamation marks added to a street name, undeleted a
fire hydrant (!), and a couple of other things that I'm drawing a blank
on right now.

While I support OSM-related lessons in the classroom on general
principle, but I have to wonder if some of the garbage edits that come
with it offset the good edits. And to put it bluntly, the higher the
grade level this is coming from, the more disappointed I will be
regarding our public education system in 2014.

http://www.openstreetmap.org/history#map=13/38.0462/-84.4885


Some recent changesets in Lexington mention UK, which is the 
University of Kentucky. For a few years now, the Geography department's 
GEO109 course [1][2] has incorporated an introduction to OSM and 
TileMill. Students in this class have edited primarily in the Lexington 
area but also in hometowns across Kentucky. The changesets are usually 
tagged #geo109. [3] Perhaps GEO109 has raised awareness of OSM on 
campus, leading to less-closely-guided edits?


Ohio State's Geography and Geodetic Science departments have also 
offered extra credit for OSM contributions in the past. I've found most 
course-related contributions from both universities to be of high 
quality. Following up with quick corrections and guerrilla edits can 
help keep these mappers engaged beyond the course.


[1] https://geography.as.uky.edu/courses/digital-mapping
[2] https://twitter.com/search?q=%23geo109
[3] http://resultmaps.neis-one.org/osm-changesets?comment=geo109

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] USGS Drought Map Uses OSM?

[Minh Nguyen]

On 2014-12-12 13:38, Mike Thompson wrote:

Interesting depiction of the drought in California (recent rains not
withstanding). It appears that their base map is OSM, but I didn't
notice the required OSM attribution. Perhaps I missed it.


I don't see it either. There's a GitHub issue tracking the lack of 
attribution: https://github.com/USGS-CIDA/CIDA-Viz/issues/343


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] State highway refs (was Re: New I.D Feature)

[Minh Nguyen]

On 2014-12-01 13:58, James Mast wrote:

Same thing goes with Florida.  Just the state outline.

Heck, in Pennsylvania, originally on BGS's before we started to use the
Keystone shield, we used the 'PA' abbreviation (one such sign that still
stands [1]).  However, now on the little white reference mileage signs
[2] that PennDOT posts on roads they maintain, it says 'SR' (even on
Interstates).  However, PennDOT recently posted a nice little gem on
PA-28 @ Exit #6 going both directions that goes back in time and
mentions the 'PA' on the sign. [3]  There are at least 3 of these signs
(2 going SB, at least 1 going NB).


Just to be clear, the argument I've been putting forward has little to 
do with route shields (or places where you'd expect a route shield). I'm 
thinking about places where plain text is expected and intended for a 
general audience.


(If you're sick of hearing me ramble on about ref formats, feel free to 
tune out now.)


Variable message signs are generally programmed to display alphanumeric 
messages only. [1] The messages usually say SR for state routes in 
Ohio [2], Florida [3], and Utah [4]; KY in Kentucky; K- in Kansas; 
and SH in Texas [5]. (California doesn't usually bother qualifying the 
state route number.)


But it isn't all about the highway department. The same style tends to 
be used also by the media and by businesses and homeowners giving their 
addresses. Any other style sounds foreign.


If we standardize all states on the state abbreviations, software like 
Nominatim would need special cases to translate from e.g. 100 SR 123, 
Red Lion (what a typical user would input based on a business listing) 
to 100, OH 123, Red Lion, Warren County, Ohio. Routers would need to 
translate in the other direction, because street signs are often limited 
to plain text. If someone's in unfamiliar territory and their GPS says 
turn left on Texas 99 but they see SH-99 on a blade sign [6], maybe 
that could make them hesitate and miss a turn?


In any case, I'm only concerned with allowing Ohio to keep the SR refs 
intact, since folks have occasionally suggested that they be eliminated. 
I bring up other states just to point out that Ohio isn't much of a 
special case in reality.


[1] OTOH some do have shields: 
http://www.asphaltplanet.ca/ON/hwy_401_images/401_dv_191_west_lg.jpg
[2] 
https://www.dot.state.oh.us/Divisions/Operations/Traffic/FAQs/PublishingImages/DMS_Carillon.jpg

[3] http://www.aaroads.com/southeast/florida075/i-075_sb_exit_101_04.jpg
[4] http://www.aaroads.com/west/utah067/ut-067_sb_exit_004_09.jpg
[5] http://www.aaroads.com/texas/sh250-299/sh-286_n_horne_rd_02.jpg
[6] 
http://webzoom.freewebs.com/theoldcopperfield/Album%2027%20Pic%2006.jpg


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Palmer Motorsports Park...

[Minh Nguyen]

On 2014-11-30 18:55, Paul Johnson wrote:

Eeeh, that's not as far out as, say, Hallett
http://www.openstreetmap.org/#map=17/36.22111/-96.59435.  Though you
might want to fix all those SH and SR refs, can't even tell what
state that's supposed to be in without asking Nominatim.


That's because the OSM doesn't have a breadcrumb up top like some 
other map providers (Bing comes to mind). So here's a request to add it 
to OSM, hopefully without bringing Nominatim to its knees:


https://github.com/openstreetmap/openstreetmap-website/issues/848

(And sorry for the confused state of the original writeup, Paul.)

Even if all the U.S. used state abbreviations on state routes, that 
leaves all the map views without state routes: if I zoom in on a city's 
central business district or wander out to the middle of a national 
forest, I wouldn't be able to rely on highway shields. That's where a 
breadcrumb would help.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] State highway refs (was Re: New I.D Feature)

[Minh Nguyen]

On 2014-11-29 22:45, Shawn K. Quinn wrote:

On Sat, 2014-11-29 at 22:21 -0800, Minh Nguyen wrote:

Do any routing engines currently care about prefixes on way refs?

  From what I've seen so far, most of the map styles that use the ref tag
to distinguish route networks will recognize either the state
abbreviation, SR, or SH. Some renderers use the prefix to choose a
state-specific shield, assuming any unrecognized prefix is for a county
route (white rectangle at higher zoom levels). MapQuest only recognizes
state/provincial abbreviations. Not that we should place too much stock
in individual renderer decisions. :-)


OSRM doesn't know that, for example, TX 6 and SH 6 are the same highway.
Once upon a time, I'd get directions that had things in them like:

Turn right on TX 6
Continue on SH 6
Continue on TX 6
Continue on SH 6
Continue on TX 6 ... etc

Granted, OSRM still doesn't handle it gracefully when another highway
multiplexes for a stretch, but at least one might be able to figure out
which highway one's supposed to stay on when it's ref'd the same across
the board. When it's not, it becomes much trickier.


That's a good point: it is certainly important that an individual route 
or road be tagged consistently, both its ref and (to the extent 
possible) its name, so that routers and tools like Nominatim can 
aggregate ways into roads.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] State highway refs (was Re: New I.D Feature)

[Minh Nguyen]

On 2014-11-30 10:41, stevea wrote:

My two cents:  I must say that here in California, I've made it a habit
to remove the County Route designation (CR) which precedes a ref
number in our County Route system.  For example, NE2 (a banned-from-OSM
former contributor for those unfamiliar with that history) entered ref
tags for many G2, N1... county routes as CR G2 and CR N1.  That, in
my opinion, is so redundant (as G and N and A and S... are well-known
multi-county/regional-within-California county highway networks) as to
be true clutter.  People in California do know (and routing software,
renderers... SHOULD know) that A1, G2, N4 and S16 are county routes in a
lettered system where each letter represents a cluster of counties...at
least in California.


Some northwest Ohio counties post shields along section line roads that 
say A, B, C, etc. So far I've been tagging them like CR A, even though 
you'd be hard-pressed to find that style anywhere outside of OSM. 
Instead of reducing ambiguity, I wonder if the CR may cause very mild 
confusion, for example when a router tells its user to turn onto CR R.



Also, while SR (for State Route in California and other states) is
still legally correct, I still might change for consistency's sake any
SR prefix I see in a highway route relation ref tag to be CA
instead.  So, while SR 17 is correct, I much prefer CA 17 and will
change it to that if I see SR in a California highway route relation ref
tag.


Yes, usage is different in California. I've only ever seen SR on 
signage a few times, in rather obscure places. But in Ohio, it's ubiquitous.



I agree with what we (as OSM volunteers entering/editing data in our
map) now do, as well as what map styles/renderers and routing engines
do, as Minh notes above:  recognize the state abbreviation, SR or SH.
Yes, Michigan still has its M- routes, and I think OSM (both its human
editors and software components) should just learn to cope with that
(plus perhaps a few other states) as exceptions to this largely (though
not completely) applicable rule.  I believe we are pretty much there,
but we still have edge cases, data in the map and newer contributors who
are not completely familiar with these conventions in the USA.
Discussing it here helps, though wiki documentation and taginfo data
which are consistent across the fifty states is better.


My response to anyone who wants more consistency is that route relations 
are the way forward. They may be painful now but they make the data a 
lot less subject to interpretation.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] State highway refs (was Re: New I.D Feature)

[Minh Nguyen]

On 2014-11-29 19:31, Dave Mansfield wrote:

 From the Wiki

http://wiki.openstreetmap.org/wiki/United_States_roads_tagging

“The two letter abbreviation for the state per the United States Postal
Service's state abbreviation list
https://www.usps.com/send/official-abbreviations.htm, another
abbreviation used by the state (such as SR for State Road), or no
prefix. Different states may have different standards for which to use,
and there is no current inter-state standard.”

I take the “Different states may have different standards for which to
use” to mean that not all states use the two letter abbreviation and in
states that don’t we should use that states standard for example
Michigan uses M. The highway behind my house is M-15 and singed that way
so I would think it should be tagged that way. Am I reading the Wiki wrong?


Back in September, I collected some statistics on states that use 
something other than the state abbreviation in way refs:


https://lists.openstreetmap.org/pipermail/talk-us/2014-September/013604.html

tl;dr: 97% of Michigan's state routes are currently tagged with M or M-, 
and a couple other states are also contrarian in this regard.


On 2014-11-29 19:40, Paul Johnson wrote:
 I'm going to say that the wiki is presently wrong compared to consensus
 previously arrived at on the tagging list regarding this issue the last
 971151183 times that this has come up, largely as a result of previous
 efforts by NE2 to game the renderer...

I think NE2's ref efforts have largely been undone in states where 
mappers disagreed. (I undid several of his edits where he tried to 
reduce refs to parenthesized numbers.) But in the case of Ohio, we were 
already using SR and have continued to use it. (Ohio's shields have no 
lettering on them, but blade signs, variable message boards, etc. do say 
SR.) Next door in Indiana, I think IN has pretty much taken over.


In general, if you'd like to make systematic changes to data that seems 
intentional, it's a good idea to reach out to the mappers who entered 
it. And if you decide to go ahead with any ref editing, be sure to add 
any missing relations and relation roles.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] State highway refs (was Re: New I.D Feature)

[Minh Nguyen]

On 2014-11-29 21:27, Dave Mansfield wrote:

It makes sense the way you explain it. I was looking at it as a name of
the route and thinking it should me the same as signs etc. But not the
fact that routing engines and renderers will know it’s a state highway
based on the state abbreviation.


Do any routing engines currently care about prefixes on way refs?

From what I've seen so far, most of the map styles that use the ref tag 
to distinguish route networks will recognize either the state 
abbreviation, SR, or SH. Some renderers use the prefix to choose a 
state-specific shield, assuming any unrecognized prefix is for a county 
route (white rectangle at higher zoom levels). MapQuest only recognizes 
state/provincial abbreviations. Not that we should place too much stock 
in individual renderer decisions. :-)


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Who controls data: Google Maps, others erasing Hollywood sign, but it's in OSM

[Minh Nguyen]

The individual letter ways are currently tagged tourism=artwork. There's 
an outstanding request to have the Standard stylesheet render such ways:


https://github.com/gravitystorm/openstreetmap-carto/issues/855

In the meantime, would it be too much of a stretch to tag them 
barrier=wall too? That would get the letters on the map in some fashion, 
and after all they would generally impede you if you tried to walk right 
through them.


On 2014-11-26 09:30, Andrew Wiseman wrote:

That was me -- but I would argue it's an unusual way to tag it -- it's
not the individual letters that are important, it's the whole piece. You
wouldn't tag each president in Mount Rushmore and leave it at that,
right? To me the letters are secondary and to the whole. The FDR
Memorial in DC is the same way, each part is tagged, but there's a point
for the whole thing. Or maybe it should be tagged as an area, since the
sign takes up an area?

Andrew

On Wed, Nov 26, 2014 at 12:00 PM, Martin Koppenhoefer
dieterdre...@gmail.com
mailto:dieterdre...@gmail.com wrote:


2014-11-25 16:48 GMT+01:00 Andrew Wiseman
awise...@gmail.com
mailto:awise...@gmail.com:

Interesting, but now it doesn't render. I saw it was gone and
worried somebody from that article took it off. Can we include a
point in the relation for it, so that it does render?



Someone has indeed done this. IMHO we shouldn't duplicate the data
(or non-data, in this case there are no more tags than name and
tourism=attraction on the new node), we should find a way to render
the name from the relation without tagging for the renderer-hacks.
This would include changing osm2pgsql to deal with site-relations.

I couldn't find any ticket for site-relations in the osm2pgsql and
osm-carto repos, so I have added them.

cheers,
Martin

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site




--

600,000 DC residents don't have a vote in Congress --
http://www.dcvote.org/ http://www.dcvote.org/about/index.cfm


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




--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] admin level for US states

[Minh Nguyen]

On 2014-11-25 01:29, Martin Koppenhoefer wrote:


2014-11-24 21:18 GMT+01:00 Minh Nguyen
m...@nguyen.cincinnati.oh.us
mailto:m...@nguyen.cincinnati.oh.us:

Assuming this table reflects the actual state of the map, most
countries have chosen 4 for their state equivalents.



Actually, many countries do not have something like a state
equivalent, it is a particularity of the USA because they are a federal
republic.


I understand; I just meant that most countries have chosen admin_level=4 
for the second-level governmental authority, regardless of any autonomy 
or sovereignty. That is, most of the level 3 entries in the table are 
for entities that have no legislative or executive function. I don't 
think it was historically viewed as a problem that admin_level=4s in 
different countries had varying levels of autonomy.



This level-skipping scheme extends all the way down to the smallest
jurisdictions. Because the TIGERcnl import chose admin_level=8 for
municipalities, skipping 7, I was able to tag Ohio townships as 7
without demoting all the state's cities and villages. [2] Even
though neighboring Kentucky and West Virginia lack a level of
government between counties and municipalities, it makes sense to
keep cities in most states at the same admin_level, because they're
functionally equivalent. (Virginia is a notable exception.)



I was not going to get into discussion about cities and other lower
level admin entities. Please lets stick to the state question.


My point is that there's a pattern. Using 4 for states is not an 
arbitrary choice, but rather an intentional way of leaving room for 
additional detail.


Incidentally, [1] is silent on the question of Indian reservations, a 
topic that has come up periodically on this list. Is there any consensus 
on how to tag them? If so, it should be reflected in the table.



For context, there's an open pull request to have the Standard
stylesheet render country and state labels based on administrative
boundary polygons rather than place nodes. [3]



yes, this is also something I wanted to point to, because in the
discussion for this style change it was argued that some countries,
which currently do use level 3, should change that to level 4 (like the
US), and I was arguing the other way round, that the US should probably
change the states to level 3 instead.


It sounds like the intention is to preserve U.S. state labels at z4 (by 
promoting them to level 3) while demoting subdivisions of smaller 
countries to higher zoom levels (by keeping them at level 4). I'm all 
for a more readable map of Europe, but basing admin_levels on degrees of 
autonomy won't really solve the problem. Some federal republics have 
relatively small second-level divisions (e.g., Switzerland), while some 
very large second-level divisions happen to be provinces of Canada, 
which is not a federal republic.



Martin, how would the U.S. would be affected by this change? As it
stands, U.S. state boundaries and labels appear at z4 and above,
regardless of the state's size. Of the smallest states, Rhode Island
(RI) appears at z4 and z6+, Connecticut (CT) appears at z4+, and
Maryland (MD) and Delaware (DE) are both obscured at z4 by the label
for Washington, D.C.

At a glance, this change would seemingly omit most of the
Northeastern states' labels at z4.

It appears to set a minimum size of 750 way pixels at z4 and 3,000
at z5 for displaying a state's label. I don't really see those
states' two-letter refs as being clutter.



I am not sure why raising the importance would lead to less names
displayed. If this holds true, the stylesheet would have to adopt to
correct this IMHO.


Sorry, I should've been clearer. It seemed to me like the proposed 
stylesheet change would cause some labels to disappear at z4-5 without 
any changes to the data, because the stylesheet would enforce a minimum 
area, whereas currently it doesn't. But I haven't tried out the change, 
so hopefully I'm wrong and the U.S. will look good either way. :-)


[1] http://wiki.osm.org/wiki/United_States_admin_level

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] admin level for US states

[Minh Nguyen]

On 2014-11-25 06:54, Brad Neuhauser wrote:

Here is the most recent thread on the tagging list about Indian
reservations:
https://lists.openstreetmap.org/pipermail/tagging/2014-November/020160.html

Neither of the proposals mentioned in the thread advocates using admin_level


Thanks. I've updated the page; feel free to improve on it:

http://wiki.osm.org/wiki/United_States_admin_level

In particular, please update the table if you find that it doesn't 
reflect how a particular state is currently being mapped. The wiki isn't 
always clear about whether it's documenting current practice or an 
obscure proposal.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] admin level for US states

[Minh Nguyen]

On 2014-11-24 05:00, Martin Koppenhoefer wrote:

I wonder why US States are tagged as admin_level=4, wouldn't it be more
consistent with the rest of the map to have them tagged as level 3?


IIRC mappers in many regions of the world started out using 
even-numbered admin_levels only, skipping the odd numbers, so that more 
obscure groupings of jurisdictions could be inserted in the future 
without going fractional. And indeed, if you look at [1], admin_level=3 
has been used primarily for regions: groups of provinces that have no 
separate administrative authority. Assuming this table reflects the 
actual state of the map, most countries have chosen 4 for their state 
equivalents.


This level-skipping scheme extends all the way down to the smallest 
jurisdictions. Because the TIGERcnl import chose admin_level=8 for 
municipalities, skipping 7, I was able to tag Ohio townships as 7 
without demoting all the state's cities and villages. [2] Even though 
neighboring Kentucky and West Virginia lack a level of government 
between counties and municipalities, it makes sense to keep cities in 
most states at the same admin_level, because they're functionally 
equivalent. (Virginia is a notable exception.)


For context, there's an open pull request to have the Standard 
stylesheet render country and state labels based on administrative 
boundary polygons rather than place nodes. [3]


Martin, how would the U.S. would be affected by this change? As it 
stands, U.S. state boundaries and labels appear at z4 and above, 
regardless of the state's size. Of the smallest states, Rhode Island 
(RI) appears at z4 and z6+, Connecticut (CT) appears at z4+, and 
Maryland (MD) and Delaware (DE) are both obscured at z4 by the label for 
Washington, D.C.


At a glance, this change would seemingly omit most of the Northeastern 
states' labels at z4. It appears to set a minimum size of 750 way 
pixels at z4 and 3,000 at z5 for displaying a state's label. I don't 
really see those states' two-letter refs as being clutter. They're 
probably the most informative use of that space at z4 in a big country 
like the U.S. Unfortunately, they really clutter up the map in smaller 
countries, especially in Europe.


[1] http://wiki.osm.org/wiki/Tag:boundary%3Dadministrative
[2] http://wiki.osm.org/wiki/United_States_admin_level
[3] https://github.com/gravitystorm/openstreetmap-carto/pull/1134

--
m...@nguyen.cincinnati.oh.us


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