[OSM-ja] Housenumber plates in Japan

[Tobias Zwick]

Dear fellow mappers in Japan

I would like to adapt recording housenumbers in the Android app StreetComplete 
to the situation in Japan, if necessary.

Can you help me? 

I would like to know how a housenumber plate in Japan looks like. Does it only 
show the house number, or more? Do you have some photos?

See this GitHub issue here for more information: 
https://github.com/westnordost/StreetComplete/issues/1407

Cheers
Tobias

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

Re: [Talk-GB] Access restrictions for lorries above a certain GVM

[Tobias Zwick]

Again, the max weight is not the same as the max allowable weight. Using 
maxweight in this context is wrong.

See the Key:hgv wiki page where I added an explanation and examples.

Am 27. September 2018 11:25:11 MESZ schrieb Ed Loach :
>Tobias asked:
>
>> In United Kingdom, how do you tag roads signed with this sign?
>> 
>> https://en.wikipedia.org/wiki/File:UK_traffic_sign_622.1A.svg
>
>Based on 
>https://wiki.openstreetmap.org/wiki/Conditional_restrictions
>
>I'd go with something like
>access:hgv:conditional=no@(weight>7.5)
>with added :forward or :backward if only signed at one end of a given
>road.
>
>Ed

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

Re: [Talk-GB] Access restrictions for lorries above a certain GVM

[Tobias Zwick]

Thank you for the answers given. Perhaps there are some
misunderstandings, so I want to clarify two points:

1.
A HGV is defined as a vehicle with a max allowable mass of above 3.5t,
even in the UK. Tagging "hgv=no" when seeing this sign is plain
incorrect, except if we specifically redefine only for OSM what
constitutes a HGV contrary to what can be found in the actual
legislation. I don't think it is wise to do that.

2.
How HGV are defined (>3.5t) and what can be seen on signs like these
(7.5t) is NOT THE WEIGHT but the maximum allowed weight. This is very
important.
The maximum allowed weight, also known as the gross vehicle mass or GVM
or GVWR is the maximum permitted weight of the vehicle at full load, as
specified by the manufacturer. (See
https://en.wikipedia.org/wiki/Gross_vehicle_weight_rating)

Just to be clear, an example. Let's say there is a lorry with the
following properties on the road:
- Without any load it weighs 2 tons -> this is the unladen/empty weight
- It carries 4 tons of gravel -> this is the tara/load
- It currently weighs 6.5 tons
  -> this is the current/actual weight. Used for maxweight=*
- It could load up to 7 tons -> this is the maximum capacity
- It is permitted to weigh in total up to 9 tons
  -> this is the maximum permitted/allowed weight/mass, aka gross
 vehicle mass, aka GVM
- in other words, GVM = unladen weight + maximum capacity

Thus, using maxweight=7.5 is incorrect already because the maxweight tag
is about the maximum CURRENT weight. A HGV whose permitted maximum
weight is above 7.5 tons but which currently weighs below 7.5 tons is
not allowed on roads signed with the linked sign.

So, these are the points I wanted to clarify. Also, turns out that
someone else already noticed the exact problem and created a proposal
for this, which seems kind of abondoned, as usual:
https://wiki.openstreetmap.org/wiki/Proposed_features/gross_weight

How can we get this proposal started again? Because, the only correct
way to tag the sign initially posted here would be with

maxweightrating:hgv=7.5

(if the proposal is unchanged)

Greetings
Tobias


On 26/09/2018 13:35, Tobias Zwick wrote:
> Hey there
> 
> I can't believe this didn't come up before - or maybe it did but was not
> documented in the wiki.
> 
> In United Kingdom, how do you tag roads signed with this sign?
> 
> https://en.wikipedia.org/wiki/File:UK_traffic_sign_622.1A.svg
> 
> Note that the GVM for which the sign applies is given explicitly on the
> sign, which is apparently always the case for any HGV-access-restriction
> sign in the UK.
> 
> In other words, you will never find a sign like this in the UK:
> 
> https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C7.svg
> 
> Greetings
> Tobias
> 
> P.S: GVM is gross vehicle mass
>  https://en.wikipedia.org/wiki/Gross_vehicle_weight_rating
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


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

[Talk-GB] Access restrictions for lorries above a certain GVM

[Tobias Zwick]

Hey there

I can't believe this didn't come up before - or maybe it did but was not
documented in the wiki.

In United Kingdom, how do you tag roads signed with this sign?

https://en.wikipedia.org/wiki/File:UK_traffic_sign_622.1A.svg

Note that the GVM for which the sign applies is given explicitly on the
sign, which is apparently always the case for any HGV-access-restriction
sign in the UK.

In other words, you will never find a sign like this in the UK:

https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C7.svg

Greetings
Tobias

P.S: GVM is gross vehicle mass
 https://en.wikipedia.org/wiki/Gross_vehicle_weight_rating

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

Re: [Talk-it] Should StreetComplete stop adding addresses in Italy?

[Tobias Zwick]

Hey

Alright, so from the responses I got here, I detected a tendency to say
that the quest type should be disabled in Italy, so I will do this for
the next version of StreetComplete.
As far as I understood, the other thread (Nomi delle strade e numeri
civici) was rather about the address on POIs of amenities/shops etc.

Cheers
Tobias

On 12/07/2018 20:33, Tobias Zwick wrote:
> Hey there
> 
> Since early 2017 till now, users of my app StreetComplete have been
> adding house numbers to buildings.
> Should I disable this functionality for Italy?
> 
> For buildings of certain types, such as "apartments" or "house"s etc.
> (but not "yes"), which do neither have an address tagged, nor have any
> node on or in their outline with an address tagged, nor are in any area
> that has an address tagged, the app shows a pin on the map, like this:
> 
> https://raw.githubusercontent.com/westnordost/StreetComplete/master/fastlane/metadata/android/en/images/phoneScreenshots/screenshot8.png
> 
> This pin is shown to every user of the app, until it is solved. To solve
> it, the user taps on the pin and can input the housenumber for the
> building in the form that pops up then. The user can also answer that
> the building has no housenumber, in which case the app tags noaddress=yes.
> 
> Cheers
> Tobias
> 
> -
> 
> Addresses in Italy are described here in the wiki:
> https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia
> 
> A related discussion on talk-it is archived here:
> https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
> 


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

Re: [Talk-it] Should StreetComplete stop adding addresses in Italy?

[Tobias Zwick]

Hmm, I was hoping for a more definite answer than what I got from this
thread so far. I will give you some more input.

Regarding the ideas expressed so far:
Adding a node within the building with the housenumber is not possible,
because StreetComplete can only change the tags of an element, neither
add, delete or change the geometry of elements - but it doesn't matter
really if there is a node with an address within the building with a
fixme-tag or the address is just on the building: It requires cleanup to
conform to the Italian address guidelines in either case.
Also, a detection whether a housenumber is "nearby" specifically for
Italy is also something I will not do, because such a detection would be
too fuzzy to be reliable. But it needs to be reliable.
Finally, regarding the idea to let StreetComplete ask for the addresses
on gates and entrances instead of buildings in Italy, that would create
lots of false-positives (not every gate or entrance has an address). I
think if the building is already mapped in such a detail that the
entrances are also mapped, someone must have been there to survey it and
then he will have also specified the housenumber (if that entrance has one).

To summarize, I see no chance how StreetComplete, or for that matter,
any automatic algorithm, would be able to automatically determine where
and which housenumbers are missing on the map, when housenumbers are
mapped on plot boundaries instead of always on, in or at the entrances
of buildings.

---

Certainly, StreetComplete can be very useful in filling the white spots
regarding addresses in Italy, and it is true that as OSM is a
collaborative project, other mappers can later separate the address from
the building outline and put it on the entrance(s) to make it conform to
the guidelines. Also, most (inner-)town buildings will have their
address on the entrances and many buildings just have one entrance, so
there is no problem.
However, you also have to consider that StreetComplete will definitely
be a disruption in areas where the address is commonly (mapped) at the
gates leading to the properties (=outside the building outline). In
these areas, the buildings may be spammed with either duplicate
housenumbers or noaddress=yes tags. Worse still, if you clean up the
duplicated nodes after a StreetComplete user added them, they may appear
again later, when another user adds them again, and so on.

So, you have to weigh the these up against each other and decide.

Anyway, thank you for the praise :-)

Tobias

On 13/07/2018 10:55, mbranco wrote:
> I think that it should be fine if your app could put a node inside the
> building (at the center?) with the housenumber, and maybe with a fixme "move
> me at at the access of this building".
> Being OSM a collaborative project which works with subsequent refinements,
> someone later could set the exact position.
> 
> But I'm afraid that it's not easy to detect if the housenumber is already
> set (is already there a node "near or inside" the building with the
> housenumber?)
> 
> P.S. However, thank you Tobias for your great app, I think it's a valuable
> tool to bring newbies to OSM.
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
> 


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

