Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mark Wagner]

On Thu, 20 Apr 2023 20:47:34 +0100
Andy Mabbett  wrote:

> On Thu, 20 Apr 2023 at 19:50, Mateusz Konieczny via talk
>  wrote:

> > shop = unattended → shop = vacant  
> 
> "Unattended" is not "vacant"; it can mean a place where one pays in an
> "honesty box", or uses vending machines.

These were all added by a single user, who confirmed that "unattended"
meant "vacant".  I don't see it as being a controversial change.

-- 
Mark

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

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: [OSM-talk] Removing all signposts from relations

[Mark Wagner]

On Sat, 25 Jul 2020 18:14:14 +0200
pangoSE  wrote:

> Hi
> 
> Recently it was discussed whether to have signposts in route
> relations. I suggest we delete them from all relations by running a
> script. I se no loss of information doing that and a benefit to data
> consumers wanting to sort and calculate the length and height profile
> of the relation which I think should only contain unclosed ways
> belonging to the route.
> 
> What do you think?

I think that if software can't handle filtering out route members that
aren't of interest, it's defective and needs to be re-written.

(I think it's also likely to crash as soon as it encounters some of the
messes that make up real-world OSM data.)

-- 
Mark

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mark Wagner]

Almost all of the tracktype mapping around me has been done by armchair
mappers working from from aerial images.

Tracks in my area are usually produced in one of two ways:

* A bulldozer is used to scrape vegetation and topsoil off.
* A given route is driven repeatedly, eroding any vegetation or
  topsoil.

Either way, the track surface is composed of whatever's underneath the
top layer.  If I understand tracktype tagging correctly, this should be
grade 4 or 5, depending on how much gravel and/or clay is present in
the soil.  Actual tagging is almost uniformly divided between grades 2,
3, 4, and 5, with a few spots of grade 1.

Some of the more interesting inconsistencies:

* A road being "grade 2" north of an intersection and "grade 3" south
  of it, despite being the same dirt surface on both sides.
* An abandoned railroad being a mix of "grade 3" and "grade 4", despite
  the track ballast (grade 2) still being present and visible in aerial
  imagery.
* Two adjacent sections of track being tagged as "grade 2" and "grade
  4" not because of any difference in road surface, but because one has
  a line of grass between the ruts and the other doesn't.

-- 
Mark

On Sat, 18 Jul 2020 18:51:57 +0200
Florimond Berthoux  wrote:

> I see no big issue of using only aerial images to set track_type or
> surface. You can get a fairly good result with such sources.
> So no, you should not blindly revert its modifications.
> If the estimation was really bad almost all the time why not, but
> here the example given is ok.
> 
> Le sam. 18 juil. 2020 à 12:56, Michael Reichert
>  a écrit :
> 
> > Hi,
> >
> > while reviewing changes in my local area, I discovered that user
> > Modest7 has been adding tracktype=* tags to lots of highway=track
> > at various locations. I asked him what sources he used apart from
> > the satellite imagery mentioned in the imagery_used=* tag of his
> > changesets. See https://www.openstreetmap.org/changeset/87236896
> > for a discussion with him.
> >
> > I do not believe that one can add reliable tracktype=* information
> > from satellite imagery without having some ground truth knowledge
> > in order to know how to interpret the imagery in that region.
> > Adding estimated tracktype=* does not help OSM on the long term.
> > People how rely on the information (e.g. some wanting to drive or
> > cycle on that track) are disappointed about this low-quality OSM
> > data. Mappers who decide where to map assume these roads to be
> > mapped properly. IMHO, adding fixme=resurvey tracktype will not
> > improve it. Data consumers usually do not use tags like fixme=* In
> > the case of imports (another type of mass editing), we say that an
> > import must not add fixme=* to cover shortcomings of the data to be
> > imported because they usually do not get fixed in a reasonable
> > time. Therefore, I plan to revert these changes.
> >
> > Modest7 does not seem to realise that estimating tracktype from
> > satellite imagery is not doing a service to OSM. I am currently
> > preparing a revert of all additions of surface=* and tracktype=* by
> > him he uploaded since 1 January 2020 [1]. The revert will only edit
> > tags, geometry will stay unchanged. I revert changes on surface as
> > well because that's not very different to tracktype except that it
> > applies to other types of roads as well.
> >
> > The countries which will be affected are:
> > Germany
> > Denmark
> > Turkey
> > United States
> > Poland
> > Ukraine
> > Morocco
> > Czech Republic
> > Lithuania
> > Sweden
> > Norway
> > eSwatini
> >
> > A changeset discussion with him can be found at
> > https://www.openstreetmap.org/changeset/87236896
> >
> > Best regards
> >
> > Michael
> >
> >
> > [1] This date is not fixed yet.
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >  
> 
> 


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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Mark Wagner]

On Sat, 27 Jun 2020 22:01:57 +0200
"Marc M."  wrote:

