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

[Mark Wagner]

The problem with "suburb" is like the problem with "football": there
are two meanings, and a very large population that doesn't know about
the other meaning.  That guarantees widespread misuse.

-- 
Mark

On Thu, 24 Sep 2020 11:55:55 -0400
Brian Stromberg  wrote:

> If suburb is a commonly understood and useful concept in other
> countries then it seems good to keep it around. I don't really know
> what the implications are of retirement or what the process would be.
> I would instead advocate for country-specific guidance on its usage.
> 
> --
> Brian
> 
> 
> On Thu, Sep 24, 2020 at 11:38 AM Paul Johnson 
> wrote:
> 
> > On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg
> >  wrote:
> >  
> >> This contradicts the OSM wiki but seems like the only way to avoid
> >> confusion.
> >>  
> >
> > Much like sport=american_football vs sport=soccer, this makes sense.
> > Maybe it's time to retire place=suburb as a tag due to its
> > ambiguity?
> >
> >  
> >> The only reason I can think of to use 'suburb' as a tag in the
> >> context of the United States would be if a tag indicating 'central
> >> city' or something similar was introduced.
> >>  
> >
> > Ostensibly, that's what place=city was supposed to be, but not
> > helping OSM would be that some places have cities and towns of
> > different legal importance (Oklahoma), or "it's a city or it's not
> > a city" with no room for nuance (Oregon).  Not making things any
> > easier is how lopsided populations are in the US, a midsize
> > municipality is about 5500 people.  Once you get to about 90,000,
> > you're in the top 2% largest anything in the 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

Re: [Talk-us] Potential Import of Addresses for Thurston County, WA, USA

[Mark Wagner]

On Sun, 09 Aug 2020 03:53:55 -0700
Raven King  wrote:

> Hello:
> 
> I discovered that Thurston County, WA publishes a database of
> addresses stored as gps pins inside a shape file. 
> The data can be found here:
> https://gisdata-thurston.opendata.arcgis.com/datasets/thurston-address-points-tcomm?geometry=-122.915%2C47.023%2C-122.914%2C47.023
> 
> The license can be seen where it has a link labeled "Custom License"
> next to a picture of a lock. I didn't see anything in there that would
> prohibit our use of this, but extra eyes are needed. 

The most interesting clauses in the license is:

"Users are not authorized to license, re-license, assign, release
publish, transfer, sell or otherwise make available any portion of
these Data, or any information from GIS data derived from these
Datasets, to a third party in any format revealing Thurston County as
the source of the data."

This solves the attribution issue quite nicely: we're *forbidden* to
credit this data to Thurston County. 

> The database has 128,639 addresses. My goal would be to import the
> entirety of it into OSM, as Thurston county has very few addresses in
> OSM. They would be imported as points, since the database has them
> stored as points.
> 
> The caveats I see are as follows:
> * The database probably has some addresses that are wrong. While
> everything I could verify has been correct, I only checked about 100
> addresses. 

A quick look at the data in JOSM doesn't reveal any large-scale
problems.  Some observations: 

* Almost every point corresponds to a building or some other object
  (eg. a parking lot) that would reasonably be expected to have an
  address.  There are a few oddities, such as a wetland.

* There are a few multi-story apartment buildings where the address
  points don't correspond to the actual locations of the units.

* I think you'll want to build street names off the "StreetName",
  "St_PreMod", "St_PreDir", "St_PreType", "St_PosDir", and "St_PosType"
  fields rather than any of the other fields.

* There are seven duplicate addresses in the data.

-- 
Mark

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

Re: [Talk-us] Cycleway Crossings

[Mark Wagner]

On Fri, 07 Aug 2020 07:11:01 -0400 (EDT)
"Doug Peterson"  wrote:

> I have noticed in my area where some people have been adding
> crossings to a designated cycleway (named and signed as a bike
> trail). The crossings are fine. It is that the crossing is then been
> changed to a footway. 
> 
> I have looked at the highway=cycleway wiki and not seen anything
> addressing crossings. There was one screenshot that seemed to show
> intersections or crossings with roads remaining as cycleways. Before
> I made any effort on changing these back I wanted to ask if there was
> any other knowledge out there about this.