[Talk-it] Should StreetComplete stop adding addresses in Italy?

[Tobias Zwick]

Hey there

Since early 2017 till now, users of my app StreetComplete have been
adding house numbers to buildings.
Should I disable this functionality for Italy?

For buildings of certain types, such as "apartments" or "house"s etc.
(but not "yes"), which do neither have an address tagged, nor have any
node on or in their outline with an address tagged, nor are in any area
that has an address tagged, the app shows a pin on the map, like this:

https://raw.githubusercontent.com/westnordost/StreetComplete/master/fastlane/metadata/android/en/images/phoneScreenshots/screenshot8.png

This pin is shown to every user of the app, until it is solved. To solve
it, the user taps on the pin and can input the housenumber for the
building in the form that pops up then. The user can also answer that
the building has no housenumber, in which case the app tags noaddress=yes.

Cheers
Tobias

-

Addresses in Italy are described here in the wiki:
https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia

A related discussion on talk-it is archived here:
https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html

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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Hey Phil

The quest pin is still in your application's cache. The app downloaded
the quest more than 8 months ago.
In any case, no need to worry. In case you solve a quest that turns out
to be outdated (=there is a conflict with actual data), it will discard
that answer and invalidate the cache of the area. You can manually
invalidate the cache in the settings.

For more information, see here:
https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#How_does_the_app_handle_uploads.3F

Cheers
Tobias

On 02/05/2018 13:58, Philip Barnes wrote:
> Tobias
> A quick question on speedlimit quests in Street Complete. I have
> attached a screenshot of an area showing some missing speed limits.
> 
> The problem is they are mapped, for example Bynner Street
> https://www.openstreetmap.org/way/48394860
> 
> Cheers Phil (trigpoint)
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Also,

6. Did you come up with the term "restricted" or is the term actually
used within the same context as single / dual carriageway in the UK
legislation? Because, that term is usually used for quite another thing
in OSM context (restricted access roads). But, as long as the nsl_*
taggings in themselves are consistent (in that they use the terms from
the UK legislation), that's fine, I guess. Otherwise, we should perhaps
look for a more fitting name before I cast it into code.

Tobias

On 01/05/2018 20:19, Jason Cunningham wrote:
> I had a bit of an interest in tagging speed limits a few years back.
> It's way more complicated than it should be in the UK. Researching led
> me down a bit of a rabbit hole of legislation & case law.
> 
> I made the following personal notes about UK limits and how to recognise
> them, which I think is mostly correct.
> https://wiki.openstreetmap.org/wiki/User:Jamicu/UK_Speed_Limits
> 
> I personally tagged restricted roads as  maxspeed:type=UK:nsl_restricted
> 
> All a bit of a mess though.
> 
> Jason
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

So then, in case the user answers in the app that there is no sign, the
app could ask the user whether the street is lit. Only if it is not lit,
it tags the street as nsl_single/nsl_dual. Would that solution be correct?

On 01/05/2018 19:22, Philip Barnes wrote:
> On Tue, 2018-05-01 at 18:42 +0200, Tobias Zwick wrote:
>> Does the "there are no repeater signs" rule only apply for the
>> default
>> 30 mph limit (and the 20 mph zones)? Or in other words, if there is
>> an
>> explicit different limit posted, let's say 40 mph, does it have to be
>> repeated at each intersection and feed roads?
>>
> It applies for 30 mph limits where there is street lighting, I have
> never come across an unlit 20 mph zone.
> 
> If there is no street lighting the National Speed Limit applies, unless
> there are repeater signs. Hence you will find 30 mph repeater signs in
> unlit 30 mph limits.
> 
> Repeaters are spaced at an regular intervals (up to about 400m), there
> is no connection with junctions.
> 
> If a NSL road is lit, then that will need repeaters (not motorways).
> 
> All 40/50mph roads need repeaters, unless the limit is very short.
> 
> An example of a 30 mph repeater.
> https://www.mapillary.com/map/im/cQ-aZU75WoEDEr72_gj4xA
> 
> Phil (trigpoint)
> 
> 
> 
> 
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Does the "there are no repeater signs" rule only apply for the default
30 mph limit (and the 20 mph zones)? Or in other words, if there is an
explicit different limit posted, let's say 40 mph, does it have to be
repeated at each intersection and feed roads?

Tobias

On 01/05/2018 16:35, Philip Barnes wrote:
> 
> 
> On 1 May 2018 10:41:28 BST, Tobias Zwick <o...@westnordost.de> wrote:
> 
>> This is where I need your help. How should the dialog be changed (in
>> GB)
>> to not create any misunderstandings here?
>>
> Difficult without having seen the speed limit signs as you have entered the 
> zone. 
> 
> My usual approach is to survey the change points, split the ways at those 
> points. Often the limit change is painted on the road so can be seen on 
> imagery. 
> 
> 20 limits are likely to exist in the centre and close to schools, so those 
> areas need survey to check. If in doubt leave the limit unmapped.
> 
> The radial roads are the usual start point for mapping speed limits, these 
> are where the transitions usually occur and are where the 40 zones are found. 
> In cities it is rare to find a direct 30 to NSL change.
> 
> If a road is has no speed limit sign it will inherit the speed limit from its 
> feed road, which if that has been mapped makes it easy.
> 
> In the case of short limits where a road passes through a small village you 
> need to be able to split the way at the zone transitions otherwise you will 
> end up tagging the entire way.
> 
> Phil (trigpoint) 
> 


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Did you read my last paragraph? Could you respond also to that?

On 01/05/2018 13:23, David Woolley wrote:
> Two or three years ago, we had problem of lots of bogus "wrong speed
> limit" notes being added by one particular app.  The general result ws
> that no-one took any notice of the notes from that app.  More recently,
> we have had problems from maps.me, although possibly not for speed limits.
> 
> I think it can be quite dangerous to give people apps that fix or note
> particular problems to people who don't know how to map using the more
> general tools.
> 
> I don't know about your tool, but it is essential that every user has an
> explicit personal account with OSM, and that they are set up to receive
> emails if people add changeset comments, or post messages to their OSM
> account.  maps.me has a high incidence of people who seem not to notice
> changeset comments.
> 
> On 01/05/18 10:41, Tobias Zwick wrote:
>> I am quite sure that this problem can lead to wrong tagging,
>> specifically that normal urban roads, even residential ones, are tagged
>> with "maxspeed:type=nsl_single" when they should not.
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

This tag is not invented, it exists in other countries where slow zones
exist as well.
Also, there *is* something special about it, otherwise the sign would
not be different from a normal maxspeed sign, wouldn't it? (And the
wikipedia article wouldn't exist)
The special thing about it, is that the posted maxspeed is valid for the
whole zone, in other words, until the maxspeed zone is explicitly posted
to be over. No repeater signs on crossroads and not even for adjacent
streets.

Yes, there is a certain similarity with the "normal" 30 mph limit in the
UK, that is why I mentioned "maxspeed:type=GB:zone30" in my original
post. Remember that OSM is a worldwide project, as long as something is
not the same in the whole world, it is not "normal".

Tobias