> Le 26.06.20 à 14:09, Florian Lohoff a écrit :
> >> I don't care about SLA. Does OSM have SLA?  
> > The point is when you distribute your storage to people at
> > home we will have at most 10% of images online all the time.  
> 
> what facts are you basing that number on ?
> The worst internet connection I have has 98% availability.
> of course, it's not mandatory to have a pay-per-use dialup :)
> not to mention local chapters or companies with servers in datacenters
> or with fiber connection (where 2 instances of the PoC are running
> right now).
> 
> > Disregarding the case that upstream bandwidth internationally
> > is pretty bad so you tend to have access times
> > for images of about 4-5 seconds at best. (3MByte image at
> > a typical ADSL upstream with 1.5MBit/s and international latencys)  
> 
> your logic does not correspond to a distributed storage.
> it is not "one disk that sends one photo to one user"
> it is the pool that sends the pool of requests to all users.
> if you have 1000 adsl to serve 100 simultaneous requests,
> this is the equivalent of 15Mb/s par request (minus the management).
> I leave it up to you to imagine an order of magnitude for the
> conversion between simultaneous requests and users.

The only distributed data store I'm aware of with an actual
implementation is Freenet.  Freenet exhibits classic long-tail
behavior: popular data has high (>99%) availability with rapid
transfers, while the vast majority of data objects exist only as
references from other objects, and on the rare instances where they're
still in the data store, transfer times are measured in minutes.

If you treat a Bittorent index as a distributed data store, you see the
same pattern: a few popular torrents have hundreds or thousands of seeds
and download as fast as your connection can handle, while the majority
have, at best, one seeder, and many only have one or two users with
partial copies, hanging around in hopes that someone will eventually
show up with the remaining pieces.

In the context of a street-level photography system, distributed
storage means that you'll have no trouble downloading images of Old
Faithful or the Eiffel Tower, but you'll be lucky if you can get even
one photo of Road 783 in central Nebraska.

Distributed storage is one of those things that sounds good, but
nobody's figured out how to make it actually work well.

-- 
Mark

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

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: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Mark Wagner]

On Fri, 19 Jun 2020 23:45:57 +0200
Florian Lohoff  wrote:

> Hi Nick,
> 
> On Fri, Jun 19, 2020 at 11:47:01AM +, Nick Whitelegg wrote:
> > 
> > (Disclaimer: I am the developer of said project)
> > 
> > You can login using your OSM account.  
> 
> The issue is that once you start pushing stuff into any projects your
> storage expenses will kill you pretty fast.
> 
> https://www.backblaze.com/b2/cloud-storage-pricing.html
> 
> Thats 0.005$ per GB and Month. Thats *12 *1024 for a Terrabyte. Thats
> something like 60$ per Year per Terrabyte which sounds reasonable
> concerning disk costs. Costs per disk per lifetime and infrastructure
> to connect it to the IP Network.
> 
> Since late May i have produced:
> 
> flo@p4:/scratch/local/mapillary$ du -sh .
> 285G  .
> flo@p4:/scratch/local/mapillary$ find . -type f -iname "*.jpg" | wc -l
> 97407
> 
> So just pushing worth like 2 Weeks of taking street imagery will cost
> the Hoster about 20$ per year from now on. And i have pushed multiple
> terrabytes to Mapillary since 2014.
> 
> And thats just me. Put that to a global OSM perspective and you need
> serious funding for storing all that imagery, let alone the CPU cycles
> for your compute vision to blur faces and number plates.

Serious funding?  Yes.  Outrageous funding?  No.

Rough estimate:

* The CIA World Factbook says there are about 64 000 000 km of roads in
  the world.
* Google Street View takes 100 photos per km.
* A photosphere from my tablet, compressed using WebP at 50% quality
  takes 2.7 MB.

This is about 17 280 TB of storage to cover the entire world at Google
Street View quality.  It would cost $215 000 per month to store in
Amazon S3, or $89 000 per month in Backblaze B2.  It's well within the
capacity of someone like the Wikimedia Foundation.

-- 
Mark

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

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Mark Wagner]

On Sat, 13 Jun 2020 08:03:11 +0200
Florian Lohoff  wrote:

> On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote:
> > No they shouldn't, mapping roads in northern Canada, your bbox can
> > become quite large quickly as mapping logging roads/dirt roads is
> > quick and easy, but span over multiple kms  
> 
> The point is that the line/way of that road should also not span tens
> of kms. You should break that up every couple of kilometers.
> 
> Otherwise this is prone to break one day or the other. And its simply
> inefficient. Every time you touch that road you invalidate hundrets
> of tiles.

Come out to the rural United States sometime.  It's not unreasonable
for a road to span tens of kilometers between intersections.

(And a one-square-kilometer limit on landuse is also unreasonable: the
most common farm shape is a circle one mile in diameter.  The
second-most-common is a square one mile on a side.)

-- 
Mark

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

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: [OSM-talk] Strava high resolution heatmap

[Mark Wagner]

On Tue, 31 Mar 2020 12:56:32 -0400
Jmapb via talk  wrote:

