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

[Mark Wagner]

On Fri, 2 Jun 2017 16:21:23 +0100
"Ed Loach"  wrote:

> Chris wrote:
> 
> > > After Ihad entered the choice as an experiment I was expecting a
> > > note to appear  
> 
> Tobias wrote:
>  
> > Really? That behavior would be horrible!  
> 
> Did these two notes get created by the application? I installed
> StreetComplete to try and reproduce the behaviour before realising
> I'd manage to add surface tags to a few local roads.
> 
> https://www.openstreetmap.org/note/1016204
> and
> https://www.openstreetmap.org/note/1016625

The first of those is a situation that StreetComplete can't resolve:
deleting an object that is no longer there requires finer-grained
editing tools than a simple "question-and-answer" format.  The second
could be handled in theory, but a business that has changed its name
may have also changed what sort of business it is, so putting up a note
is safer than simply editing the name.

In contrast, "this street has four lanes", "this building is two
stories tall", or "this business is open 24/7" are things that
StreetComplete can resolve by editing.

-- 
Mark

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

Re: [OSM-talk] Street Complete

[Mark Wagner]

On Fri, 2 Jun 2017 14:20:31 +0100
Chris Hill  wrote:

> I have just been encouraged to look at Street Complete by some odd
> notes I saw.
> 
> I installed it to find out what the app does. I was prompted at some 
> point for my OSM credentials, which I now regret.
> 
> The app shows my local area plastered with questions about the road 
> surface. In the UK residential roads are generally metalled. Are we 
> really going to add a surface tag to every UK residential road? 

> It also pointed out a few very short link connections with no name.
> That is sensible to me, why would a short (<10m ) link road have a
> name? When double confirmed that the road has no name, it added
> noname=yes to the road using my credentials, again without telling me.
> 
> These seem to be unnecessary tagging.

"Usually" is not the same as "always".  The lack of a surface tag on a
road could indicate that the road has the default surface for the area,
or it could indicate that nobody's bothered to see what sort of surface
it has.  Maybe the UK has managed to pave *all* its residential roads,
but here in the US, even major urban areas have the occasional unpaved
road; by explicitly marking even the normal case, it makes it clear
which roads have an unknown surface type.

The same thing goes for those short link roads: sometimes they take the
name of the main road, sometimes they get their own name (locally,
" Wye"), and sometimes they don't have any name at all.
Explicitly marking the lack of name makes it clear which is the case,
where a simple lack of a name could also mean "I don't know".

-- 
Mark

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

Re: [OSM-talk] Require on-the-ground verifiability of ref tag on highway

[Mark Wagner]

On Tue, 20 Jun 2017 13:23:44 -0700 (MST)
LapplandsCohan  wrote:
> 
> To be able to get routing descriptions that works for everyday use I
> motion that when the ref= tag is used on a highway, there MUST be
> signs in real life along the way that shows the same information
> (on-the-ground verifiability), otherwise the information instead must
> go into unsigned_ref, int_ref or other appropriate tag.

How do you propose to handle intermittent signage?  For example, US-2
at Birch Street in Reardan
(https://www.google.com/maps/@47.6695416,-117.8773181,18z) is
unsigned.  However, one block away, at Aspen Street, it's signed as
both "Broadway" and "US-2".  A literal interpretation of your
suggestion would have you leave the Reardan Schools parking lot and
"turn left on unnamed road".

This is a common situation in small towns in the US: the locals all know
what the highway through town is, so they don't bother signing
minor intersections.  You could drive clear through Colton
(https://www.google.com/maps/@46.5662602,-117.1226678,15.5z) and for
several miles on either side without ever learning you're on US-195.

-- 
Mark

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

Re: [OSM-talk] Decline in accuracy of capture date metadata in Bing imagery

[Mark Wagner]

On Tue, 25 Jul 2017 15:48:25 -0700
Clifford Snow  wrote:

> I'm sure if we were paying for imagery we would
> have different requirements. Bing probably wants nice looking - with
> lots of green vegetation. Our needs would be better served by leaf
> off imagery.

It depends on what we're mapping.  An image with lots of green makes it
easy to tell an abandoned field from one that's growing wheat, and the
current Eastern Washington Bing imagery is quite good for judging the
extent of seasonal wetlands and ponds.

-- 
Mark

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

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] 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: [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: [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] 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: [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] 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] 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] 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: [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] 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: [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: [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] "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: [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] 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] Software configuration | Re: iD influencing tagging

[Mark Wagner]

On Thu, 11 Apr 2019 03:17:27 -0400
Yuri Astrakhan  wrote:

> On Thu, Apr 11, 2019 at 2:10 AM Mateusz Konieczny
>  wrote:
> 
> > * easy to edit by community
> >
> > I am dubious whatever "anybody can
> > edit any preset stored as wikidata
> > items" will be considered as benefit
> >  
> 
> One could also doubt that allowing direct OSM and Wikipedia edits by
> anyone would be considered as a benefit... But it does, doesn't it?
> Worst case scenario: someone breaks a preset - with so many eyes on
> them (exposed via wiki pages, used by all editors, monitored via
> numerous tools, cross-checked by validation queries, etc etc etc), it
> will be fixed within minutes.

Wikipedia is a good comparison, but not in the way you intended it.

Wikipedia has special permissions for changing widely-used
templates or the website interface itself: the "template editor" and
"interface administrator" permissions.  An ordinary editor can only
mess up one article at a time, while a template editor can mess up a
half-million articles in a single go, and an interface administrator
can vandalize every page on Wikipedia at once.

If someone breaks the preset for something like "building=yes", then
sure, it'll be spotted and fixed in a matter of minutes.  But in the
meantime, there'll be hundreds of mis-tagged buildings, many of them in
places that nobody will review for years.

-- 
Mark

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

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: [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: [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] 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] 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] 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] 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: [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] 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] 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: [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] 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: [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] 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] 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