Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Josh Lee]

On Sun, Apr 28, 2019 at 12:10 PM OSM Volunteer stevea
 wrote:

> Does OSM tag these leisure=park?  "We" (the people, the Departments of 
> Parks...) do, yet should we in OSM?  This IS talk-us; a major reason I 
> brought this up here is that USA park tagging drifts from elsewhere as "more 
> generous with the tag."  Yet the tag has recently become more precise, 
> narrowing it from how it is often used in the USA.

If the wiki history
 is to be
believed, it looks like one editor besides yourself has unilaterally
decided to change the wiki page to refer to something which is not how
the tag is actually used.

Where is the consensus or vote? The wiki page says "Status: de facto"
which implies that the wiki page should document *actual usage* and
not some sort of idealist, narrow viewpoint.

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

Re: [Talk-us] Strange city boundary: Lee, Illinois

[Josh Lee]

I can think of at least six examples in Pennsylvania off the top of my head:
Trafford, McDonald, Shippensburg, Seven Springs, Telford, Falls Creek.

On Wed, Nov 14, 2018, 08:49  Hi,
>
> are there cities (admin level 8) in the USA which  part of two counties?
>
> see: https://wambachers-osm.website/images/osm/snaps_2018/lee.png
>
> left: Lee County
>
> right: DeKalb County
>
> there are some more, but i would like to know if that is ok. In Germany
> this is impossible.
>
> Regards
>
> walter/Germany
>
> --
> My projects:
>
> Admin Boundaries of the World 
> Missing Boundaries
> 
> Emergency Map 
> Postal Code Map (Germany only) 
> Fools (QA for zipcodes in Germany) 
> Postcode Boundaries of Germany
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] TIGER place confusion

[Josh Lee]

Use border_type=* for this. https://wiki.openstreetmap.org/wiki/Key:border_type

Usage is spotty at best but it looks fairly consistent to me. For
example in Pennsylvania admin_level=8 can have a border_type of city,
township, borough, municipality(?), or town (there's just one "town").
In New York admin_level=7 can have a border_type of town or city, but
I'm only seeing this on two cities and about a third of the towns.

Since a combo admin+place has both a boundary and a label node, is
there a rule of thumb for what tags go where? Does place=whatever go
on both? What about wikidata?

(?) border_type=municipality definitely came from TIGER, as it matches
Bethel Park, Monroeville, and Murrysville having an LSAD of
municipality. Pennsylvania's classification of home rule
municipalities is a bit fuzzy, since it's *also* still considered to
be a township or borough. I'll leave that one alone for now.
On Thu, Sep 27, 2018 at 7:50 AM Max Erickson  wrote:
>
> Many of the administrative boundaries imported from TIGER have a
> place= tag that reflects the legal type of incorporation of the
> municipality rather than a sensible value for the OSM place tag (which
> would give some hint about the relative prominence of the place).
>
> This confusion has gone under the radar, as openstreetmap-carto
> doesn't render place labels from ways and relations:
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/2816
>
> Deleting the imported place= values (or perhaps moving them to some
> other tag, say something like incorporation=) would directly make the
> data more accurate and improve maps that render place areas without
> accounting for the confusion in the data.
>
> What do people think about deleting (or adjusting) the place tag from
> imported US administrative boundaries?
>
>
> Max
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-us] admin_level=8 boundaries in Parker County, TX

[Josh Lee]

Some of the US boundary data gives "USGS DRG" as a source. This seems
to stand for "Digital Raster Graphic" files. It is my suspicion that
this raster was vectorized as part of an import process, but I have no
documentation to support that. Still, I consider it a convenient
explanation for why the data doesn't seem to match anything currently
available from TIGER.

Here at the PA/WV state line there is an anomaly of about 100m:
https://osm.org/go/ZWmfhbe
The current OSM data have the PA/WV boundary as a straight line, but
TIGER says it's not. That's the only reasonable explanation for the
Weirton city border to jut into PA by this much — the city border is
true to currently available TIGER data, and state border needs to be
updated.