> I probably wouldn't be comfortable adding paths based on Strava data
> alone even if they did have an explicitly ODBL compatible license.
> Just because there are GPS traces doesn't mean there's a path (plenty
> of popular bushwacking routes in their data) and certainly doesn't
> tell me what value to use for the highway key.

It also doesn't tell you the access tagging.  Around me, a fair number
of Strava paths are "access=private" or "access=no", sometimes in
combination with things like "barrier=razor_wire".

-- 
Mark

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

Re: [OSM-talk] Attribution guideline update

[Mark Wagner]

On Thu, 20 Feb 2020 12:25:48 +0100
Christoph Hormann  wrote:

> On Thursday 20 February 2020, Simon Poole wrote:
> >
> > Artificial "yes", but the main thing is that it is small enough to
> > ensure that it will essentially never be a substantial extract, on
> > the other hand large enough that you can cover the location of your
> > entrance, parking lot or whatever in it, with other words, large
> > enough to be useful.  
> 
> First: This has absolutely no place in an attribution guideline, in 
> particular since we already have a guideline specifically dealing
> with the subject of what is a substantial extract of OSM data.
> 
> Second: You are here essentially declaring almost all indoor mapping 
> performed within OSM (with the exception of really large structures 
> like large airports) to be insubstantial and therefore not protected
> by the ODbL and free to take and use without attribution or
> share-alike.

10,000 square meters really isn't that large.  It's the Senate wing of
the US Capitol Building.  It's the eastern third of Saint Peter's
Basilica.  It's gates 54, 55, and 56 of Tokyo Narita Airport.

Moving down to lesser-known structures, it's a dozen houses on the
outskirts of Paris.  It's a par-3 hole on a Scottish golf course.  It's
half of an Ikea store in the suburban United States.

10,000 square meters strikes me as a good rule of thumb for separating
"substantial" and "insubstantial" portions of the OSM database.  Sure,
there are exceptions, but I expect they'll mostly be in the direction
of larger extracts still being insubstantial.

-- 
Mark

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Mark Wagner]

On Sat, 8 Feb 2020 09:03:45 -0800
stevea  wrote:

> On Feb 8, 2020, at 2:58 AM, Rory McCann  wrote:
> > On 07.02.20 20:12, stevea wrote:  
> >> A well-known example is (national, other) boundaries, which
> >> frequently do not exist "on the ground,"  
> > National borders don't exist on the ground? huh? Have you ever
> > actually _crossed_ an international border? I assure you they exist
> > on the ground. From large infrastructure, to changes in the paint
> > colour on roads, one can nearly always *see* where a border is.  
> 
> I didn't say "always" (I said "frequently," though I was being
> parochial / local to me).  Between USA and Canada, for thousands (and
> thousands) of kilometers, the national border is entirely invisible.
> True, in places, it exists in an observable way (some stone markers,
> border crossings with paint-on-asphalt, even a fence or wall here or
> there), but I'd even say "mostly," the USA-Canada national border
> simply "isn't there:"  nothing on-the-ground, that is.

Have you actually been to the US-Canada border?  For thousands and
thousands of kilometers, it's really obvious:
https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg

Even when it's not as obvious as in that photo, there are still
frequent boundary cairns.  And yes, they're mapped in OSM:
https://www.openstreetmap.org/node/1997617997

-- 
Mark


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

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: [OSM-talk] no-go-areas

[Mark Wagner]

On Tue, 31 Dec 2019 16:14:30 +0100
Martin Trautmann  wrote:

> hi all,
> 
> did you read about the Suisse tourist couple which was shot because
> they got lost in a Brasilian favela?
> 
> NZZ (Neue Zürcher Zeitung) from Tuesday 31.12.2019. ("Schweizer
> Ehepaar bei Irrfahrt duch Favela in Brasilien
> angeschossen")
> 
> Other examples are e.g. Mafia areas within Kosovo - or name your own
> home town no-go area.
> 
> Is there any option to mark certain areas in order to bypass routing
> whenever possible?
> 

The problem is that most of these "no-go" areas are subjective, both in
boundary and in level of danger.  If you ask a half-dozen people, you
might get a half-dozen responses ranging from "I go there all the time"
to "The police don't patrol in less than platoon strength".

-- 
Mark

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

Re: [OSM-talk] Maintaining privacy as a casual mapper

[Mark Wagner]

On Sun, 3 Nov 2019 16:55:43 +0100
Oleksiy Muzalyev  wrote:

> You can assist from time to time in mapping the areas were there is
> one or another trouble, like a military conflict, or a natural or 
> technogenic disaster. The list can be found here: 
> https://tasks.hotosm.org/contribute?difficulty=ALL
> 
> This way it would be not easy to figure out in which place you live.

Unless you're mapping the exact same things remotely as you are
locally, this doesn't stop anything but the most naive effort to figure
out where someone lives.  If a mapper is tracing buildings in Zimbabwe
and adding restaurants in London, which is more likely: that they live
in Zimbabwe and are armchair-mapping in London, or that they live in
London, and are armchair-mapping in Zimbabwe?

-- 
Mark

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

Re: [OSM-talk] Abuse of natural=cliff tag

[Mark Wagner]

On Wed, 11 Sep 2019 20:54:17 +0200
Vladimir Vyskocil  wrote:

> > On 11 Sep 2019, at 20:20, Mark Wagner  wrote:
> > 
> > 
> > On Wed, 11 Sep 2019 15:33:05 +0200
> > Vladimir Vyskocil  wrote:
> >   
> >> A even crazier area regarding the abuse of the cliff tag ! 
> >> 
> >> https://www.openstreetmap.org/#map=15/50.9610/14.0724
> >> <https://www.openstreetmap.org/#map=15/50.9610/14.0724>  
> > 
> > Doesn't look crazy to me.  From what I saw on the map, I expected
> > there to be rock formations of the sort you'd find in south Utah.
> > Switching to aerial imagery, I saw pretty much that, just with more
> > trees.  
> 
> https://www.openstreetmap.org/edit#map=20/50.96391/14.06867
> <https://www.openstreetmap.org/edit#map=20/50.96391/14.06867> really ?

Really.  The lack of leaves-off imagery means I can't see what's under
the trees, but the shadows in some of the imagery options are not
inconsistent with the sort of stepped cliff it appears to be mapping.

-- 
Mark

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

Re: [OSM-talk] Abuse of natural=cliff tag

[Mark Wagner]

On Wed, 11 Sep 2019 15:33:05 +0200
Vladimir Vyskocil  wrote:

> A even crazier area regarding the abuse of the cliff tag ! 
> 
> https://www.openstreetmap.org/#map=15/50.9610/14.0724
> 

Doesn't look crazy to me.  From what I saw on the map, I expected there
to be rock formations of the sort you'd find in south Utah.  Switching
to aerial imagery, I saw pretty much that, just with more trees.

(Is now tempted to map Bryce Canyon in excruciating detail.)

-- 
Mark

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

Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Mark Wagner]

On Mon, 29 Jul 2019 10:53:07 -0400
Yuri Astrakhan  wrote:

> On Mon, Jul 29, 2019 at 6:19 AM Martin Koppenhoefer
>  wrote:
> 
> > speaking about risks, having an incomplete network of verified,
> > correct roads is probably more useful and less troublesome than an
> > "overcomplete" one which also contains non-existent roads (e.g.
> > waterways interpreted as roads) or shows connections that aren't
> > there in reality. 
> 
> I think this position should be a bit more nuanced.  Taken to
> absurdity, OSM map with a one percent of roads is far worse than
> having 101% of the roads mapped with the help of AI with 1% of
> extras, because fixing that 1% is far less work than adding 99% by
> hand.  I'm sure we can find a good balance between both positions.

Having hiked in areas with 1% maps, and having hiked in areas with 101%
maps, I have to say that I prefer the 1% map.  With the 1% map, there's
at least no question that you're off the map and on your own for
route-finding.  With the 101% map, it's very easy to get in trouble
because the connecting trail you were counting on doesn't exist.

-- 
Mark

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

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: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Mark Wagner]

On Fri, 14 Jun 2019 10:02:59 +0100
Dave F via talk  wrote:

> On 14/06/2019 07:57, Mateusz Konieczny wrote:
> > Edits would be split to not create overly large bounding boxes.  
> 
> As long as it's clearly commented, I wouldn't loose any sleep over
> the physical size of the changeset. OSM should be concerning itself
> with quality rather than quantity.
> 
> That the main website is antiquated & unable to display details of
> edits is not a reason to improve the database efficiently. Performing
> edits in one go makes them easier to keep track of & revert, if
> there's a problem.

It's not just the main website.  I'm not aware of any QA tool that
makes it easy to review a planet-spanning changeset.

-- 
Mark

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

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: [OSM-talk] Ground truth for non-physical objects

[Mark Wagner]

On Mon, 17 Dec 2018 14:31:14 +0200
Tomas Straupis  wrote:

> 2018-12-17, pr, 11:00 Martin Koppenhoefer rašė:
> > for admin boundaries there will often be at least 2 "true" document
> > sources: one for each party / side. They are also often observable,
> > at least punctually.  
> 
>   I wonder, of those saying that it is a peace of cake to map country
> boundaries by physically observing different things on the ground, how
> many of them have actually practically MAPPED at least a tiny bit of
> country borders (say 50km?). If so, maybe they can come forward and
> tell everybody where exactly and how exactly they did that.

The US-Canada border was already well-mapped by the time I got here,
but somehow, I doubt I'd have any trouble mapping it from aerial
imagery:
https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg

-- 
Mark

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

Re: [OSM-talk] How to get an overview of multiple gpx on OSM map?

[Mark Wagner]

On Sat, 3 Nov 2018 14:09:12 +
_ dikkeknodel  wrote:

> Hi all,
> 
> Ever since I moved to Switzerland over a year ago I’ve been both
> hiking in the mountains and updating OSM details a lot. Since I hike
> at least 20 km every weekend, it must have totaled to about 1200 km
> by now all across the country. I would love to get an overview of
> where I have been so far.
> 
> Since I’ve got a GPX file of almost every hike, the data is there. I
> am now looking for a nice graphical way to plot all of these files at
> once on a nice OSM map, OpenTopoMap as a base layer would be great.
> I’ve been searching for a while how to arrange this (without much
> programming knowledge), but I am kind of lost at the moment.
> 

If you just want to browse where you've been, JOSM
(https://josm.openstreetmap.de/) can easily handle hundreds of GPX
tracks at once, and has a variety of backgrounds you can use.  Most of
them are aerial photographs, but it also has some rendered maps.  The
topographic options for Switzerland include OpenTopoMap, OpenCycleMap,
Thunderforest Landscape, and Stamen Terrain (a pure hillshading layer,
no topo lines or anything else).

-- 
Mark

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

Re: [OSM-talk] "Travel like a KLocal" series of printed maps

[Mark Wagner]

On Tue, 9 Oct 2018 16:48:56 +0200
Frederik Ramm  wrote:

> Hi,
> 
> someone has written to DWG because they were disappointed with a
> "Travel like a Local" map they bought on Amazon. Apparently there's
> an author there named "Maxwell Fox" who churns out these "Books"
> which promise, among other things:

> ...

> Is this a new phenomenon? Has anyone seen any of these maps, or seen a
> report about them? The Amazon listing doesn't say the data comes from
> OSM, but I guess the printed work must, otherwise the complainant
> would not have written to us...

I'm surprised it took them this long to discover OSM.  People have been
churning out the Wikipedia equivalent for over a decade now.

-- 
Mark

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

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: [OSM-talk] Representing places with no housenumber

[Mark Wagner]

On Wed, 22 Aug 2018 22:58:07 +0200
Christoph Hormann  wrote:

> On Wednesday 22 August 2018, Nelson A. de Oliveira wrote:
> > > Specifying addr:street on a building that does not have an address
> > > is either pointless or non-verifiable.  
> >
> > But this happens here :-)
> > Sometimes they are big buildings/areas (which occupies a whole city
> > block, for example), with addr:street, addr:postcode but no
> > addr:housenumber  
> 
> You probably have to give a real world example since i have no idea
> if you want to say you have a building with a unique address
> consisting of addr:street and addr:postcode (could be if there is
> only one building at this street or with this postcode) or if you
> want to defend pointless or non-verifiable tagging of addr:street for
> buildings without a unique address.
> 

As a rather extreme first-world example, the address of
https://www.openstreetmap.org/way/132723167 is:

name=Grand Canyon North Rim Lodge
addr:city=North Rim
addr:state=AZ

Not only does the building not have a house number, house name, or
other house identifier, the road it's on isn't named either.  When
there's only one road in town, and that road only has one building that
receives mail, you don't need much in the way of identifiers.

-- 
Mark

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Mark Wagner]

On Fri, 10 Aug 2018 09:32:50 -0700
Vao Matua  wrote:

> Plus code can be calculated on the fly, but if they are
> to be used we will need to have hardcopy maps with the addresses that
> can be used to direct aid workers to a specific location.

Plus codes form a hierarchical grid, so supporting them on hardcopy
maps can easily be done when the maps are prepared for printing.

I don't know if you're familiar with the UGSG topo maps, but if you
aren't, I recommend looking at one of the 1:24000-scale maps from the
late 1970s/early 1980s.  It's got three location grids on it: UTM
coordinates and latitude/longitude markings on the outside, and PLSS
township/range/section markings on the map itself.  Adding a plus-code
grid to the map would be no problem, and wouldn't require importing
billions of tags into OSM.

-- 
Mark

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

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: [OSM-talk] OSM and new Wikipedia map features

[Mark Wagner]

Japanese has three *alphabets* (well, two syllabaries and a set of
logographs), but only one writing system.  For any given thing you want
to write, there's only one correct set of symbols to use.

-- 
Mark


On Fri, 4 May 2018 08:11:14 +0200
Jo  wrote:

> Japanese has 3 writing systems.
> 
> Jo
> 
> 2018-05-04 1:10 GMT+02:00 Daniel Koć :
> 
> > W dniu 04.05.2018 o 00:33, Joe Matazzoni pisze:
> >
> > Here is the list of languages Wikimedia supports. https://en.
> > wikipedia.org/wiki/Special:SiteMatrix
> > 
> >  .
> > As to the toolchain, if you ask that question on the project page,
> > some of our engineers will be able to respond.  Be sure to explain
> > why you’re asking, so we can answer you fully.
> >
> >
> > It's not exactly what interests me:
> >
> > a) do you want to support all these languages (not how many of them
> > are there)?
> >
> > b) how many server resources do you need for rendering 
> > languages that you want to support (not the software stack used)?
> >
> > Do you know it or should I ask the engineers anyway?
> >
> > That is a very interesting edge case we hadn’t thought of.  We’ll
> > have to look into that one; our lead engineer just wrote a ticket
> > to investigate: https://phabricator.wikimedia.org/T193815
> > .
> >  I know about Serbian. What other languages do this?
> >
> >
> > Belorusian has two writing systems (see http://openstreetmap.by for
> > 4 languages demo).
> >
> > Chineese has few different writing systems.
> >
> > Buginese can use Lontara or Latin script.
> >
> >
> > There might be more of such cases.
> >
> > --
> > "My method is uncertain/ It's a mess but it's working" [F. Apple]
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
> >  


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

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: [OSM-talk] Highway=trunk : harmonization between countries ?