On 01/05/2018 11:16, Philip Barnes wrote:
> I wouldn't invent a type tag, it's maxspeed = 20 mph because that's what
> the sign says. There is nothing special about these areas.
> 
> Phil (trigpoint) 
> 
> 
> On 1 May 2018 09:58:23 BST, Tobias Zwick <o...@westnordost.de> wrote:
> 
> Regarding the 20mph zones
> (see https://en.wikipedia.org/wiki/30_km/h_zone), analogous to other
> countries where they exist, they would be tagged as 
> maxspeed:type=GB:zone20.
> 
> On 30/04/2018 20:57, Philip Barnes wrote:
> 
> Whilst in theory there is an implicit 30mph when street lights are
> present and there are no repeater signs indicating a higher
> limit then
> the speed limit is 30 mph. It has nothing to do with urban, the same
> rule will apply on lit rural roads. These days it is complicated by
> 20mph limits which also have no repeaters.
> 
> That is the theory, however in over 40 years of driving and even
> longer
> cycling I have never come across an unsigned 30mph limit. It is
> always
> signed as you enter the zone. Whilst it's useful for
> confirmation whilst
> driving, it is not really useful for mapping, you need to survey the
> start points so that it can be split at the appropriate points.
> 
> Phil (trigpoint)
> 
> 
> On 30 April 2018 18:41:26 BST, Tobias Zwick <o...@westnordost.de>
> wrote:
> 
> Hi there
> 
> On tagging implicit speed limits in the United Kingdom, the wiki
> lists
> the following values [1] for "maxspeed:type":
> 
> GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway
> (=70 mph)
> 
> I understand that the current legislation defines a road with
> road-lighting as a built-up area in which a lower implicit speed
> limit
> of 30 mph applies. There is no mention of it in the wiki, no
> GB:urban,
> GB:lit, GB:zone30 or anything like that, so something should be
> defined
> and documented by (you,) the British OSM community.
> 
> My question:
> How to tag roads in which such an implicit speed limit for built-up
> areas applies?
> 
> The question is motivated by an issue report for StreetComplete [2]
> 
> Cheers
> Tobias
> 
> [1]
> 
> https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table
> 
> [2] https://github.com/westnordost/StreetComplete/issues/1037
> 
> 
> 
> 
> 
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Okay, I have the impression that the tenor of the answers I got so far
is that a "maxspeed:type=GB:something" tagging would not be necessary
because in practice in the UK, any 30mph limit on lit streets will be
posted explicitly. Thus, the maxspeed should be specified explicitly
(along with "maxspeed:type=sign").

To those who find I summed up their opinion on that matter correctly, I
would like to confront you with an actual problem I encountered with the
surveyor-app StreetComplete of which I am the author of. I linked the
ticket to this issue in my original post.

I am quite sure that this problem can lead to wrong tagging,
specifically that normal urban roads, even residential ones, are tagged
with "maxspeed:type=nsl_single" when they should not.

So I very much want to solve this problem as soon as possible and I am
hoping you can help to find a solution to it and/or understand my point
of view that *some* "maxspeed:type" or similar tagging might be necessary.

I will now explain how this mistagging might come about in the dialogue
of the user with the app:

The app shows the street section which it is about highlighted and asks:
*"What is the speed limit sign for this street?"*
The user can then either fill in an explicit speed limit or answer
"There is no sign".

So, in case the user does not see any sign, as he would on a typical
British urban street, he answers: *"There is no sign"*

The app asks: *"Are you sure no limit is posted? Did you check at the
ends of the street? If there are no signs along the whole street which
apply for the highlighted section, default speed limits apply."*
...and in case of a road tagged as residential, it shows a slow-zone
sign and adds:
*"If there is a sign like this at the main street intersection, you
won't find individual signs within the zone because the speed limit
posted there applies to the whole zone."*

When the user answers *"Yes, no sign"*,
the app just asks (for GB): *"Are the carriageways of this road here
physically separated (i.e. through a barrier)? The default speed limit
depends on whether this is the case or not."*
The app then tags "maxspeed:type=nsl_single" or "maxspeed:type=nsl_dual"
based on the user's answer.

So, if I understand correctly, this "default 30mph limit" within lit
sections of British roads is always signed, yes, but otherwise behave
like 20mph zones in that there are no repeater signs at intersections
and *not even* in roads that branch of this main road and roads that
branch of the branched off roads (right?).
This would mean, that in Britain, it is not enough to tell the user to
look for a sign at the start of the road, but to, well, what exactly?
This is where I need your help. How should the dialog be changed (in GB)
to not create any misunderstandings here?

Tobias


On 30/04/2018 19:41, Tobias Zwick wrote:
> Hi there
> 
> On tagging implicit speed limits in the United Kingdom, the wiki lists
> the following values [1] for "maxspeed:type":
> 
> GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph)
> 
> I understand that the current legislation defines a road with
> road-lighting as a built-up area in which a lower implicit speed limit
> of 30 mph applies. There is no mention of it in the wiki, no GB:urban,
> GB:lit, GB:zone30 or anything like that, so something should be defined
> and documented by (you,) the British OSM community.
> 
> My question:
> How to tag roads in which such an implicit speed limit for built-up
> areas applies?
> 
> The question is motivated by an issue report for StreetComplete [2]
> 
> Cheers
> Tobias
> 
> [1]
> https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table
> 
> [2] https://github.com/westnordost/StreetComplete/issues/1037
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Regarding the 20mph zones
(see https://en.wikipedia.org/wiki/30_km/h_zone), analogous to other
countries where they exist, they would be tagged as maxspeed:type=GB:zone20.

On 30/04/2018 20:57, Philip Barnes wrote:
> Whilst in theory there is an implicit 30mph when street lights are
> present and there are no repeater signs indicating a higher limit then
> the speed limit is 30 mph. It has nothing to do with urban, the same
> rule will apply on lit rural roads. These days it is complicated by
> 20mph limits which also have no repeaters.
> 
> That is the theory, however in over 40 years of driving and even longer
> cycling I have never come across an unsigned 30mph limit. It is always
> signed as you enter the zone. Whilst it's useful for confirmation whilst
> driving, it is not really useful for mapping, you need to survey the
> start points so that it can be split at the appropriate points.
> 
> Phil (trigpoint)
> 
> 
> On 30 April 2018 18:41:26 BST, Tobias Zwick <o...@westnordost.de> wrote:
> 
> Hi there
> 
> On tagging implicit speed limits in the United Kingdom, the wiki lists
> the following values [1] for "maxspeed:type":
> 
> GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph)
> 
> I understand that the current legislation defines a road with
> road-lighting as a built-up area in which a lower implicit speed limit
> of 30 mph applies. There is no mention of it in the wiki, no GB:urban,
> GB:lit, GB:zone30 or anything like that, so something should be defined
> and documented by (you,) the British OSM community.
> 
> My question:
> How to tag roads in which such an implicit speed limit for built-up
> areas applies?
> 
> The question is motivated by an issue report for StreetComplete [2]
> 
> Cheers
> Tobias
> 
> [1]
> 
> https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table
> 
> [2] https://github.com/westnordost/StreetComplete/issues/1037
> 
> 
> 
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.


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

Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

I apologize for the misunderstanding, this is about implicit speed
limits when there is *no sign* that ordains another speed limit, of course.

Cheers
Tobias

On 30/04/2018 20:50, Brian Prangle wrote:
> You can't make that assumption of an implicit 30mph limit. Major roads
> in in built up areas can be 40 mph and increasingly speed limits are
> being reduced to 20mph in built up areas
> 
> Regards
> 
> Brian
> 
> On 30 April 2018 at 18:41, Tobias Zwick <o...@westnordost.de
> <mailto:o...@westnordost.de>> wrote:
> 
> Hi there
> 
> On tagging implicit speed limits in the United Kingdom, the wiki lists
> the following values [1] for "maxspeed:type":
> 
> GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph)
> 
> I understand that the current legislation defines a road with
> road-lighting as a built-up area in which a lower implicit speed limit
> of 30 mph applies. There is no mention of it in the wiki, no GB:urban,
> GB:lit, GB:zone30 or anything like that, so something should be defined
> and documented by (you,) the British OSM community.
> 
> My question:
> How to tag roads in which such an implicit speed limit for built-up
> areas applies?
> 
> The question is motivated by an issue report for StreetComplete [2]
> 
> Cheers
> Tobias
> 
> [1]
> 
> https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table
> 
> <https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table>
> 
> [2] https://github.com/westnordost/StreetComplete/issues/1037
> <https://github.com/westnordost/StreetComplete/issues/1037>
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org <mailto:Talk-GB@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-gb
> <https://lists.openstreetmap.org/listinfo/talk-gb>
> 
> 


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

[Talk-GB] Implicit speed limits: What to tag in built-up areas?

[Tobias Zwick]

Hi there

On tagging implicit speed limits in the United Kingdom, the wiki lists
the following values [1] for "maxspeed:type":

GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph)

I understand that the current legislation defines a road with
road-lighting as a built-up area in which a lower implicit speed limit
of 30 mph applies. There is no mention of it in the wiki, no GB:urban,
GB:lit, GB:zone30 or anything like that, so something should be defined
and documented by (you,) the British OSM community.

My question:
How to tag roads in which such an implicit speed limit for built-up
areas applies?

The question is motivated by an issue report for StreetComplete [2]

Cheers
Tobias

[1]
https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table

[2] https://github.com/westnordost/StreetComplete/issues/1037

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

Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Tobias Zwick]

Why do you think it necessary to map at all if any particular toilet is
segregated or not beyond whether I can go there as a man/woman? What is
the application?

On 24/04/2018 18:27, Rory McCann wrote:
> Hi all,