On Mon, Jul 9, 2018 at 2:36 PM Martijn van Exel  wrote:
>
> Frederik,
>
> These boundaries are often very outdated. I don't know which TIGER vintage 
> they were imported from. I have been replacing them piecemeal from current 
> TIGER as I work, but we should probably replace them altogether and have a 
> plan to keep them updated. I don't think they interfere with other features 
> much, but obviously that should be researched.
>
> As for this specific case, current boundary from TIGER 2017 in brown, OSM in 
> green: https://cloud.rtijn.org/s/bpxPffp6ycm8rF7
>
> --
>   Martijn van Exel
>   m...@rtijn.org
>
> On Mon, Jul 9, 2018, at 05:10, Frederik Ramm wrote:
> > Hi,
> >
> > I've recently traced a little bit of stuff in Annetta, TX. The area I
> > looked at had a lot of potential for someone interested in mapping from
> > aerial imagery (houses, tracks, driveways, parking missing; some
> > driveways tagged as highway=residential etc.) and I did what I could in
> > the small area I worked on, but there was one thing I didn't dare touch
> > and that's admin boundaries. The ones I encountered often cut straight
> > through residential buildings and I thought that can't be right, but I
> > know too little about boundaries in the US to fix any of it. I am
> > specifically talking of
> >
> > https://www.openstreetmap.org/relation/114418
> >
> > and
> >
> > https://www.openstreetmap.org/way/33245202
> >
> > - maybe someone local wants to give them a closer look. Maybe it's ok
> > the way it is. The Annetta North boundary is relatively straight but has
> > one wobbly bit, is there maybe a waterway missing in OSM?

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

Re: [Talk-us] I-69 east west vs north south

[Josh Lee]

While it might be uncommon for two-digit Interstate highways to change
their directions, it's quite common for three-digit ones to do so, and
it shouldn't be treated any differently.

Some examples of changing direction, all of which are mapped as a
single relation for the state they're in, with cardinal directions for
the roles.

I-275 (Cincinnati)
I-270 (Columbus)
I-465 (Indianapolis)
I-495 (Washington, D.C.)

None of these have separate relations for the opposite directions,
just a single relation for the whole highway in that state.

Some other examples:

- I-64 in Virginia. South of I-264, it loses East/West signage (this
fact is not currently mapped in OSM)
- US 98 in Florida changes from EW to NS and back to EW (this fact is
not currently mapped in OSM).
- Ohio SR 104 changes from North/South to East/West near I-71, just
south of Columbus (mapped as cardinal directions for roles).

On Fri, Sep 22, 2017 at 1:32 AM, Bill Ricker  wrote:
> He seems to be correct, using the (not usable for mapping but usable
> to inform discussion) G-Streetview, I do indeed see signage as
> described, which defies commonly understood version of Fed standards.
> Not just BUSINESS route, not just when cotracking i-94, but actual
> green, solo "WEST 69 MILE 198" with red white and blue shield.
>
> Do we know if whether there is a Fed exemption, the Feds actually
> acknowledge that I-69 actually E-W beyond a certain point, and so can
> be E-W here?  Or if  the State of Michigan is defying Federal
> standards in the interest of being understandable? After the Feds
> threatened to pull our block grant $$ if we didn't renumber our exits
> their way, I'm amazed they're letting this slide when they could just
> rename the E-W section I-369 E-W  and it'd be a compliant extension of
> a N-S route. Perhaps the bureaucracy can be reasonable. [I spent a few
> years with DOT, not in Highway. Nice folks really.]
>
> (Probably not the only exception. There are 1xx/2xx/3xx/4xx that don't
> fit the spur/loop rule too.)
>
>
> (Frankly, I'm surprised any of 69's escutcheon route markers remain
> unstolen, like the 420 mile markers that keep wandering off.)
>
> So back to original question(s) --
> - who should fix the E-W section of I-69 to be E-W
> - how - split relation? relation of relation?
> - from where ?  At what point does signage change to E-W ?
>[and for mapping purposes no I'm NOT going to suggest we get that
> from a copyright source like StreeView, that needs free & open ground
> truth. ]
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-us] Territorial municipalities, Guam's villages

[Josh Lee]

TIGER Line gives these village boundaries in the "County Subdivisions" file.
https://www2.census.gov/geo/tiger/TIGER2016/COUSUB/tl_2016_66_cousub.zip

The existing boundaries in Guam seem to be tagged as
[boundary=census], since they're Census-Designated Places imported
from an older version of TIGER. The 2016 vintage is better aligned
with the actual boundaries.


On Tue, Jul 18, 2017 at 10:44 AM, Max Erickson  wrote:
> The image the linked image was traced from provides no provenance
> (beyond "Own work"). It's tough to go from there to being sure that
> derived data is okay to contribute to OSM.
>
>
> Max
>
> ___
> 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