This almost always happens because someone's adding crosswalks using
iD, types "crosswalk" into the tag search, sees "Marked Crosswalk"
(highway=footway, footway=crossing, crossing=marked) as the first hit,
and fails to notice "Marked Cycle Crossing" (highway=cycleway,
cycleway=crossing, crossing=marked) as the fourth.

-- 
Mark

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

Re: [Talk-us] Labeling county roads (Idaho)

[Mark Wagner]

On Sun, 21 Jun 2020 21:45:19 +0900
tj-osmw...@lowsnr.net wrote:

> Newby here.
> 
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn"
> name but TIGER2019 data also has names such as "Acacia Avenue". I
> think most map users would want to use the "Acacia Avenue" name as it
> what would be listed in postal addresses and they'd want to search it
> in applications such as OSMand. Question is how to handle this. Also,
> what to set the "ref" to for county roads.
> 
> There's not much information on the roads tagging page:
> 
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2
> 
> Proposal: use alt_name for "County Road nn" and name for "Acacia
> Avenue" where a name is given. (I've seen name_1 used but this is not
> really a "standard" OSM tag, AFAIK.)
> 
> For ref: set the ref to the county road number until someone can come
> up with a better proposal...
> 
> Any Idahoans have any information?

Not an Idahoan, but I've driven in the area from time to time.  The
roads I'm familiar with don't have a "County Road" designation on the
sign, just the road name.

-- 
Mark

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

Re: [Talk-us] USGS Topos, "Draw", "Gulch", etc.

[Mark Wagner]

On Mon, 1 Jun 2020 11:56:57 -0600
Mike Thompson  wrote:

> Do the names on the USGS Topo Maps that end in "Draw", "Gulch", and
> similar terms refer to a stream, or a valley?  I have always assumed
> a stream, and applied the name to waterway=stream in OSM, but perhaps
> that is not correct.

What color is the name?  If it's blue, it refers to a water feature.
If it's black, it could refer to either the water or some other
geographic feature: USGS cartography for this has changed over time.

-- 
Mark

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

Re: [Talk-us] Jefferson Notch Road and latest "GPS made me do it" in the news

[Mark Wagner]

On Thu, 2 Jan 2020 14:47:35 -0500
Bill Ricker  wrote:

> Kevin asks,
> > is Jefferson Notch Road actually closed to wheeled vehicles in
> > winter or  
> just not maintained?
> 
> Per copyright news reports, it is signed as closed to wheeled
> vehicles, open to snow-machines only, in winter.
> (As should be obvious, to correctly tag this according to our
> license, we do need some on-the ground or license0compatible
> verification of the facts form the news, as well as a decision on
> what tags to use.)

In the United States, facts can't be copyrighted, only specific ways of
expressing them.  If a news article says "the road is closed in the
winter from Wherezit Junction to Anytown", you can freely extract the
fact of the closure, look for the OSM ways corresponding to the
description, and apply a "closed in the winter" tag.

(If the news article instead has a map of the closure, the copyright
situation becomes more questionable, because now you're copying not
just the facts of the closure, but possibly the way they're expressed
as well.)

-- 
Mark

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

Re: [Talk-us] Typical maxweight signs in USA? (editor developmnent question)

[Mark Wagner]

On Tue, 25 Jun 2019 08:47:39 -0700
Peter Dobratz  wrote:

> 
> Reading this page, I see the potential ambiguity extends deeper than I
> realized (short ton, metric ton, long ton)
> https://en.wikipedia.org/wiki/Tonne
> 

"Ton" in the United States is *always* the "short ton" of 2000 pounds.

-- 
Mark

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mark Wagner]

On Thu, 21 Mar 2019 13:23:48 -0600
Martijn van Exel  wrote:

> > On Mar 21, 2019, at 12:35 PM, Mark Wagner 
> > wrote:
> > 
> > On Wed, 20 Mar 2019 21:46:59 -0600
> > Martijn van Exel mailto:m...@rtijn.org>> wrote:
> >   
> >>> On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny
> >>>  wrote:
> >>> 
> >>> I plan to run an automated edit that will revert part of the GNIS
> >>> import that added them and delete objects that never had any
> >>> reason to appear in the OSM database in any form, at least
> >>> according to GNIS data.
> >>> 
> >>> Please comment no matter what you think about this idea! I will
> >>> not make the edit without a clear support so please comment if
> >>> you think that it is a good idea and if you think that it should
> >>> not be done. 
> >> 
> >> 
> >> Thanks for bringing the idea up. It actually did come up fairly
> >> recently on Slack
> >> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
> >> 
> >> My view is that we would be missing an opportunity to have mappers
> >> review these locations and update the areas concerned. These nodes
> >> exist mostly in ‘undermapped' / remote areas that could use some
> >> human mapper attention. So I’d be in favor of trying to resolve
> >> this using some human driven cleanup first.  
> > 
> > My experience is that this will mostly just make things worse.
> > 
> > There was a MapRoulette task a while back for cleaning up
> > unmodified GNIS-imported schools.  There were only a few of them
> > left around me, but the most common result was that an armchair
> > mapper would drag the node to a nearby non-house-looking building,
> > trace the building, and merge it with the imported node.  Not one
> > of these was actually a school.
> >   
> 
> Do you think this could have been prevented had there been better
> instructions?

No, I don't.  Sorting out which GNIS nodes are outdated and which are
merely misplaced isn't something that can reliably be done from aerial
imagery.  For something like "(historical)" GNIS nodes, it's better
just to delete all of them.

-- 
Mark

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

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mark Wagner]

On Wed, 20 Mar 2019 21:46:59 -0600
Martijn van Exel  wrote:

> > On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny
> >  wrote:
> > 
> > I plan to run an automated edit that will revert part of the GNIS
> > import that added them and delete objects that never had any reason
> > to appear in the OSM database in any form, at least according to
> > GNIS data.
> > 
> > Please comment no matter what you think about this idea! I will not
> > make the edit without a clear support so please comment if you think
> > that it is a good idea and if you think that it should not be
> > done.   
> 
> 
> Thanks for bringing the idea up. It actually did come up fairly
> recently on Slack
> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
> 
> My view is that we would be missing an opportunity to have mappers
> review these locations and update the areas concerned. These nodes
> exist mostly in ‘undermapped' / remote areas that could use some
> human mapper attention. So I’d be in favor of trying to resolve this
> using some human driven cleanup first.

My experience is that this will mostly just make things worse.

There was a MapRoulette task a while back for cleaning up
unmodified GNIS-imported schools.  There were only a few of them left
around me, but the most common result was that an armchair mapper would
drag the node to a nearby non-house-looking building, trace the
building, and merge it with the imported node.  Not one of these was
actually a school.

-- 
Mark

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

Re: [Talk-us] US Bureau of Land Management Boundaries

[Mark Wagner]

On Sat, 5 Jan 2019 21:19:10 -0600
Ian Dees  wrote:

> Hi Brad, thanks for proposing this import and posting it here.
> 
> I would strongly prefer that we not import boundaries like this into
> OSM. Boundaries of all sorts are almost impossible to verify with
> OSM's "on the ground" rule, but BLM boundaries in particular are such
> an edge case (they have no other analog in the world, really) and
> almost never have apparent markings on the ground to check. Since
> these boundaries aren't visible, this data can never be improved by
> an OpenStreetMap contributor. The boundaries are defined by the
> government, and any sort of change to them would make them diverge
> from the official source.