> Let's have a wee talk about how should one map gender neutral (and
> gender segregated) toilets. There is a unisex=yes for toilets which
> looks like it might be the number one tag to use. The bog standard
> meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
> segregated into separate male & female facilities.
> 
> Many smaller public toilets are single occupancy and hence unisex, many
> larger public toilets (e.g. in shopping centers) are segregated. Social
> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people, and they're proposing "bathroom laws"
> to limit trans people's access to public life. Some organizations are
> making their toilets "gender neutral" in response. So there are probably
> a lot of gender neutral public toilets, and it's very useful for some
> people to know where they are.
> 
> But I don't think that's how "unisex=yes" been used in OSM. The wiki
> page says "unisex=yes" is a shorthand for "male=yes female=yes". The
> JOSM validator used to suggest that replacement, until I filed a bug[2].
> iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
> it won't let you add both male=yes female=yes.
> 
> If I see "amenity=toilets unisex=yes", I would think this is a gender
> neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
> think gender segregated. Big difference.
> 
> I propose that we start viewing "unisex=yes" on toilets as meaning
> "gender neutral toilet", which is different from "male=yes female=yes",
> which is "gender segregated".
> 
> Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
> by many projects? What do they interpret it as? It's good not to force
> things.
> 
> A year ago Micah Cochran's suggestion[3] would be along these lines, but
> some changed to toilets:for:unisex=yes (etc.)
> 
> Rory
> 
> P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
> which for the quarter is gendered toilets. Plenty of toilets have no
> male/female (and/or unisex) tag, and we should add those tags.
> 
> [1] https://en.wikipedia.org/wiki/Unisex_public_toilet
> [2] https://josm.openstreetmap.de/ticket/15536
> [3]
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> 
> [4] https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2
> 
> ___
> 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] "The Future of Free and Open-Source Maps" Slashdot.org , Saturday February 17, 2018

[Tobias Zwick]

I also read this article and I found it identifies some areas in which
(the central infrastructure of) OpenStreetMap could improve.

What I do not like about this article is the deeply pessimistic and
resigned tone of it, like clickbait. It reads like "OSM needs to change
from the core up or else it will be doomed!".

Yeah, I don't think so.

And I do not think that this mode of appeal is that productive. It's
good if it sparks discussions about what we can and want to improve, but
I do not think that it is going to inspire anyone to "save" OSM by
innovating things. This is not how it works in FOSS, and not how
innovation works. AI detections of features from pictures/drone videos
for example is not going to happen because someone writes that we
_really_ need this now to keep up, but because someone is enthused about
the concept (and is able to capture others with that).
Also, Serge maybe doesn't know
https://blog.mapillary.com/update/2015/01/27/traffic-signs.html

That there might be a conflict of interest regarding pulling more
technology and services into the core OSM toolset is an interesting
thought that did not cross my mind before and that may very well be
true. Though on the other hand, I consider the fact that OSM runs on a
"shoestring budget" as something that contributes to OSM's
sustainability: I.e. I observe with concern that Wikimedia apparently
requires more and more money every year to survive.
OSM's minimalistic organizational structure is simply a different
concept than WP.

Regarding the "area" type, I agree that it would be a good improvement
to introduce a more fixed notion of areas in OSM data. To introduce
another data type has quite the ramifications on backward compatibility
but there may be other options. Right now, every single piece of
software needs to maintain an area detection based on tags like this:
https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/data/meta/OsmAreas.java#L13-L28
Naturally, it is different, thus inconsistent, for any piece of software
- and needs to be updated for any tagging scheme that comes up.

If I were to name the biggest challenge for us, it would be the
maintainability of the map data, a topic that he never mentions directly.

Tobias

On 17.2.2018 10:56 AM, Oleksiy Muzalyev wrote:
> This article is on the front page of the Slashdot today:
> 
> Fri 16 February 2018 "Why OpenStreetMap is in Serious Trouble"
> 
> https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/
> 
> 
> "The Future of Free and Open-Source Maps"
> 
> https://news.slashdot.org/story/18/02/16/2216228/the-future-of-free-and-open-source-maps
> 
> 
> 
> I actually read the article, and though it has got insightful
> information and interesting ideas, I have doubts about some suggestions.
> 
> For instance, reviews. I hope it will not come to what there is at some
> commercial maps, when one adds say a building and then has to wait for a
> month that an almighty moderator approves it, so that it appears on the
> map.
> 
> I also skeptical of massive imports from governments' databases. These
> databases were created in the last century, with outdated tools,
> sometimes by disinterested underpaid clerks, probably in a climate of
> secrecy of that era. And such an import may replace the quality data
> from modern satellite imagery, GPS traces, surveys, etc.
> 
> Best regards,
> 
> O.
> 
> 
> ___
> 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] How to teach novices about optimal changeset size?

[Tobias Zwick]

This is how StreetComplete does it. Good thing is that the OSM server
automatically closes changesets where nothing was added after one hour,
so one does not need to worry that a changeset gets "stuck" if the user
exits the application without closing the changeset.

On 17/01/2018 18:47, Rory McCann wrote:
> On 17/01/18 15:13, Michał Brzozowski wrote:
>> Certainly not:
>> - one changeset per building, repeated 20 times
> 
> Couldn't this be done with the "upload" vs "new changeset" feature of
> the OSM API? A technical solution. Multiple uploads in a single changeset?
> 
> Users want to save/upload frequently (because computers), so we'll never
> stop them pressing the button often. Maybe iD could keep a changeset
> open and an upload rather than open a new changeset? There would have to
> be an option to "close current changeset and open a new one" (& close
> current changeset), and to word that in a more friendly way for people
> who don't know the terminology.
> 
> I don't think linking to documentation will solve this issue. Too many
> users don't read things like that, no matter how much we'd want them to.
> 
> Yes, I know I'm suggesting a software change without offering a patch.
> 
> 
> ___
> 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] How to teach novices about optimal changeset size?

[Tobias Zwick]

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

Tobias

On 17/01/2018 14:26, Michał Brzozowski wrote:
> Many new users have a habit of e.g. sending one or few objects per
> changeset, resulting in a dozen or even more changesets per day.
> Obviously this makes them PITA to review quickly in Achavi or whatever
> tool you use.
> 
> This habit is probably caused by non-knowledge of how auto-save works in
> iD (which makes the work reasonably secure), as well as just not knowing
> better thus forming their own judgement.
> 
> How should we teach about optimal changeset size? This is quite tricky -
> how we would define it?
> 
> Can the iD nudge users towards better practice? (Linking to Good
> changeset comments wiki page would be useful as well)
> 
> Michał
> 
> 
> ___
> 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] Tool for tag tracking

[Tobias Zwick]

Wow, Roland, this is awesome!

So, this seems to make any deliberations of introducing a
survey_date:something tag or similar obsolete, because in the future,
one will be able to search with overpass through the history on a
per-tag basis.

This will make it possible for QA and hm... data-actuality-maintenance
tools (made up this term, this category of tools doesn't exist yet I
guess) to find data that haven't been changed for a long time and should
be re-checked some time.
I am thinking of finding automatically certain data points (tags) that
haven't changed in the database for X months and should be re-surveyed.
Will that be possible also (checking for "last change on tag older
than...")?

This feature makes it possible to greatly improve the maintainability of
data in openstreetmap.
For example the smoothness of streets and cycleways in particular is
something that should be revisited every few years, same as the street
surface especially in developing countries. Also, the presence of
cycleways on streets might be something that should be re-checked every
decade or so at least. Etc etc

Great work!

Cheers
Tobias

On 12/01/2018 06:31, Roland Olbricht wrote:
> Hi,
> 
> for the sake of completeness, I would like to give a preview what is in
> the development for Overpass API:
> 
> Similar to this one
> 
>> https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass
>>
> 
> you could nowadays search with https://overpass-turbo.eu/s/uF0
> for all highways that have changed since the beginning of the year in
> and around Antwerp:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> out geom;
> 
> I suggest the "out geom" mode over recursing to the nodes. Overpass
> Turbo can handle both, but the "out geom" means that there is exactly
> one item per object in question. No unchanged nodes get involved.
> 
> The above result is bloated by objects like
> https://www.openstreetmap.org/way/469659128/history
> It has no change to its highway value but just lost the unrelated tag
> "horse=no".
> 
> Here comes a feature in the staging area for the next version into play.
> We do not ask for all changes but just for changes that affect the tag
> "highway": https://overpass-turbo.eu/s/uF2
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:t[highway]);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> The line "compare(delta:t[highway]);" reads as: keep only objects that
> have changed in the value "t[highway]". The last line is a directive to
> execute the query on the development server.
> 
> We could even drill down further and retrieve only objects that have
> been created or deleted: https://overpass-turbo.eu/s/uF4
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> This is admittedly hacky and the final implementation might have a more
> straightforward term. The condition for "compare" always evaluates to
> the empty string for non-existing objects. And for existing objects to
> "0" as we just have specified, hence it can tell apart existing from
> non-existing objects.
> 
> Can we separate the deleted from the created objects? Yes,
> https://overpass-turbo.eu/s/uF7 delivers only created objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   way._(newer:"2018-01-01T00:00:01Z");
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> And https://overpass-turbo.eu/s/uFa delivers only deleted objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> Please note that these are not yet in a published release because there
> may come up a reason to change the syntax. If that happens, I will write
> a mail here again. For example, it might be more concise to do these
> tasks with a three argument "changed" condition. But I have not
> evaluated yet whether this leads to a logically sound syntax.
> 
> Best regards,
> Roland
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