[Mark Wagner]

On Thu, 15 Feb 2018 16:14:42 -0200
Fernando Trebien  wrote:

> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
> 
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
> 
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above

"Best" and "large/important" are both rather subjective.  Further, this
proposed system gives rather questionable results at times.

For example, the fastest route between the cities of Fargo (largest city
in North Dakota, population 120,000) and Rapid City (second-largest
city in South Dakota, population 68,000) follows I-29 and I-90, while
the shortest follows I-94 for a ways, then cuts cross-country on a mix
of minor state highways to save 70 miles while taking about five minutes
longer (on a total trip time of 470 minutes).

Which one is the "best"?  If it's the fast route, there's no issue:
both roads are already "highway=motorway".

If it's the short route, how should it be classified?  Fargo and Rapid
City are both larger than any city within 200 miles, which would
seem to make them "large/important", but even by western American
standards, they're pretty small in an absolute sense.  Trunk, primary,
or secondary?

-- 
Mark

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

Re: [OSM-talk] Roundabouts - why is a separate segment required?

[Mark Wagner]

On Wed, 14 Feb 2018 16:39:29 +
Dave F  wrote:

> I think I have read it correctly.
> 
> https://www.openstreetmap.org/node/5408566797
> 
> It is easy to determine this shared node is part of the roundabout as 
> well as the entrance from Wapping & can exit along Commercial, or if 
> required, continue around the roundabout:
> How is this different from, say, two side roads joining a main road
> at the same node?,

If I'm judging the angles correctly, OsmAnd will not even announce that
intersection: the angle between Wapping and Commercial is shallow
enough that OsmAnd sees it as a single road, while the angle between
Wapping and the roundabout is sharp enough to not require a "keep
left" instruction.

In the general case, a router only needs to consider the ways that a
route actually passes over when creating directions.  By mapping a
roundabout entrance and exit sharing a single node, you've
introduced a special case: the router now needs to check all ways
connected to that node to see if any of them is part of a roundabout.

-- 
Mark

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

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: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Mark Wagner]

On Thu, 18 Jan 2018 19:44:47 +0100
Oleksiy Muzalyev  wrote:

> Imre,
> 
> It is very good and surprising idea.
> 
> I discovered on the page "Error categories" a tool 
> https://www.keepright.at/ with the help of which I found already
> dozens obviously misspelled tags. It functions quite intuitively,
> just select "misspelled tags" check box and move the map to an area
> of interest.

But make sure they're really misspelled.  I recently saw a change that
fixed a dozen instances where the key "brand" was misspelled as "band"
-- except that one of the "band" tags was correct, describing the fact
that a radio antenna operated in the two-meter band.

-- 
Mark

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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Mark Wagner]

On Thu, 18 Jan 2018 06:14:17 +0100
Oleksiy Muzalyev  wrote:

> Good morning,
> 
> I started to experiment with the OSM data [1] on a local computer,
> and I begin to realize how big these data files are. It takes quite a
> while to load into the local database just the data for one country.
> 
> What can I as a map editor do to keep these data files to a
> reasonable size without compromising  data quality? I mean in the
> sense, - take care of the pennies and the pounds will take care of
> themselves?
> 
> I could think of the following three approaches so far:
> 
> - using as short an URL as possible, website=http://somewebsite.com 
> instead of website=http://www.somewebsite.com , three characters
> less; [2]
> 
> - correct phone number ISO format, phone=+12 345 678 90 12 instead of 
> phone=+12 (345) 678 90 12 , two characters less;  [3]
> 
> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with 
> consequent verification of its geometry;
> 
> What else, if anything, could be done?

Honestly, the best thing you can do is not worry about it.  The world
is a big, complicated place.  The three bytes you save from shortening
a URL?  You'd need to repeat it 400 times to fit one extra gas station
on the map.

As an experiment, I tried applying various data-saving
options to a park I've mapped.  I managed to reduce the size from
1240354 bytes to 1218966 bytes for a savings of 1.7% -- savings that
will vanish almost instantly this spring once I resume mapping
seasonal wetlands.

-- 
Mark

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Mark Wagner]

On Wed, 17 Jan 2018 14:51:38 +0100
Tobias Zwick  wrote:

> So, what is the optimal changeset size, and why?
> 