I don't know about BLM land in general, but I was able to verify a
large portion of Fishtrap Recreation Area
(https://www.openstreetmap.org/relation/6154436) by tracing fence lines
and looking for "No Trespassing" signs.  I suspect most of the other
BLM rangeland can be mapped this way as well.

-- 
Mark

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

Re: [Talk-us] Address data for Miami Florida United States

[Mark Wagner]

On Mon, 17 Sep 2018 02:13:46 -0500
Aaron Forsythe  wrote:

> zip codes – Zip codes are USPS routing codes.  They do not align to
> cities and may even cross over each other often.  USPS only uses the
> city field on mail as a backup to zip codes.  They fudge the cities
> intentionally to make it easier on their sorting machines.  I’d be
> cautious when getting city data from USPS based on zip codes.

"City" on a USPS address isn't the city, and never has been.  It's the
name of the sorting office.  This usually corresponds to the name of
the city (and for places with only one post office, the name of the
post office), but not always.  For unincorporated areas, it's usually
the same as the name of the nearest incorporated area, but not always:
unincorporated areas can still get post offices.

Postal Zip codes are point clouds, not areas (and Zip+4 codes even more
so).  Census zip codes are areas, but they've only got a rough
correspondence to the postal codes.

-- 
Mark

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

Re: [Talk-us] Maximum number of tasks on US tasker

[Mark Wagner]

What I've observed is that MapRoulette works well with tasks that
are highly localized and don't require much thinking.  "A road crosses a
railroad here: should it be a crossing, or a bridge?" is a good
MapRoulette task, because unusual situations are rare, and the user
doesn't need to consider anything outside the focus point. "This road
segment hasn't been touched in ten years. See if there's anything wrong
with it, and if so, fix it." is bad: the road segment might be a
twenty-mile-long composite of a logging road, a rural highway, and a
driveway, badly aligned, with half the logging end of the road having
been abandoned in the 1970s. The average MapRoulette user is only going
to spot one or two of the problems, and in fixing them, could well
introduce more problems.

-- 
Mark

On Mon, 07 May 2018 22:25:30 -0600
Martijn van Exel  wrote:

> I'd like to learn more about that massive mess and how we can prevent
> that in the future, Paul.To my mind, most TIGER clean up consists of
> atomic tasks, which is where MapRoulette would typically come in
> really handy. (Remember the 70,000 connectivity errors we fixed in
> 2013/4, and the 100,000+ missing railroad crossings which were also
> attributable to TIGER .) But perhaps you have something different in
> mind. I'd like to think MapRoulette can help, also because not
> everybody prefers the same style of working on large projects.--
>   Martijn van Exel
>   m...@rtijn.org
> 
> 
> 
> On Mon, May 7, 2018, at 21:12, Paul Johnson wrote:
> > MapRoulette really made a massive mess of the lanes situation that a
> > more systematic and big-picture effort is starting to get a handle
> > on in Oklahoma.  I think MapRoulette works well for smaller-picture
> > stuff, and is more complimentary to StreetComplete and not terribly
> > great at directing more complicated projects.> 
> > I've restarted my efforts at a county level to avoid having a huge
> > number of tasks that fall largely in Texas, since it seems that the
> > tasking manager is ultimately only capable of dealing with
> > rectangular project areas even if you feed it a more complicated
> > polygon via JSON.> On Mon, May 7, 2018 at 9:32 PM, Martijn van Exel
> >  wrote:>> I’d like to see how TM and MapRoulette could
> > be complementary in this  
> >> effort. I know Clifford has set up a TIGER related challenge on
> >> MapRoulette, and I have done this in the past as well.>> 
> >>  I feel that TM can be good for a general ask like ‘check all TIGER
> >>  residential roads in rural areas in this cell, demote to track /
> >>  unclassified or delete as needed’ whereas MapRoulette may be
> >> useful for more specific TIGER cleanup related tasks?>> 
> >>  Thoughts?
> >> 
> >>  Martijn
> >>   
> >> > On May 5, 2018, at 12:49 PM, Paul Johnson   
> >> > wrote:>>  >   
> >>  > I think it's somewhere between 2000 and 2100.  I'm working on
> >>  > eventually handling the entire state of Oklahoma on a TIGER
> >>  > cleanup and enrichment.  Ideally, I'd like to do the whole state
> >>  > at once (just for variety's sake and for even coverage), but
> >>  > county by county works, too.  If there's a limit for the number
> >>  > of times an area can be split, this could really use some work,
> >>  > too, since 3 (based on tasks2 limit) is not enough.  A 4000 or
> >>  > 5000 task limit should be sufficient for a single county (though
> >>  > definitely won't start off with that many tasks, and almost
> >>  > certainly won't hit that many tasks over the life of a project)
> >>  > if the split limit is increased (like, at least 5, possibly
> >>  > higher just to be on the safe side).>>  > 
> >>  > The idea is to basically keep it in that 75-100 item range per
> >>  > task just to keep it manageable (item count based on the
> >>  > resulting selection when using JOSM search to replace selection
> >>  > and searching for highway=* type:way).>>  > 
> >>  > On Sat, May 5, 2018 at 12:57 PM, Ian Dees   
> >>  > wrote:>>  > I don't know. Do you see a limit somewhere? I'm
> >>  > happy to increase it.>>  > 
> >>  > On Sat, May 5, 2018, 12:35 Paul Johnson   
> >>  > wrote:>>  > What is the maximum number of tasks possible on the
> >>  > US tasker, and is it possible to change that?>>  >
> >>  > ___ 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 mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Satus CDP

[Mark Wagner]

Satus has a population of 750 people scattered across 70 square miles
of farmland.  The largest population center I've been able to find from
aerial imagery has ten buildings, three of which look rather abandoned
in Google Street View.

Looking through Google Books results, it definitely *was* a community:
I'm seeing references from the 1910s to the 1940s.  After 1945, though,
the search results are either for the CDP or are Satus mailing
addresses.

As far as I can tell, it's not an unincorporated community in the way
that someplace like Anatone[1] is, or a recognized region such as
Mead[2].  The Satus CDP appears to simply be a bookkeeping region
for the census that was given an old name.  I'd have no trouble calling
it a "place=locality", but calling it any sort of "significant
community" seems like an exaggeration.

[1]: https://en.wikipedia.org/wiki/Anatone,_Washington
[2]: https://en.wikipedia.org/wiki/Mead,_Washington

-- 
Mark

On Mon, 26 Feb 2018 20:27:45 -0600
Chris VandeVenter  wrote:

> I would leave it in place.  Census designated place is a place that
> is not incorporated as a city  under state law but is still a
> significant community. It’s been a large debate on Wikipedia about
> their, but general consensus is they are significant enough to
> include. The CDP boundary follows what the community would have if it
> were an incorporated city. For example, U.S. Air Force bases are
> generally treated as census designated places. 
> 
> Chris VandeVenter
> Sent from my iPhone
> 
> > On Feb 26, 2018, at 6:59 PM, Clifford Snow
> >  wrote:
> > 
> > In the middle of the Yakama Nation Indian Reservation sits Satus
> > [1] that as far as I know only exists in some Census bureaucrat
> > world. Asking around here I haven't found anyone familiar with the
> > area. Wikipedia [2] doesn't help much either.
> > 
> > I'd like to remove it from OSM. What reasonable checks do I need to
> > do before deleting it. Or do they belong in OSM and I should leave
> > it alone. 
> > 
> > I should add that the reason I want to delete it is because
> > currently shares a boundary with the Yakama Nation. The boundary
> > needs updating.
> > 
> > 
> > [1]
> > https://www.openstreetmap.org/relation/237292#map=11/46.2322/-120.1180
> > [2]
> > https://en.wikipedia.org/wiki/en:Satus,%20Washington?uselang=en-US
> > 
> > Thanks,
> > Clifford
> > 
> > -- 
> > @osm_seattle
> > osm_seattle.snowandsnow.us
> > OpenStreetMap: Maps with a human touch
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us  


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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Mark Wagner]

On Mon, 12 Feb 2018 13:25:02 -0800
OSM Volunteer stevea  wrote:

> On Feb 12, 2018, at 1:07 PM, Tod Fitch  wrote:

> > Anyway, what is the current best practice dealing with TIGER tags
> > once the road has been surveyed and corrected? Remove all TIGER
> > tags or just the reviewed tag?  
> 
> As I am not familiar with the "things you've read," while also
> wondering myself whether additional TIGER tags (tiger:cfcc,
> tiger:zip, etc.) should remain or be deleted, I also pose this
> question to the greater talk-us community.  What DO we do with these
> additional TIGER tags as we endeavor to "clean up TIGER" in the USA?
> Is there consensus on a definitive "best practice" for removing or
> leaving them?  (Consensus is clear that we remove tiger:reviewed=no
> after we've reviewed the way).
> 
> Our wiki https://wiki.osm.org/wiki/TIGER_fixup is silent on this
> particular issue (of removing or leaving additional tags).  BTW
> another wiki of ours, https://wiki.osm.org/wiki/TIGER_Edited_Map
> gives a nice overview/documentation of the Ito map.
> 
> We might create a new thread or keep it in this one:  but even as a
> seasoned TIGER cleanup volunteer, I don't know what to do with
> additional TIGER tags, and I guarantee everybody reading this that
> I'm not alone there!

I find the "tiger:county" tag to be useful as a quick way to figure out
where I am when looking at a changeset or otherwise am zoomed in on the
map while editing.  "tiger:zip" would be useful when adding addresses if
I could trust it, but it's wrong too often.  The rest of the tags
aren't useful because either they can be derived from the OSM-relevant
tags on the road, or they're wrong/outdated.

-- 
Mark

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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Mark Wagner]

On Mon, 12 Feb 2018 12:11:29 -0800
OSM Volunteer stevea  wrote:

> Remember, after you review tags and alignment of TIGER data, REMOVE
> the tiger:reviewed=no tag, don't change its value to yes.

I don't remove the "tiger:reviewed=no" tag unless I've verified the
name and approximate classification of the road, in addition to the
alignment.  I've found too many cases where TIGER has the wrong name
for a road.

-- 
Mark

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

Re: [Talk-us] Multipolygonizing

[Mark Wagner]

On Mon, 20 Nov 2017 10:15:01 -0800
Evin Fairchild  wrote:

> (I couldn't for the life of  me figure out how to add a way to a
> relation!)

Select a way currently part of the relation.  Shift-click on the way
you want to add.  Select "Update multipolygon" from the "Tools" menu,
or hit Ctrl+Shift+B.  Simple.

Of course, this only works for ordinary relations.  If the way you
clicked on is shared by two or more relations, you need to go
through the far more complicated method of playing with the
relation-editor dialog.

-- 
Mark

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

Re: [Talk-us] Trunk

[Mark Wagner]

On Sat, 14 Oct 2017 22:40:16 -0700
Bradley White  wrote:

> If we can determine importance (which is what the 'highway=' tag
> fundamentally represents per the wiki) solely by what's on the ground,
> why not just tag what's physically there, ditch the 'highway' tag
> altogether, and let the renders handle it with their own algorithms?

Because we can't.

WA-290 at Starr Road is two paved lanes wide, with 12-foot lanes and
4-foot paved shoulders.  It has a speed limit of 45 mph.

WA-261 at Lyons Ferry Fish Hatchery is two paved lanes wide, with
11-foot lanes and 4-foot paved shoulders.  It has a speed limit of 50
mph.

Two very similar-looking roads, so they should have similar
classifications, right?  WA-261 runs from nowhere much to nowhere
much, and sees maybe 300 vehicles a day.  In contrast, WA-290 is the
other major route between the Spokane and Coeur d'Alene metropolitan
areas (the main route is the interstate), and sees 13,000 vehicles a
day go by.  If you omitted WA-261 from a map, almost nobody would
notice.  If you omitted WA-290, people would discard your map as
useless.

I've driven both roads, and they *feel* very different.  But it's not a
difference that I can put into numbers -- at least, not without putting
a traffic counter out for a few days.

-- 
Mark

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

Re: [Talk-us] dubious church node

[Mark Wagner]

On Sat, 30 Sep 2017 15:11:06 +0700
Dave Swarthout  wrote:

> "Second, many entries have their coordinates specified using the old
> NAD 27 datum, but somewhere along the line, that fact was lost and the
> coordinates were assumed to be in either NAD 83 or WGS 84.  This
> results in an offset that increases the further you go from central
> Indiana; the offset in Alaska is upwards of a hundred meters to the
> west."
> 
> Wow, thanks for that. If I understand what you're saying, this means
> many of the old GNIS nodes will be positioned about 100 meters east
> of where they should be? Or do I have your statement turned around?

Depending on where in the process the error was made, it could go
either way, but in my experience, the nodes are usually positioned too
far to the east.

-- 
Mark

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

Re: [Talk-us] dubious church node

[Mark Wagner]

On Sat, 30 Sep 2017 06:56:31 +0700
Dave Swarthout  wrote:

> Glad you mentioned that GNIS import, Ian.
> 
> This isn't a pressing issue but I've been doing considerable mapping
> in Alaska and encounter GNIS features constantly. Many of them are
> nodes and refer to mines, usually abandoned mines, and contain
> tagging that JOSM complains about, for example, using landuse=quarry
> on a node. Sometimes I delete that tag and add man_made=mineshaft or
> similar tagging but it's often not clear if the node is in the proper
> location. The newer, high-resolution imagery will often suggest a
> more likely spot for the node, and sometimes I'll move the node
> there, but usually it isn't obvious. There are also duplicate nodes,
> that is, mines having the same name but in a slightly different
> position and carrying a different GNIS reference number.
> 
> Can you provide some guidance about the accuracy of the positions, the
> duplication, and perhaps weigh in on possible tagging scenarios?

In my experience, there are two common sources of position error in
GNIS:

First, many GNIS entries are pulled off of old USGS topo maps.  These
are of limited resolution, and you can't get a position more accurate
than about a city block.  It's not much of an error, but when you're
used to coordinates that will lead you to a specific door, it's
something to keep in mind.

Second, many entries have their coordinates specified using the old NAD
27 datum, but somewhere along the line, that fact was lost and the
coordinates were assumed to be in either NAD 83 or WGS 84.  This
results in an offset that increases the further you go from central
Indiana; the offset in Alaska is upwards of a hundred meters to the
west.

For churches, hospitals, post offices, and other facilities in towns,
it's not unusual for them to take the same coordinates as the center of
the town.  This mis-positioning may be combined with one or both of the
above.

The other common error you'll encounter is that the tagging is only
approximate as to type.  This is most obvious with medical facilities:
everything from doctors' offices to retirement homes gets tagged as
"amenity=hospital".  More common but less noticeable is that a wide
range of vaguely recreation-related things get tagged as "leisure=park"
-- in particular, watch out for historic markers tagged as such.

Your quarries are subject to this same type-approximation: everything
from a county road department's gravel pit to an extensive complex of
mineshafts is tagged as "landuse=quarry", as are some mining-related
industrial facilities.

-- 
Mark

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

Re: [Talk-us] Missing imagery in JOSM

[Mark Wagner]

On Wed, 27 Sep 2017 12:14:03 -0400
"Mark Bradley"  wrote:

> What happened to the USGS topographic map imagery that was available
> in JOSM until a few days ago?

Still there for me, though something's changed: when you zoom out, it
no longer switches away from the 1:24000 maps, but instead displays
them scaled down.

-- 
Mark

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

Re: [Talk-us] Recent Aerial Photo Imagery Changes

[Mark Wagner]

On Tue, 26 Sep 2017 11:07:55 +0300
Rihards  wrote:

> On 2017.09.26. 03:09, David Wisbey wrote:
> > Fellow mappers,
> > 
> > So what's up with the recent changes in our aerial photo imagery?
> > 
> > It used to be so simple and I followed the rule(?) of making sure
> > features line up with Bing imagery.  I'm wondering about that now -
> > big time. I have been mapping in a variety of locations lately and
> > the situation is different in each location.  In Minnesota, for
> > instance, I really don't want to use Bing imagery unless at some
> > zoom level it shows me the most current images (especially in high
> > growth areas like northwest Rochester). And when recently updating
> > an intersection in southwest Minnesota to a new roundabout, I was
> > aghast at what Bing was giving me and so only used it where the
> > quality/resolution "wasn't TOO bad". Sad. Mapbox, ESRI and other
> > imagery were all much better choices, especially between Blomkest
> > and Hutchinson, MN.
> > 
> > So the main question now is: Does the "line up with Bing" rule
> > still stand? In recent work around the city of Virginia, Minnesota
> > (re-routing of US 53) I felt I had to use Mapbox imagery and so
> > lined up what I could with it rather
> > than Bing. In most cases, they matched or were off by only 2 meters
> > or so.  
> 
> there has never been a rule to "line up with Bing", quite the
> opposite - you should not unconditionally line up with any imagery
> layer, unless you know for sure it's extremely precise.
> regarding imagery layers like sat/ortophoto, it has always been
> suggested to check and align them to gps traces from the area (while
> keeping in mind that one or few traces might be all wrong, the centre
> line of many traces being the best).

When possible, I line up imagery to Strava cycle heatmaps -- Strava's
already done the work of averaging dozens/hundreds of traces for you.
When doing this, keep in mind that, especially in hilly areas, cyclists
sometimes prefer one direction of travel over another, biasing the peak
to one side or the other.  Alignment to Strava works best when you've
got two distinct peaks from the shoulders of a road, or a single narrow
peak from a dedicated bicycle route.

With the old Bing imagery, I usually didn't bother, since the
disagreement between Bing and Strava was usually less than the
resolution of the imagery.  With the new imagery, I prefer not to use
the imagery unless I can align a nearby feature to something I know is
reasonably accurate (and when mapping locally, I don't use Bing at all
-- ESRI is newer, better-aligned, and has resolution that would let
me map the shingles on a roof.)

-- 
Mark

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

Re: [Talk-us] Speed limit editing in Detroit

[Mark Wagner]

On Fri, 5 May 2017 12:55:55 +
Horea Meleg  wrote:

> Hello all,,
> Me and my Telenav colleagues are planning to start editing speed
> limit in Detroit area and we found the following situation:
> 
>   1.  There's a trunk road which continues with a motorway but we
> don't have a speed limit sign at the beginning of the motorway. Do
> you think we should add the speed limit value from position 1 or 2 on
> the highlighted segment? 42.4985931, -83.3042949 --> Position 1 (50
> mph) 42.4941433, -83.2950564 --> Position 2 (70 mph)

The speed limit from (1) should be used.  A change of road
classification doesn't automatically imply a change in speed limit.
 
>   1.  A lot of motorway_links don't have a speed limit sign. Do you
> have any idea where could we get the speed limit values from? Thank
> you, Horea Meleg

In general, motorway_links to a motorway are treated by everyone
(drivers, police, courts) as having speed limits equal to the speed
limit of the motorway they provide access to.  Links from a motorway
are treated as a "transition zone" where you are expected to be going
the motorway's speed limit at the start of the link, and the
destination road's speed limit at the end.  Advisory speed limit signs
are common, while signed mandatory limits are extremely rare.

-- 
Mark

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

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

[Mark Wagner]

On Sun, 13 Nov 2016 22:22:06 -0500
Russ Nelson  wrote:

> Markus Fischer writes:
>  > 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)?  
> 
> Oh, and you can always do some work in Pennsylvania. Here, let's pick
> a place at random, Thompson,
> https://www.openstreetmap.org/#map=12/41.8666/-75.5154
> 
> Look at Willow Street against Bing aerial imagery. It's badly aligned.
> Look at Main Street. Also badly aligned.
> Look at the cemetery west of Main. It's not on the map.
> Jefferson, East Jackson, Water, all badly aligned.
> Four bodies of water north of the village, all missing.
> A little creek coming in from the west and going into a mill pond.
> 
> There's LOTS to do, and you don't need to have ever gone to the
> place. You can just see it from the air. You can even see where an
> intersection has traffic lights -- the aerials are that good.

I wouldn't recommend pure armchair mapping as a starting point for
someone just getting in to OSM.  There are too many "gotchas": to take
your traffic light example, there are patterns of street lights that
look similar to traffic lights if you're just judging from the shadows
they cast.  Or looking at Thompson, you missed the fact that Starrucca
Creek proceeds to exit the millpond, flow west through Thompson, and
loop around to the north and east, to join with the Susquehanna River
about ten miles away.  Or to take an example in my area, most of the
small bodies of water are seasonal and turn into patches of
dried mud in the late summer, something you'd never figure out from
looking at Bing.

I'd recommend starting by simply verifying things in your immediate
area.  It will give you a feel for how things on the ground match up to
what you see from the air, and you'll probably find some businesses or
roads that need updating.

-- 
Mark

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Mark Wagner]

On Sun, 5 Jun 2016 13:21:07 -0700
Dion Dock  wrote:


> I think the rural residential roads are either “highway=service”,
> “highway=track” or “highway=path”.  I think “highway=residential”
> should always have a name.  Service might or might not have a name,
> same for path and track.

You must be driving on a different set of roads than me.  Consider
South Bank Road (OSM:
https://www.openstreetmap.org/#map=15/47.8602/-117.6751, Google:
https://www.google.com/maps/@47.8555045,-117.6814056,14z).  It doesn't
connect anywhere to anywhere, so it's not tertiary or above, but
"highway=service" doesn't seem appropriate for a road that provides
access to about a hundred scattered houses and two little-known parks,
and "highway=track" seems wrong for eight miles of paved two-lane
public road.

Or if that seems too built-up, how about Glenwood Road
(OSM:https://www.openstreetmap.org/#map=14/46.9380/-117.2812,
Google: https://www.google.com/maps/@46.9391634,-117.2896051,14z).
Four miles of high-quality two-lane gravel road, providing access to
some farms and a home or two.

There's a definite need for a road level between "this is how you
travel from town A to town B" and "this is how you make your final
approach to your destination".  "highway=unclassified" seems like it
works well there.

-- 
Mark

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