[OSM-talk] Mapzen is shutting down

[Tobias Zwick]

Hey guys

Some of you already read it on weekly, Mapzen is shutting down. This is
very sad news for the new year, as they were working on many promising
open-source services around OpenStreetMap.
I don't have the best overview, but their main product was the vector
map, so amongst the most important projects were

+ tangram and tangram ES (GL vector maps for web, embedded, mobile etc)
  https://github.com/tangrams

+ vector-datasource (Vector tile service)
  https://github.com/tilezen

+ Valhalla (routing engine)
  https://github.com/valhalla

+ Pelias (geocoder)
  https://github.com/pelias/pelias/

(did I forget anything?)

With the company being in dissolution and the developers forced to find
other jobs, all the work done in the last few years might be for the
birds if these repositories will no longer maintained.

I read we do not have to worry about the Valhalla team and project, they
found a new home at MapBox.

Also, I read today that the maintainers of Pelias announced this week,
that they will not shut it down. Full statement here:
https://github.com/pelias/pelias/tree/master/announcements/2018-01-02-pelias-update

But the future of Mapzen's main product, both the vector tile server and
tangram is what I am worried for. With Mapzen's tile services shutting
down along with everything else, the demos [1] will not work anymore and
people who want to use tangram will need to set up an own tileserver for
that, which is something the fewest would do with the easy alternative,
MapBox (and others? Or are there no more other competitors?).

Perhaps some people from the team/company are on this list and can share
their view on how or if these projects can continue and maybe how we as
a community could help.

Greetings
Tobias

P.S: Not sure if I should post this also on the dev mailinglist?

[1] http://tangrams.github.io/tangram/

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

Re: [Talk-cz] Adding housenumbers with StreetComplete

[Tobias Zwick]

Hi Martin

Understood, thanks for the link. I will post on the SK mailing list as
well then. :-)

Cheers
Tobias

On 13/11/2017 08:51, Martin Ždila wrote:
> Hi Tobias,
> 
> On Sun, Nov 12, 2017 at 10:28 PM, Tobias Zwick <o...@westnordost.de
> <mailto:o...@westnordost.de>> wrote:
> 
> Regarding Slovakia, so would you say it is the same situation in regards
> to that an individual survey is not helpful for housenumbers?
> 
> 
> In Slovakia we have so far imported housenumbers of many places but also
> many are still missing.
> 
> We have a wiki page related to this
> at http://wiki.freemap.sk/SupisneCislaKapor.
> 
> Recently a new source of addresses has opened for us so we are planning
> to do another big import. You can read it
> ad https://groups.google.com/forum/#!topic/osm_sk/nV3b2l7ZSnI
> <https://groups.google.com/forum/#!topic/osm_sk/nV3b2l7ZSnI> (also in
> Slovak language).
> 
> For more details please ask on osm...@googlegroups.com
> <mailto:osm...@googlegroups.com> because I am directly not working on it.
> 
> Best regards
> --
> Martin Ždila <http://www.openstreetmap.org/user/*Martin*>
> OZ Freemap Slovakia
> tel:+421-908-363-848
> mailto:martin.zd...@freemap.sk <mailto:martin.zd...@freemap.sk>
> http://www.freemap.sk/
> 
> 
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> 


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

Re: [Talk-cz] Adding housenumbers with StreetComplete

[Tobias Zwick]

Hi Marián

Not sure if I understand you correctly, just to be in the clear:

So, you have a source from which you irregularly update the addresses
from. That source is also kept up-to-date and that is why it makes
little sense for surveyors (be it via StreetComplete or using field
papers and JOSM/etc) to add housenumber data and/or is even disruptive.

Correct?

Regarding Slovakia, so would you say it is the same situation in regards
to that an individual survey is not helpful for housenumbers?

Cheers
Tobias

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

[Talk-cz] Adding housenumbers with StreetComplete

[Tobias Zwick]

Hi, I am the author of StreetComplete, an Android app with with which
surveyors can add data to the map directly. More Info here:
https://github.com/westnordost/StreetComplete

Amongst other things, the app incites its users to add housenumbers to
buildings. I have read that in your country, most (all?) housenumbers
are imported from an official source. But it is not clear to me whether
this happens regularly, if this means that housenumbers should not be
added from OSM users etc.

On the wiki documentation
https://wiki.openstreetmap.org/wiki/Addresses#Country_specific_rules_and_sources
, it is only documented that a housenumber (possibly?) has more than
just a housenumber, but also a conscription number etc.

So that is why I would like to ask you whether adding any housenumbers
on building outlines) should be disabled for your country in the app.
Ideally, the linked wiki should be updated to reflect the decision made.

To help you decide on this, here are some facts about what the app does:

When are users prompted to enter a housenumber?
---

1. Exclusively for buildings tagged as house, residential, apartments,
   detached, terrace, hotel, dormitory, houseboat, school, civic,
   college, university, public, hospital, kindergarten, train_station,
   retail, commercial. Notably not for building=yes

2. Only for buildings which do not contain (or contain on outline) any
   node that is tagged with a housenumber or -name

3. Only for buildings that are not contained in a larger area that
   already has a housenumber or -name (such as schools, hospitals,
   campuses etc)

What tags do the users enter?
-

Users can enter either a addr:housenumber or a addr:housename.
Alternatively, they can leave an OSM note in which they can explain the
situation and optionally attach a photo.
No tags are replaced by this app, the users can only add data. They can
neither delete previously entered housenumbers nor merge housenumbers
from nodes onto a building outline and as said above, are also not
prompted to supply a housenumber for buildings that already contain a
housenumber node.

By the way, if there are certain , i.e. that the housenumber is not
sufficient because there are other numbers as well on the housenumber
sign (conscriptionnumber, streetnumber, provisionalnumber), then, the
form to input the housenumber could be adapted for within the Czech
Republic to also ask for the conscription number (etc?).
But first I need to know if adding housenumbers via this app in your
country is something that makes sense at all.

-

You might want to follow the forum thread in the Norway and Netherlands
forum where I asked the same question:
Norway - https://forum.openstreetmap.org/viewtopic.php?pid=671651
Netherlands - https://forum.openstreetmap.org/viewtopic.php?pid=671650
I also asked the same question on the Denmark mailing list.

(All of the above countries do regular imports of housenumbers from an
official source).

Cheers
Tobias

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

Re: [Talk-dk] Adding housenumbers with StreetComplete

[Tobias Zwick]

> But this also means that the functionality of leaving an OSM note for
> missing and wrong addresses would be very helpful in Denmark.

To clarify:

The app asks for the housenumber of a building and prompts the user to
input it. This housenumber and only the housenumber is then directly
added to the OSM database, no note is created for that. (And similarly
with inputing housenames)

Only if the user clicks on "Unable to answer", so in case the user
surveyed the place and could not find a housenumber (or something like
that), the user is given the choice to instead leave a note and explain
the situation. The notes generally look like this then:

  Unable to answer "What is the housenumber of this building?" for
  https://www.openstreetmap.org/way/[element id] via StreetComplete 3.0:

  [user message]

So then, so far, it looks like I shall disable the functionality for
Denmark.

Tobias

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

[Talk-dk] Adding housenumbers with StreetComplete

[Tobias Zwick]

Hi, I am the author of StreetComplete, an Android app with with which
surveyors can add data to the map directly. More Info here:
https://github.com/westnordost/StreetComplete

Amongst other things, the app incites its users to add housenumbers to
buildings. I have read that in your country, most (all?) housenumbers
are imported from an official source, regularly.

On the wiki documentation
https://wiki.openstreetmap.org/wiki/Addresses#Country_specific_rules_and_sources
, it is not stated clearly whether this is discouraged. So that is why I
would like to ask you whether adding any housenumbers (on building
outlines) should be disabled for your country in the app. Ideally, the
linked wiki should be updated to reflect the decision made.

To help you decide on this, here are some facts about what the app does:

When are users prompted to enter a housenumber?
---

1. Exclusively for buildings tagged as house, residential, apartments,
   detached, terrace, hotel, dormitory, houseboat, school, civic,
   college, university, public, hospital, kindergarten, train_station,
   retail, commercial. Notably not for building=yes