For a novice?  One building, or a short stretch of road, or a small
park.  They'll almost always make mistakes, and small changesets let
you suggest better ways of doing things without overwhelming them with
"Square your corners, every object needs a tag, not just a name,
don't use descriptions for unnamed things, 'motorway' means an
interstate, not 'any road you can drive on', schools should be tagged
on the school grounds, not the individual buildings, 'living street' is
almost exclusively a European construct, 'oneway=no' is redundant on
almost all road types, and locally, Bing is the lowest-quality image
option -- use this one instead."

-- 
Mark

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

Re: [OSM-talk] How to show school icons ?

[Mark Wagner]

On Sat, 25 Nov 2017 17:08:00 +0100
Martin Koppenhoefer  wrote:

> sent from a phone
> 
> > On 24. Nov 2017, at 11:00, Christoph Hormann  wrote:
> > 
> > In general there are many possible reasons why you would want to
> > map a school with a node.  Like:
> > 
> > * you don't have verifiable information on the extent of the school 
> > grounds.
> > * the school consists of a number of rooms in a building but not
> > the whole building.
> > * there are multiple schools using the same infrastructure
> > together.  
> 
> 
> yes, case 2 and 3 could alternatively also be mapped with relations
> or overlapping ways (conveying more information than a node), but if
> you don’t know the extent it is best to use a node.

When two schools share a building, it's common for the dividing line to
shift from year to year depending on the makeup of the student body.
Mapping this as two school nodes in a building is probably the best way
of doing this, as the *entrances* to the schools are usually separate,
and don't change over time.

-- 
Mark

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

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: [OSM-talk] CC0 in UK, CC0 in USA, sui generis database right and Wikidata

[Mark Wagner]

On Sun, 5 Nov 2017 11:47:22 +0100
Mateusz Konieczny  wrote:

> tl;dr 
> 
> It may be not OK to import data from Wikidata despite that this
> database is CC0 (adding wikipedia/wikidata tags is still OK, but this
> connection is mostly useless for adding data into OSM).
> 
> It may be necessary to revert some imports of data from Wikidata
> 
> 
> 
> Note: it is likely that some of what I write below is
> misunderstanding, I am not a lawyer. I would be happy to discover
> that I am wrong and that Wikidata is usable for us.
> 
> In UK and EU putting effort into compiling a database grants a
> property right called sui generis database right (very similar to
> copyright).

Not an issue.  The CC0 license explicitly calls out database rights as
being released to the greatest extent possible.  From the text of the
license (https://creativecommons.org/publicdomain/zero/1.0/legalcode)

> 1. Copyright and Related Rights include, but are not limited to, the
> following:

> vi. database rights (such as those arising under Directive 96/9/EC of
> the European Parliament and of the Council of 11 March 1996 on the
> legal protection of databases, and under any national implementation
> thereof, including any amended or successor version of such
> directive)...

> 2. Waiver. To the greatest extent permitted by, but not in
> contravention of, applicable law, Affirmer hereby overtly, fully,
> permanently, irrevocably and unconditionally waives, abandons, and
> surrenders all of Affirmer's Copyright and Related Rights...

-- 
Mark

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Mark Wagner]

On Sun, 29 Oct 2017 22:15:18 +0200
Safwat Halaby  wrote:

> - Adding closed ways with area=yes instead of building=yes, or with no
> tags at all

A closed way with "area=yes" is a *very* common newbie mistake with iD:
the user traced an area, then forgot to tag it, or didn't realize they
needed to apply additional tags.

-- 
Mark

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

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: [OSM-talk] Fixing wiki* -> brand:wiki*

[Mark Wagner]

On Wed, 27 Sep 2017 06:49:40 -0500 (CDT)
Richard Fairhurst  wrote:

> Andy Mabbett wrote:
> > in different parts of the world  
> 
> IIRC OSM stores spatial information. I might be wrong.
> 

Two examples that can't be resolved by a spatial query:

1) There is a business near me named "Maxwell House".  It is entirely
unrelated to the coffee brand of that name, despite both companies
operating in the same country.

2) Until recently, there was a burger joint in town called "Sonic's"
that was entirely unrelated to the chain of drive-in eateries.  (When
the national chain opened up a location in town, they paid the existing
restaurant to re-brand.)

-- 
Mark

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

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: [OSM-talk] Fixing OSM wikipedia redirects

[Mark Wagner]

On Mon, 25 Sep 2017 23:11:52 -0400
Yuri Astrakhan  wrote:

> At the moment, there are nearly 40,000 OSM objects whose wikipedia
> tag does not match their wikidata tag. Most of them are Wikipedia
> redirects, whose target is the right wikipedia article.

What about the ones where the article is a Wikipedia redirect, whose
target is *almost, but not quite* the right Wikipedia article?  I'm
thinking about things like neighborhoods of a city, where Wikipedia
currently has a redirect to the city article.

-- 
Mark

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

Re: [OSM-talk] HDYC, login requirement and "privacy"

[Mark Wagner]