2. Only for buildings which do not contain (or contain on outline) any
   node that is tagged with a housenumber or -name

3. Only for buildings that are not contained in a larger area that
   already has a housenumber or -name (such as schools, hospitals,
   campuses etc)

What tags do the users enter?
-

Users can enter either a addr:housenumber or a addr:housename.
Alternatively, they can leave an OSM note in which they can explain the
situation and optionally attach a photo.
No tags are replaced by this app, the users can only add data. They can
neither delete previously entered housenumbers nor merge housenumbers
from nodes onto a building outline and as said above, are also not
prompted to supply a housenumber for buildings that already contain a
housenumber node.

-

You might want to follow the forum thread in the Norway and Netherlands
forum where I asked the same question:
Norway - https://forum.openstreetmap.org/viewtopic.php?pid=671651
Netherlands - https://forum.openstreetmap.org/viewtopic.php?pid=671650

Cheers
Tobias

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

> compromise between the two, how about I disable the "embed edit".  If
> the query is executed from a link, without the query editor mode, users
> can only view results.  But in the power mode, the users can still use
> the tool to write a query they need, test and edit things as they need. 
>  So its ok to use it as a power editor (e.g. JOSM or Level0), but not as
> mass contribution.

I like this idea, that also goes into the right direction.
Something like this is what I had in mind when I said the tool should
not lend itself for a purpose it is intended for (mass re-taggings
without prior discussion and consensus).
> In the mean time, I will add the "two person approval required", which
> should alleviate expressed concern.  Should be ready fairly soon.

+1
A reject feature plus a two-person approval feature sounds like a
solution with which noone should have a problem with the tool thereafter.

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

I get your point, especially regarding the appliance of the JOSM
fix-button as a "by-the-way" fixing.

Though, you can't fix possible issues with of one tool by introducing
another tool. People will not stop using (that feature of) JOSM. That is
why I think, if you think you detected a problematic issue there in that
editor, it should be discussed in a separate topic.

On 17/10/2017 00:57, Yuri Astrakhan wrote:
> Michael, I can only judge by my own experience adding validation autofix
> rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
> they were reviewed by one or two JOSM developers and merged, probably
> because they were deemed benign.  I don't know about the other rules,
> but I suspect many of them also went this route.  Should have they been
> discussed more widely? I don't know, but that question is complicated,
> just like "what is a local community?" question. What a few devs may see
> as benign, others may say needs a discussion, right?
> 
> Mass editing is a different matter.  We consider mass editing when one
> person goes out to fix something everywhere in the world.  But when we
> provide a tool that automatically fixes something that you are looking
> at, we don't view it as such.  Or at least we don't view it when it
> happens as part of JOSM, but we do when it happens in my new tool. Of
> course there is an important difference - JOSM doesn't guide you towards
> those cases.
> 
> I think massive "by-the-way" fixing is far worse than the targeted fix
> of a single issue.
> 
> When you want to fix a single issue in many places, you become a subject
> matter expert.  You know all about that change, how it interacts with
> other tags, what to watch out for, how to handle bad values, etc.  For
> example, when fixing wikipedia tags, you would see the types of mistakes
> people make, wrong prefixes people use, incorrect url encodings, hash
> tags in urls, incorrect multiple values, ... .    When you simply click
> "fix" because JOSM validator tells you it can fix it automatically, you
> don't have that knowledge, so it effectively becomes a distributed
> mechanical edit without the "reject" capability.  My tool tries to
> address this - to build domain experts in a narrow field, and let those
> experts review changes one by one. I do not discount the value of local
> knowledge, but it is not a panacea - you must be both to make
> intelligent choices, and in some cases, the domain knowledge is more
> important than the knowledge of a specific locale.
> 
> On Mon, Oct 16, 2017 at 4:00 PM, Michael Reichert
> > wrote:
> 
> Hi Yuri,
> 
> Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan:
> > Rory, most of those queries were copied from the current JOSM validator
> > autofixes.  I don't think they were discussed, but they might have been
> > mass applied without much thought by all sorts of editors.
> 
> Could you please give examples for (a) the mass appliance of these rules
> and (b) rules which have not been discussed but should have been
> discussed?
> > There are two ways to use the tool - you can write your own query, run 
> it,
> > and fix whatever it is you want to fix. That's the power user mode -
> > anything goes, no different from JOSM or Level0. And there is another 
> one -
> > where you go to osm wiki, read the instructions, find the task you may 
> want
> > to work on, and go at it.   The community reviews wiki content, tags
> > different pages with different explanation or warning boxes, etc. The
> > discussion could still be on the forum, or here, or in IRC, 
> 
> Just for future readers: IRC and Telegram channels are no replacement
> for a mailing list or a forum with a public readable archive where you
> can look up the discussions years later.
> 
> Best regards
> 
> Michael
> 
> 
> 
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
> 
> 
> ___
> 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] New OSM Quick-Fix service

[Tobias Zwick]

>> Anyway, generally, with everyone raising the alarm about this tool, it
>> would be a friendly gesture to either take the tool offline for now or
>> set it to read-only mode
> 
> Or have it run on the dev API.

Does the dev API have real (=mirrored) data?

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

Number 2.

>> [...] This was a topic in this thread already and it was
>> voiced that inventing new tags just to be used by this tool in not
>> acceptable and I agree with that. The other tools also do not
>> require that.
>
> [...] Not showing it can also be easily done by a slight
> modification of the query itself.  This is assuming my reasoning for
> on-OSM tag storage makes sense for other tools. In the mean time, I do
> plan to make a separate reject storage system just to cover all cases.

An on-OSM tag storage? Inventing new tags for (single) tools is
specifically what I mentioned has been strongly opposed!

I see you mention having some OSM tag further below in your message and
you give some arguments why this might be a good idea beyond the ease of
implementation.
I'd say, of course whether such a tag or namespace of tags could make
sense is something that can be discussed. But not after the fact and not
on pressure. Your tool being live, and no way marking something as
false-positive, this does set a discussion about this in exactly in a
bad atmosphere.
Anyway, generally, with everyone raising the alarm about this tool, it
would be a friendly gesture to either take the tool offline for now or
set it to read-only mode (no save button) so that everyone can calm down
and the critical points about it can been addressed and solutions be
found, in an objective non-pressured manner. Since this is a general
consideration that concerns other tools as well then, it should be done
in a separate topic.

Anyway. I am surprised to read that you see the tool actually also in
case #1, as a manually operated automatic edit. It could be that I, and
probably many people here in this topic majorly misunderstood your
intention with this tool.
Let me summarize your arguments why this makes sense over a fully
automated edit:

1. barrier too high for writing a completely automatic bot
  a) automatic edits are too risky, fear of programming errors
  b) too thorough review is required for fully automatic edits, fear of
 uncovered edge cases
  c) a mistake of a bot edit can only be spotted after the fact and a
 (partial) revert of such a bot edit is complex

2. your tool lowers that barrier by creating some kind of staging / test
   area for bot edits by having different users manually confirm or
   reject the proposed fix for any such element
  a) it's relatively easy to add an automatic edit to the tool and that
 same query can be used to run directly on the server for full
 automation
  b) issues with the query can be fixed by anyone (wiki)

---

I can follow your line of argumentation and your vision. There is quite
the discrepancy between this and the concerns mentioned so far in this
topic, which see your tool from a different perspective (which I will
iterate further below).

The concerns are, that the tool will not actually be used to
stage/analyze the impact of an automatic edit that is to be applied
after consensus and thorough testing but to go forward with organized
re-tagging without that (or at least give other users the tool to do
that). If this is not your intention, then the tool must be changed in a
way that it does not lend itself for that purpose.

Furthermore, the argument that a mistake in a completely automatic bot
is complex to revert, seems bogus. If the edit happens in *one* edit, it
is on the contrary, very easy to revert. If, on the other hand, dozens
or even hundreds of people worked on a quick-fix task which needs to be
reverted, again on the contrary, this is much harder to revert because
there are different users, different changesets and over a varying
timespan involved. (Also, I hope the tool at least writes into the
changeset which quick-fix exactly was used, to link quick-fix with
changesets)

> [...] this will be up to the communities to enforce - if
> someone writes a query [that requires actually going there to check],
> others should be quick to point this out.

Better, document that. Here, look for example at the guidelines for new
"quick-fixes" (aka quests) I wrote for my OSM tool:
https://github.com/westnordost/StreetComplete/wiki/Adding-new-Quests-to-StreetComplete

Leaving this kind of supervision to "the community" means that you
generate thankless work for people that constantly "should be quick to"
sound the alarm for quick-fixes that are not correct in one way or the
other (which are immediately live).

Not sure if this came across to you yet, but it has been said a couple
of times in this thread already and it should be repeated in light of
the answer you gave above:

When you say, it is up to the community to point out problems with any
such query that has already been created and is being worked on, then
you basically reverse the whole guidelines for bot-editing - the
community learns about it after the fact, instead of before it is
happening. This is exactly the situation we do not want to have.
This is the fundamental issue with the tool and something 

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

I will split this into several answers, that is what a threaded
structure is for.

> JOSM fix button

I am not sure what is your point with JOSM's fix button. Let's not
deviate from the topic: your tool.
If you find, something is wrong with JOSM or any other tool in that
matter, better create an own topic for that. In any case, it is not a
good argument to justify deficiencies of one tool with deficiencies
another tool might (or might not) have. Not saying that this is your
intention here, what I understood is that you want to say that the idea
for your tool mainly comes from wanting to improve on the idea behind
that feature in JOSM. Ok.

> it won't save unless you zoom in to 16+ (just like iD editor).
> Plus I added Mapbox satellite imagery to help.

You mean, the save button is disabled, right?

> MapRoulette and SPARQL

Well, if you are not interested in getting involved in MapRoulette to
add your idea there, that's your choice. I am elaborating below just to
get this clear, in case you misunderstood:

I did not mention SPARQL. I was talking solely about the idea of
quick-fixes, not to transplant your current code into MapRoulette.
Naturally, the implementation in MapRoulette would not include SPARQL
queries but i.e.

1. the creator of a challenge simply supplies the "quick fix" answer
   option(s) in a multiline textfield after he supplied the Overpass
   query, i.e. like this:
   sport=soccer
   sport=american_football
   sport=canadian_football
   sport=australian_football
   sport=gaelic_football

2. MapRoulette shows the answer option(s) (as dropdown) next to the
   other buttons for each element in the challenge.

3. MapRoulette uploads the selected quickfix through OSM API

I was also bringing this up, because I was quite shocked to see how much
code is necessary in SPARQL just to convert

  religion=Christian into religion=christian
  (http://tinyurl.com/yame4thf )

I am already lost there with this query. I'd say, as a user, it is
*really* easy to make a mistake there.

>> Though, note, for all three cases, a prior consensus is required,
>> either by prior discussion or by looking at what was previously
>> agreed on in the wiki. That is the case for *any* organized
>> re-tagging of existing tags.
>
> Sure thing. There are very very few cases when the fix is super
> obvious, e.g. a typing fix, but lets not dwell there.

In regards to what I said above, I reckon you can do a lot more stuff
with SPARQL than simple tag replacement. Fair enough, that I'd find such
an extension of MapRoulette more useful is just my personal opinion.

Tobias

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

> Except that's not true. In Ireland "handball" is Gaelic Handball¹
> which is a one-on-one game, not a team sport (which is apparently a
> different thing²). There are some sport=handball's tagged in Ireland.
> Now the tag is clearly wrong, and we need to figure out something about
> that. But if you just change sport=handball to sport=team_handball, then
> you've entered incorrect data, based on incorrect assumptions.

Good catch. So, it is no good as an example for that. But no matter, I
think the idea got across anyhow.

> Big question: What defines "community consensus"?

I can't really answer that. I'd define it as "Topic has been brought up
to the public and there are no justified and irrefuted objections."

> Not everyone (incl me) thinks that the wiki defines what a tag should
> mean...

Sure, the wiki is to be taken with a pinch of salt (I think I do not
need to elaborate why), but it is the only documentation we have.
Everyone, (new) users, data consumers and app developers simply will
always consult the wiki.
Because the wiki has such a central importance, the (unwritten?
written?) rule is that parts that explain what has to be mapped how
should only be done to document the status quo (if it is explicitly
stated as such) or better after finding such a consensus.

Tobias

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

Hi Yuri

I am not aware of the record of your previous interactions with the
community and I think you cannot be blamed to not respond to any toxic
feedback and/or accusations thrown at you here, whether they may be
justified or not.

So, I give you the benefit of the doubt and write up this honest and
constructive feedback. Substantively, I come to the same conclusions as
the previous posters: That I find it hard to see that the app will have
any positive impact - at least "as is". I hope you value it nonetheless,
I also have some suggestions at the end.

So, the initial question is: What is the conceptual use case for such a
tool? Where would be its place in the range of available OSM tools?

There is the use case where one tagging scheme has been deprecated by
community consensus and one (combination of) tag(s) should be changed
into another (combination of) tag(s) globally.

1. If this does not require humans because both tagging schemes are
mutually translatable (i.e. lets say for sport=handball <->
sport=team_handball), then, the edit can be made automatically by a bot.

2. If this does require humans to check the transition to the new tag
because the deprecated tagging scheme is ambiguous (i.e. , such as
sport=football -> soccer or american/australian/canadian/... football),
then, an automatic edit cannot be done. Instead, tools like MapRoulette
are used.

3. Finally, if this also does require humans because a tag combination
is suspicious (what would show up as warnings in JOSM and what most of
Osmose consists of), also, a tool like Osmose or MapRoulette is used.

Though, note, for all three cases, a prior consensus is required, either
by prior discussion or by looking at what was previously agreed on in
the wiki. That is the case for *any* organized re-tagging of existing tags.

I reckon you see the quick fix tool to be in category 2 and 3 here,
along with MapRoulette and Osmose, only with the crucial advantage of
being quicker to use, since no editor is required.
But it seems to me, you didn't think this through. If the tool offers
*one* solution to any re-tagging ("Save" or leave it), then, this is
pretty much a manually operated automatic bot (case 1), which really
doesn't make sense. For case 2 and 3, it cannot be used as is, because:

- Quick fix cannot be used to find what kind of football it is (case 2),
but MapRoulette can, because it leaves the actual editing to the user.

- Quick fix cannot be used to solve any markers which may or may not be
an actual problem (case 3) because it has no way of marking any of the
things as false-positives.

Looking at your linked Wiki document (
https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
candidates for automatic corrections. I.e.:
- Convert religion=Christian to religion=christian
- Convert various common forms of religion=catholic to
religion=christian + denomination=catholic
- Convert religion=islam to religion=muslim
- etc.

(Only) your initial example ( amenity=sanatorium -> leisure=resort +
resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
mentioned, either marking as false-positives or other answer options
(i.e. "yes, it is a sanatorium in the West European sense") are missing.

Okay, so much for why I think the tool is, as is, not fit to be used and
probably why you got so many negative responses here.

*However*, the idea as such, to make the clean-up process of either
clearly wrong tags, deprecated tags or even just warnings
semi-automatic, is a very good one. The prerequisite is, that there must
always be the option to *not* apply that fix and save that decision. The
other very critical point is, that the easier you make it for users to
apply a predefined fix, the more precautions must be taken to ensure
that the user really checked the situation.

So, the most critical missing features from my point of view in your
tool are

a) There must be an option to manually edit this instead and/or marking
it as a false positive. In any case, the marker may not be shown for
other users anymore. This was a topic in this thread already and it was
voiced that inventing new tags just to be used by this tool in not
acceptable and I agree with that. The other tools also do not require that.

b) I strongly suggest to offer different answer options. As I said, if
only one option is available, it is really nothing else than a manually
operated automatic edit. If several options are available (i.e.
"american football", "soccer" etc. ) as a quick fix, only then the tool
becomes to be useful. (There are some challenges like that on
MapRoulette also, such as "Phone or fax number is not in international
format" and these in my opinion also do not belong there because they
can be solved automatically)

c) Require users to zoom into the map at around zoom 17 or more to make
any changes. If the users are supposed to check if something is the case
(via satellite image), then at least don't let them cheat by just
solving 

Re: [OSM-talk] Finding duplicate cycleways

[Tobias Zwick]

Hey Roland

The reason I asked about whether there is a tool that finds (possibly
wrong) duplicate mapped cycleways because a very similar algorithm could
be used to determine whether any one street is actually *missing*
cycleway tagging or whether the cycleway is in fact already tagged but
as a separate way.
In other words, I need all those roads that neither have a cycleway=*
tag (easy) nor have a cycleway-way next to them (the hard part). I
wonder, is this possible to achieve with an Overpass query?

I was told here
https://github.com/westnordost/StreetComplete/issues/139#issuecomment-297518195
by an Osmose-backend contributor that they implemented this already, but
of course, Osmose does direct postgis queries, so more is possible with
this.
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_cycleway_track.py

I am developing an app with which one should be able to map cycleways
basically by simply answering the question "Is there a cycleway here?"
and of course, the app needs to find out, where it may ask and where it
shouldn't.

Greetings
Tobias