On Fri, 5 May 2017 12:34:14 +0200
Martin Koppenhoefer  wrote:

> 2017-05-05 12:24 GMT+02:00 Frederik Ramm :
> 
> > I think that even if they are careful enough not to use their real
> > name, the identity of a mapper will often be easy to reconstruct if
> > you have access to just a little bit of extra information (might be
> > as little as a name on a doorbell).
> >  
> 
> 
> if I look at my "local area" in hdyc, there are probably a million
> people living within, but even if it were just a few thousand it
> would effectively not be possible to look at all those doorbells
> (where you won't have your name anyway if you are really concerned
> about privacy) and get a clue to which username this might be
> related. If you are living in a _very_ remote area (which most
> mappers are not), in very rare exceptional cases it might be possible
> to see who is which mapper, and that he mapped this remote area.
> Congratulations.

You're seriously underestimating how much information it's possible to
get from editing patterns.  There are a quarter-million people in the
area I keep an eye on; maybe four of them are active OSM contributors.
Just from looking at changesets, I know where two of them live: which
house for one of them, and the general neighborhood for the other.

(I also know which university a couple dozen hit-and-run editors
attend, and can make a good guess at which class they took last fall.)

-- 
Mark

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

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: [OSM-talk] Finding duplicate cycleways

[Mark Wagner]

On Mon, 24 Apr 2017 19:49:56 +0200
Martin Koppenhoefer  wrote:

> sent from a phone
> 
> > On 24. Apr 2017, at 19:27, Tobias Zwick  wrote:
> > 
> > With duplicate, I mean cycleways that are both
> > - tagged as cycleway=* on a highway=* way and
> > - mapped as a separate way parallel to the street with
> > highway=cycleway  
> 
> 
> do you suppose this is an error?
> 
> I don't know about such a tool, but you could make a postgis query:
> define a buffer around the highways with cycleway properties and look
> for cycleway ways in these areas. You won't be able to tell with 100%
> probability whether these are referring to the same cycleways though.

https://www.google.com/maps/@47.6757218,-117.3849352,3a,75y,70.4h,83.24t/data=!3m6!1e1!3m4!1sqdzvokjXjkutvCYJLOWh_A!2e0!7i13312!8i6656!5m1!1e4

That's a bicycle lane on the road, plus a distinct bicycle path running
parallel to it.  It's mapped in OSM as a "cycleway=lane" on the road and a 
"highway=cycleway" running parallel to it.

-- 
Mark

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

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: [OSM-talk] What3words

[Mark Wagner]

There are three major problems with What3Words:

1) There's no way to reduce precision.  I can say "the left front door
of the Avista central office building", but I can't say "the Avista
headquarters campus" or "downtown Spokane".

2) There's no correlation of names between adjacent locations.  The
aforementioned left front door has a totally different name from the
right front door.

3) It requires an internet connection.  If I'm out hiking and a member
of my party breaks a leg, I can't get on the radio and tell
Search & Rescue my What3Words location: my map doesn't have it (and
never will: see the precision issues), and my GPS can't display it.

In short, What3Words has solved the problem of human transmission of GPS
coordinates from one internet-connected device to another.  But they're
hyping it as if it were the ultimate solution to all your location
problems, hence the derision.

-- 
Mark

On Tue, 12 Jul 2016 11:04:59 +
Jóhannes Birgir Jensson  wrote:

> I don't know if they are using the English version in Mongolia but I 
> doubt it. You can already swap to 8 other languages on their website 
> (top right option).
> 
> I did discuss Icelandic with Mapillary and they looked into available 
> word sets and concluded that it was more than sufficient to make
> Iceland itself work in an Icelandic w3w implementation.
> 
> The circle-jerk is strong here about w3w, they have a human readable 
> solution for GPS-coordinates (which OPL isn't sadly), they've pledged
> to offer the source code if their business goes belly-up and seem to
> doing a lot of good things. I'm slightly perplexed at the extent of
> vitriol they suffer here.
> 
> --JBJ
> 
> Þann 12.07.2016 08:11, Janko Mihelić reit:
> > So they are using the english version? What good does that do to the
> > local people? It would be easier to learn the GPS coordinates.
> > 
> > Janko
> > 
> > uto, 12. srp 2016. u 09:47 Steve Doerr 
> > napisao je:
> >   
> >> On 12/07/2016 00:23, Dave F wrote:
> >>   
> >>> This system [...] doesn't work in the real world.  
> >> 
> >> It's apparently used in Mongolia as of this month. So the proof of
> >> the
> >> pudding . . .
> >> 
> >> --
> >> Steve
> >> 
> >> ---
> >> This email has been checked for viruses by Avast antivirus
> >> software. https://www.avast.com/antivirus [1]
> >> 
> >> ___
> >> talk mailing list
> >> talk@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk [2]  
> > 
> > 
> > Links:
> > --
> > [1] https://www.avast.com/antivirus
> > [2] https://lists.openstreetmap.org/listinfo/talk
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk  
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

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