On 28.4.2017 6:36 AM, Roland Olbricht wrote:
>> http://overpass-turbo.eu/s/oEm
> 
> Thank you for the link.
> 
>> Unfortunately it does not (yet)catch also the segregated and
>> not-segregated foot-cycle-paths that are tagged using the JOSM presets
>> (highway=path, foot=designated, bicycle=designated, segregated=yes|no)
> 
> http://overpass-turbo.eu/s/oG6
> 
> I have essentially just added the conditions you mention in one line. I
> have slightly changed the viewport to have relevant results for the
> change within the viewport.
> 
>> I am not an Overpass-Turbo expert and don't dare to add them to your
>> script
> 
> The linked queries are immutable. If you open the link then you always
> work on an independend copy.
> 
> Cheers,
> 
> Roland
> 
> 
> ___
> 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

[Tobias Zwick]

> 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.

Okay, I mean of course duplicate cycleways where the duplicate mapping
is an error. Correct usages like you present can be filtered out by
looking a the value of the cycleway tag: If there is a separate way and
the cycleway-tag on the road is a track, then it is probably an error.

> do you suppose this is an error?

I would say so, as long as there are not in reality two cycleways (see
above). Wouldn't you?

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

[OSM-talk] Finding duplicate cycleways

[Tobias Zwick]

Hi

I wonder, does anyone know a QA tool out there that finds duplicate
cycleways?

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

I understand that there is no simple tag on the highway=* way to denote
that the cycleway is mapped as its own way, so whether a cycleway is
mapped or not cannot be determined just by looking at the tags of a road
but must be determined by analyzing the geometry of ways in relation to
each other (I guess).

Greetings
Tobias

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

Re: [OSM-talk] Beware Pokemon users

[Tobias Zwick]

To have a gamified way to contribute to OSM was my original idea for
StreetComplete[1]. There should be leaderboards, badges/achievements
and different stats, also different quest givers/categories each with
own pictures (like i.e. on WikiMapia), a possibility to form teams and
compete with each other for "dominance" (=contributing most) in cities.

So the game itself would (still) be to directly contribute to OSM itself
but I think this is a good enough basis for a gamey app.

For StreetComplete, it currently develops more into the direction of a
surveyor app, but only because I want to get the basics working first,
so everything is no-frills.

Tobias

[1] see https://github.com/westnordost/StreetComplete

On 30.12.2016 9:43 PM, moltonel wrote:
> 
> 
> On 30 December 2016 18:50:17 GMT+00:00, Paul Johnson  
> wrote:
>> What's the elevator pitch for Kort?
> 
> http://wiki.openstreetmap.org/wiki/Kort_Game
> 
> It's a gamified way to edit osm, which is good  but unlikely to attract 
> non-OSMers. I'd like something that is more geared towards gamers but still 
> directly usefull for mappers.
> 


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

Re: [OSM-talk] Key:Destination Abbreviations

[Tobias Zwick]

Hey Edwin

I read through the discussion on that page.

I think you focus too much on this 20:1 statistic. I too think this does
not really belong on the main page, but this is not really the issue.

I do not have the impression that anyone is using the 20:1 statistic as
an argument whether the destination name should be abbreviated or not.
The argument is that abbreviations in names being expanded for the DB is
the standard _in general_ and that the destination-value is just another
name(-like) tag.
Which I can totally follow. After all, where is the difference between a
sign on a freeway saying "Argument Ave" for the next exit and an actual
street sign at an intersection saying "Argument Ave"?

Why should this one sign not be abbreviated (street name) but that other
sign (freeway exit name) should?

As Carciofo said on the discussion page, I don't see the use case why
this consensus on names should be overturned for a specific tag.
You mentioned so that the actual sign could be displayed by the
navigation software. Well, it still can, the software just needs to know
how to abbreviate words, which is easy to do. The other way round,
automatically expanding an abbreviation (i.e. reading aloud) may be
ambiguous.

This is an old argument, it has been brought up years ago when talked
about whether to abbreviate names or not in general. That the same
argument applies to Key:destination again is a clear sign that
Kay:destination is in fact just another name tag.

Cheers
Tobias Zwick

On 18.12.2016 10:40 PM, Edwin Smith wrote:
> Hi all,
> There is a disagreement that could use a few more eyes.  Destination has
> the explicit purpose of telling a
> navigation program the wording of a sign.  It is typically used as a tag
> of a Motorway Link.  It is not visible
> in the Mapnik in any way.
> 
> One side of the disagreement argues that if an abbreviation appears on
> the sign (Ave for instance)
> it should be expanded to Avenue in the Destination Tag.  The arguments are:
> 1) OpenStreetMap discourages abbreviations
> 2) If you search through Destinations every time Avenue appears it is a
> mapper vote for expanding Ave to
> Avenue.
> 
> The other side of the disagreement (which I support) argues to present
> the sign to the navigation program
> exactly as it appears, neither abbreviating or expanding abbreviations. 
> The arguments are:
> 1) Destination is for the use of the navigation program.  If
> abbreviations are changed it has no way to
> know if the sign says Ave or Avenue.  If they are unchanged it can make
> its own decision as to what use
> of abbreviations is best for its users.
> 2) It is just wrong to count every Avenue as a mapper vote for expanding
> Ave because it very often is
> just the mapper's correct reporting that the sign has Avenue spelled out.
> 
> Check it out in the Key:destination Discussion.  As you will guess, the
> EDSS comments are mine.
> 
> Cheers,
> Edwin Smith
> 
> 
> ___
> 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] Mozambique's living streets

[Tobias Zwick]

> from minor ones... Some bright spark took initiative by tagging a large
> part of Dakar's residential streets as highway=service - that has been
> universally perceived as a very bad idea.
Well, there is this line in the wiki for highway=service and service=alley:

"In some medieval European settlements alleys may be the very narrow
streets which run in-between buildings, providing public through-access.
" ( http://wiki.openstreetmap.org/wiki/Tag:service%3Dalley )

These kinds of streets are not only common in old town centers in Europe
but can be found in any place in the world that hadn't been built with
cars in mind, in shanty towns and also in modern (non-shanty) towns -
especially in Asia.

Now, the alley tag mentioned is problematic because there is no clear
definition what may still count as an alley and what should be a
residential road already.

Actually I raised the same issue 3 years ago in the forum
https://forum.openstreetmap.org/viewtopic.php?id=21942 (with links to
example imagery).
The outcome, more or less was:
* do not use living_street for non-living-streets
* use path/footway for anything that does not fit a car anymore (i.e.
only a motorcycle/rickshaw)
* use highway=service + service=alley for residential alleys that barely
fit a car if convenient
* otherwise residential for everything else, use width/lanes to give a
hint how wide it is

(Not saying that I am absolutely content about it, it is still ambiguous)

The existence of these discussions about how to tag really small
residential roads popping up and the living_street tagging being popular
where there is no such (legal) thing as a living street again and again
is a sign that there is an unalleviated uncertainty and thus room for
conflict and disagreement about this, since it is not clearly defined.

Now, talking about this is good. But can we solve and clear this up here
in the interest of all mappers and correct the ambiguities in the wiki
definition once and for all?

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

[OSM-talk] StreetComplete Betatest (osmagent)

[Tobias Zwick]

Hey people

I created a first early version of StreetComplete (renamed from
osmagent), the Android App for surveyors I recently mailed about. If
anyone is interested to test it in the field, I would be happy for any
more feedback.
Don't expect too much, I first needed to get the basics working.

I created a forum thread for this again to not generate too much noise
here on this mailing list, as I am hoping to get much feedback (and bug
reports) :-)
https://forum.openstreetmap.org/viewtopic.php?pid=620441

The APK is here:
http://www.westnordost.de/streetcomplete/streetcomplete-0.1-unsigned.apk

Github is here (for bug reports etc):
https://github.com/westnordost/StreetComplete

Cheers
Tobias

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

[OSM-talk] Android survey app: osmagent

[Tobias Zwick]

her than
that the map may look cool, it also means that it
would be possible to directly display the answer
the user gave on the map (i.e. the building height)

State of development
---
See here: https://github.com/westnordost/osmagent

Of the quests, currently implemented are only "road name", "shop opening
hours" and "contribute to note" as proof-of-concepts, I am still working
on the base system. Adding more quests will be an easy
exercise.
What's missing on the base system is the logic when the system should
download quests and upload the changes the user made. Also, since the
app is making direct changes to the DB in the name of the user, I want
to write more tests before I make it available.
But that's it, pretty much, what is missing for a first release.

In the forum thread, I linked a few screenshots so that you can get an
impression of the app:
https://forum.openstreetmap.org/viewtopic.php?pid=616369#p616369

Cheers
  Tobias Zwick (westnordost)

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