[Tagging] animated OSM

[André Pirard]

Re-posted with smaller size.

Hi,

There was a time when OSM was used only as a background picture, like a 
Bayeux tapestry.

Times have changed.
The following pictures come from the latest tracking page of Bpost.
The blue marker is the destination of the watched parcel.
The red marker is the post vehicle.
It wobbles up the yellow road from the post-office below.
Unfortunately, I didn't at first notice it was moving.
Then a Haie des Chênes stop.




Then the pharmacy.



Then a cluster of houses across the road



But whoops it suddenly jumped to destination, no more pictures.
As I understand it, it only moves when the postman uses his keyboard.
But I was waiting behind my door to surprise the postman :-)

NB: I don't know why the images are cropped.
They do indeed contain ©Openstreetmap contributors.

Well done, Bpost !!!

All the best,

André.





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

Re: [Tagging] Literal translation of street names + defaults

[André Pirard]

  
  
On 19/09/22 12:36, Janko Mihelić wrote:


  
  
A user in my city (Zagreb) started translating street names
  into English, and I don't know what to do about it. An example
  of translation is Butcher Street for Mesnička ulica, or Stone
  Street for Kamenita ulica. I found a few of these in Berlin,
  for example, Straße
der Erinnerung translated Road of Remembrance.
  These are valid translations, but it isn't helpful for a map.
  If an english user of our map saw "Road of Remembrance", she
  won't be able to find that street sign, or explain to a taxi
  driver where she wants to go.



I think I've seen someone talk against such translations,
  but I can't find a wiki page that talks about it. I can create
  one if there is consensus that this is wrong tagging. Or maybe
  just add a few sentences about it on the name=* wiki page.



The problem is, he is doing valid work, so it feels wrong
  to just delete it. Another way to deal with this is to create
  a new tag, name:literal_translation:en=* or just
  literal_translation:en=*.


Another question, what is the right name:en=* in these
  cases, or is there none? Erinnerung Road?


Thanks!
Janko Mihelić

  

Hi, thanks for writing.
What you mean in the Subject is semantic translation, according to
meaning.
Literal, which is according to sounds, Bruxelles vs Brussels is
valid.
Those literal
  translations are many.
And I find them useful for people using other scripts like Cyrillic,
Arab, Greek, etc
And sometimes funny too (1).
The specialists of multi-language are Belgian people, I To: them.
Legally, Brussels
is French-Flemish bilingual.
So, not only are the street names written in both language on the
plates,
but also the question's would be raised which is the OSM primary
name.
Look there, they have written both names in name=*
and default_language=fr - nl.
Also, there are other communities where the default language,
although legally set, is disputed and OSM comes there as a trouble
maker.
I let the specialists talk if there is more to say.

(1) In my browser, I specified as accepted languages  en fr ... ru
...
When Nominatim finds in a French speaking place name=frnam
name:ru=runam
it will write it runam to me because it found no suitable name:fr=
default_language=fr should be used to imply name:fr=frnam in this
case.
Proposed
  features/Defaults should be
used to set default_language in one place and in all places
administratively below it. This is more important than many things
discussed here.
But that proposition should be reworked and voted. Many
contributors' comments I used to read about it did not understand
its goal or found it unaesthetic which is not its purpose, etc.
If it was voted, for example the default speed limit could be set
differently in Wallonia and Flanders with two tags instead of
specifying each Flanders road's limit and forgetting some.

All the best,



  

  André.

  


  


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

Re: [Tagging] power lines/cables power

[André Pirard]

  
  
On 15/11/2020 19.17, François Lacombe
  wrote:


  
  
  
Le dim. 15 nov. 2020 à 16:45,
  André Pirard <a.pirard.pa...@gmail.com> a
  écrit :


   Hi,

A group of friends were discussing the first electricity
power link between Germany and Belgium.
And I was kinda proud to show them this
where the only line
  across the border clearly shows.
Well done, guys (and gals?)!

  

  Way 578137663
  Tags 7
  
cables=1
circuits=1
frequency=0
location=underground
name=Alegro Interconnector
power=cable
voltage=32
  

  

Their concern was interstate power transfers and a maximum
of 7,5 GW was mentioned (more than the 6 GW Belgian
deprecated nuclear capacity, effectively running at 4,5 GW).
So then I was surprised that a power cable or line does not
indicate that power.
I looked trough the wiki and all I found as power was an
unsuitable generator:rating:...
So, as power:power=* seems weird, I added power:maximum=7.5
  GW, allowing for power:mean=* or he like.
As I don't want to get into propositions, I let specialists
discuss that.
Let me know if and how I should change that tag.

Envoyé de mon immobile Thunderbird, et sans virus
non plus grâce à seulement Ubuntu, 

All the best, 


  

  André.

  


  

On 15/11/2020 19.17, François Lacombe
  wrote:



  Hi André,
  
  
  That's an interesting question.
  Power transformers can have rating=* to state how many
power they can transmit.
  I see no problem to add it to a power relation like the
one involving the line you mention
  https://www.openstreetmap.org/relation/8193755#map=11/50.7528/6.0606
  
  
  Can you explain the difference between your value (7.5
GW) and the value already visible on the relation (1 GW)
please?
  
  
  Difference between rating on a power=line/cable and
rating on a power relation is a follow:
  - On a line/cable, it's the maximum capacity the
line/cable is designed for
  - On a relation, it's the rating the whole link is
operating at
  
  
  
  Power circuits relations :
  https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal
  
  
  All the best
  
  
  François
  


   

  


Haille François,

Merci pour ta réponse.
So, I was told that 7,5 GW rating by an ALEGrO engineer but I didn't
see it on OSM. He didn't mention 1 GW.
So I looked all over the wiki.
Passing an accepted proposal that should say that it is overridden
by another one, typical wiki, I saw no mention of power rating
except for generators. And that cable has dead ends.
And in the proposal you show, I see no mention of power rating
either, esp. in the relation.

A typical OSM browser needs to be an expert already to know how to
look at tags and do so.
Let alone guessing that what he does not find could be in a
relation.
Furthermore, I don't see at all how a relation could indicate the
operational power ratings of branches.

All in all, I continue to believe that a cable or line should
indicate their power ratings.
Let's be nice to the map users who were refused
  a F1=Help by Tom Hughes.
So, so, so, I have made the cable nice tags:

power:maximum=7.5 GW
power:used=1 GW

Quite self-describing and friendly.
Please discuss this matter and warn me of any change.

All the best,

Cordialement,



  

  André.

  


  


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

[Tagging] power lines/cables power

[André Pirard]

Hi,

A group of friends were discussing the first electricity power link 
between Germany and Belgium.
And I was kinda proud to show them this 
 
where the only line across the border 
 clearly shows.

Well done, guys (and gals?)!



Way 578137663 


  Tags 7

  * cables=1
  * circuits=1
  * frequency=0
  * location=underground
  * name=Alegro Interconnector
  * power=cable
  * voltage=32

Their concern was interstate power transfers and a maximum of 7,5 GW was 
mentioned (more than the 6 GW Belgian deprecated nuclear capacity, 
effectively running at 4,5 GW).
So then I was surprised that a power cable or line does not indicate 
that power.
I looked trough the wiki and all I found as power was an unsuitable 
generator:rating:...
So, as power:power=* seems weird, I added /power:maximum=7.5 GW/, 
allowing for power:mean=* or he like.

As I don't want to get into propositions, I let specialists discuss that.
Let me know if and how I should change that tag.

Envoyé de mon immobile Thunderbird, et *sans virus* non plus grâce à 
seulement Ubuntu,


All the best,

André.


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

Re: [Tagging] What language is the name tag value? Was: Which languages are admissible for name:xx tags?

[André Pirard]

  
  
On 27/03/2020 00.51, Martin
  Koppenhoefer wrote:


  

sent from a phone


  
On 26. Mar 2020, at 23:54, Tod Fitch  wrote:

2. Create a scheme where a default language can be set on boundaries as has been suggested by Joseph Eisenberg [4]. This has the advantage that relatively few objects need to be tagged, for example it might be possible that only one tag could be used to cover the continental United States. But it falls apart for features that are on the boundary between multiple language areas (Mediterranean Sea for example)

  
  

these could/should be outside of the default language areas as there isn’t a default language. There are also voices to omit name tags without language code in these “international” areas.




  
and for areas that are multilingual (Wales for example).

  
  


you could state that several languages are the default (even give hints about how they are formatted, provided there are multiple names in one standard name tag, something like ”de / it” (or including language and script)), or you’d have overlapping areas for languages (and maybe scripts)



  
In addition, it seems that any type of “we should add a default for an administrative area” proposal that has come up here has been rejected or “bike shedded” into oblivion.

  
  

the language areas must not necessarily be administrative areas (although it would clearly simplify adding and maintaining them), for example there could be a single (multi)-polygon for France and part of Belgium.

As it was said several times, Belgium already has language areas as
this French
  Community boundary 
 that has been chosen to be political because there is nothing more
suitable.
Also, there is a Proposed
  features/Defaults and if we clutch the two together we have
default languages.
However, this Defaults proposal has been left stranded because
almost no one see its importance, because it's highly misunderstood
and because it should be better explained.
Important because it would stop OSM data to be outside of the OSM
database.
Example: Flanders (north of Belgium) changed their speed limit from
Belgium's 90 to 70 km/h. With a working Defaults this would have
been a one number or so change of the OSM data. Without one, it
would have been changing the local data of many routers, GPSes and
such. Conclusion, Flanders now tags very road speed explicitly and
don't use defaults any more.

All the best,



  

  André.

  










  

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



  


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

Re: [Tagging] How owing to FlightRadar24 to follow the Tour de France on a less straight route

[André Pirard]

On 12/07/2019 18.55, André Pirard wrote:


Comment avec FlightRadar24 suivre les avions plutôt que les vélos du 
Tour de France. 
<https://www.flightradar24.com/blog/how-the-tour-de-france-goes-from-cycle-to-screen/?utm_campaign=website_source=sendgrid.com_medium=email>


How owing to FlightRadar24 <https://www.flightradar24.com/> to follow 
the Tour de France on a route 
<https://www.flightradar24.com/blog/how-the-tour-de-france-goes-from-cycle-to-screen/?utm_campaign=website_source=sendgrid.com_medium=email> 
less straight than that of the bikes and than OSM's.
You may right click the video and select "iframe in a new tab" for a 
larger view.


You should probably be able to use Flightradar24 
<https://www.flightradar24.com/> and see the planes live if you manage 
to point it where they are 
<https://www.velowire.com/article/1043/fr/le-parcours-du-tour-de-france-2018-sur-google-maps-google-earth--itineraires-horaires-et-profils-des-etapes.html>.


Please forward this to other lists.

This will be my last message about this.
On this 2019-07-15 at around 17:00, I turned FlightRadar24.com 
<https://www.flightradar24.com/44.56,3.51/8> on to show the route of the 
10th stage of the Tour de France: Saint-Flour -> Albi 
<https://www.letour.fr/fr/etape-10>.
I clicked a few planes along the route until I pinned one that FR24 
labels with a made-up name BE20. It circled in rounds all along he 
track, probably to relay TV signals. You will probably be able to watch 
it during the next stages. (⚠ Tuesday 16 is resting day). Unfortunately, 
albeit F24 archives the history of most flights for replay, it does not 
archive this plane, like e.g. most gliders.
Then I waited until BE20 went nanight in Castres Mazamet Airport 
<https://www.flightradar24.com/airport/dcm> to take this picture.

Beware that the pasted over data is that when the plane was above Albi.
In Castres it was less high and going down. And it had a more decided 
speed ;-)


I thought that this could add loving to watch planes to your loving to 
map the land under.
For example, replay the history of this service plane 
<https://www.flightradar24.com/data/aircraft/oo-let/> and wonder why it 
goes to those places all over the world to fly in circles. Similar trips 
for this helicopter 
<https://www.flightradar24.com/data/aircraft/f-gkmb#21364fc1> that I 
found in Albi, Lyon, Brussels near the Tour de France.




All the best,
Cordialement,
Amitiés,

*ㄿ* 
*㈖* *る*
*ェ* *ゝ*







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

[Tagging] How owing to FlightRadar24 to follow the Tour de France on a less straight route

[André Pirard]

  
  

Comment
  avec FlightRadar24 suivre les avions plutôt que les vélos du Tour
  de France.

How owing to FlightRadar24 to follow
  the Tour de France on a route less straight than that of the
bikes and than OSM's.
You may right click the video and select "iframe in a new tab" for a
larger view.

You should probably be able to use Flightradar24 and see
the planes live if
  you manage to point it where they are.

Please forward this to other lists.

All the best,



  

  André.

  


  


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

Re: [Tagging] Variable position

[André Pirard]

On 24/12/2017 02.21, Matej Lieskovský wrote:

Hello,

is there a way to map objects, whose position changes slightly?
In fact, the position of all objects changes slightly over time and a 
coordinate should be a vector indicating a position and a (presently 
best value of) direction and speed of drift.
The Greenwich meridian is presently 102m west away of the zero latitude 
of a GPS and it continues to drift.
See Greenwich Meridian   
which is now 0.0014864° W by its nodes (which should have the same value 
BTW).


All the best,

André.



Example:
I know a park that has a few dozen benches. They are there practically 
all-year-round, but their position changes every now and then. A fixme 
would imply that the problem can be fixed (which does not seem 
practical), leaving them out completely is less than ideal and leaving 
them as nodes gives a false sense of precision, which is not perfect 
either. Is there a way of saying "there are benches somewhere around 
here"?


Merry X-mas,

Matej



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

Re: [Tagging] Waterway length

[André Pirard]

On 2019-02-16 23:00, Markus wrote:
On Sat, 16 Feb 2019, 20:06 Eugene Podshivalov  wrote:


What is the best way to correct this, so that all other langauge
pages got the correction as well?


I'm not aware of any other way than correcting it on each page. I've 
just done this and also added a note that this tag lacks verifiability.




In June 2013, the notes help page was saying
Leave a short message on the map if something is missing or obviously 
wrong, like "oneway in wrong direction"...
I made a correction in English, French and Russian and asked the 
linguists to translate it to other languages.

I suggested _thinking twice_ to the persons who write notes as follows:
Leave a short message on the map if something is missing or obviously 
wrong, like "oneway goes northbound" or "bridge or level_crossing?". 
These reports can be processed by map editors. Add the message 
understandably and thoughtfully, e.g. not "oneway in wrong direction" 
because someone could have flipped the direction before the note is read.
I see that, English people are requested to stop _thinking twice_ 
because, as it often happens to what one does for OSM, that advice has 
been removed from the English version, that French and Russian people 
must continue to think twice because the text remained and that German 
people and probably others were always requested to continue making 
errors because the text never changed:
Gib einen kurzen Hinweis auf der Karte, wenn etwas fehlt oder falsch 
ist, z.B. ein "*Einbahn in der falschen Richtung*" ...

Removal happened to other corrections I made, that's the way OSM goes.
I hope I have answered your question, Eugene.

All the best,

André.


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

Re: [Tagging] Waterway length

[André Pirard]

On 2019-02-17 12:55, Eugene Podshivalov wrote:
вс, 17 февр. 2019 г. в 00:11, André Pirard <mailto:a.pirard.pa...@gmail.com>>:


It's easy to make a script to total up all the segments of a
waterway or any way.


It will work but only if the entire river from its spring to mouth is 
drawn precisely enough, all relation roles are labeled properly and 
nobody breaks the labeling by intent or mistake some day.
The more side streams a river has the greater probabily is to break it 
one day.
Here is an example of such complex river which name means "a river of 
a hundred waterways"

https://www.openstreetmap.org/relation/5561722#map=13/51.4077/25.2271

Cheers,
Eugene

The method I describe has the advantage that the length written in an 
OSM relation would be the only, or almost, number that shows exactly 
what it measures instead of other measures said better than others for 
no explained precise reason. The relation makes a consensus of what the 
river is, the number is right, and anyone having another conception of 
the river can explain it and compute the length difference the same way 
as the relation does.
Imprecision is to be corrected, just as I'm spending much time using 
JOSM to improve to a 20 cm precision errors of 3 to 5 m or more made 
with other editors.
I saved as a GPX file the relations that I found for rivers Le Rhône 
<https://www.openstreetmap.org/relation/1075117>, La Meuse 
<https://www.openstreetmap.org/relation/1075197> and Байкал road 
<https://www.openstreetmap.org/relation/318461> (going to Иркытск where 
a guy tried to sell me confiscated material such as cranes, lorries and 
railway wagons).
Anyone can use JOSM to make routes and save them as *.osm and *.gpx 
files without modifying OSM.


I tried to upload them to RouteYou <https://www.routeyou.com/>, but it 
would limit the length.
I uploaded them to GPSies 
<https://www.gpsies.com/#10_50.6167_5.75_mapnik> but the lengths are 
bogus, apparently multiplied by a strange factor.


GPSies
real
×
GPSies name (by PapoudeOSM)
12,275.62 	614 	18 	OpenStreetMap La Meuse 
<https://www.gpsies.com/map.do?fileId=qmstzmvbysegiyua> (FR+BE)

15,052.41   812 20
	OpenStreetMap Rhône 
<https://www.gpsies.com/map.do?fileId=udauuravtkrjjxhp>

33,926.12   1 113   30
	OpenStreetMap Байкал road 
<https://www.gpsies.com/map.do?fileId=ieubgcbhgjcgbxia>



(Turn off waypoint display)

Anyway, that's the idea.

All the best,

André.


вс, 17 февр. 2019 г. в 01:18, Sergio Manzi <mailto:s...@smz.it>>:


Sorry for the typo: of course Wikip_*a*_dia was meant to be
Wikip_*e*_dia!

On 2019-02-16 23:15, Sergio Manzi wrote:

Then why don't you submit a paper to the CNFG (http://www.cnfg.fr/) and 
correct the Wikipadia articles?

Sergio


On 2019-02-16 23:07, marc marc wrote:

Le 16.02.19 à 22:32, Sergio Manzi a écrit :

A static value for a river length in OSM, without any information about
its source

every tag you add into osm have a changeset with a source tag, isn't it?
so adding the lenght should/must also have a source (extrapolation (sum
of all way of a relation) of osm data is a source)

a few month ago, I have checked the length of Rhône [1]
the french wikipedia list 2 sources for the lenght... both are very fair
away of the lenght found after some work on osm data.
which one to choose? osm without hesitation. maybe it is not fair but at
least it is verifiable (everyone can load the relationship, see the
result and correct errors if necessary) while the other 2 sources
(including the official French source) are totally unverifiable.

unfortunately I did not send in osm the result of the cleaning because
it concerned partly errors in osm (mainly roles in the relationship)
but I started by purging everything that didn't interest me in the
relationship before fixing. it will have to be done again

[1]https://en.wikipedia.org/wiki/Rh%C3%B4ne
___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging



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


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

Re: [Tagging] Waterway length

[André Pirard]

On Sat, 16 Feb 2019, 15:26 Andy Mabbett  wrote:


   I would suggest that values entered by human mappers are more likely
   to be "error prone"; and that we should be more concerned with
   on-the-ground reality than "offical" figures.


It's easy to make a script to total up all the segments of a waterway or 
any way.
It would be already done if the routers added "by boat" to my suggested 
"by plane" ("as the crow flies").
I suggested that real routes can be made of multiple segments of those 
various kinds.

Like a car travel followed by a hike including a canoe trip.
Like the Tour de France (some parts by plane).
But I seem like not well understood or maybe seen as eccentric.

All the best,

André.


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

Re: [Tagging] Waterway length

[André Pirard]

  
  
On 2019-02-16 00:41, Eugene Podshivalov
  wrote:


  
The use of "distance" for river length distracts
  me as well.
  But I'm trying to find its origin on this wiki page
https://wiki.openstreetmap.org/wiki/Relation:waterway
  

  

  distance
  * (optional)
  Total length of river in km

  

  

  

не
знаю, почему это так
это
как, it's just like

  

  speed
  
  * (optional)
  height of the  building
  

  

it should be changed as well (re-written)
and other distances for lengths if there is


  

  Cheers,
  Eugene

  
  
  
сб, 16 февр. 2019 г. в 02:33,
  Graeme Fitzpatrick :


  



  On Sat, 16 Feb 2019 at
01:38, Eugene Podshivalov 
wrote:
  
  

  
André, that's correct but do you happen to know
  why "distance" was selected for route and waterway
  length then?
  

  
  
  
  No idea why, but rivers should certainly be shown
with a length.
  
  
  EG The Nile rises in Lake Victoria & travels to
the Mediterranean with a length of ~6695km (depending on
reference used), but the distance between Kampala, on
the north shore of Lave Victoria & Cairo is only
3300km.
  
  
  OSM shows it fairly accurately as 6853km but as a
distance, when it should clearly be a length - may be a
re-write required?
  
  
  Thanks


Graeme
  

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

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



  


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

Re: [Tagging] Imagery variations/misalignments in iD - which to use?

[André Pirard]

On 2019-01-12 06:33, Eugene Alvin Villar wrote:
On Sat, Jan 12, 2019 at 8:26 AM John Willis > wrote:


The issue I am facing is that, even after some adjustment of the
angle of bing imagery, there seems to be some distortion. things
don’t line up well between the Bing and ortho maps in some places,
and are much closer in others.  a *lot* of the mapping aligns with
the bing imagery, but there are areas of obvious 2-3m distortion
in places (the road is wavy), but other areas of newer/clearer
imagry align with the ortho imagry.

Bing is sometimes (often? I almost never use it) inconsistent (offset) 
with itself at different zoom levels.
I also encounter this "wavy" roads in imagery. I think they are the 
result of improper orthorectification by the imagery provider. 
Satellite imagery is often off-nadir (not photographed straight down) 
so providers correct for differences in terrain elevation by 
rectifying them based on available elevation models. Unfortunately, 
many elevation models like SRTM cannot distinguish between buildings 
and hills and so roads are often distorted around tall buildings in 
many parts of the world.
I don't think that orthorectification uses elevation maps as correction. 
Rather, they combine shots from different angles to compute the position 
of objects and that computes their elevation. A nadir photograph of a 
building is uninteresting because it only shows the roof. Side shots 
show the walls and allow computation of their height and ground 
location.  Aerial imagery shows only one of the many shots they have.
I don't have any good solution for this aside from trying to get 
access to better imagery so I just try to map things as best as I can. 
It may also help to avoid micromapping unless you are sure that the 
imagery is really good.
The orthorectification we can use in Wallonia (PICC) is really perfect. 
Of the lines I see it computes in places I know, almost only the center 
of the road can be not wrong but debatable. Sometimes lanes that have 
been changed to parking or things like that are not up to date, but 
that's manual fixing, not orthorectification.


All the best,

André.


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

Re: [Tagging] Quick Building tracing question... -> Area Selector JOSM plugin

[André Pirard]

On 2019-01-10 03:42, John Willis wrote:
I am tracing and repairing existing traces of warehouses in an 
industrial district.

On a slightly different but similar subject.
To do serious fast building tracing, one should use JOSM with Area 
Selector Plugin  and an 
orthorectified map such as PICC in geoportail.wallonie.be or 
basemap.at.  That goes, complete with auto-incrementing street number 
tagging, at the rate of one house per 5-10 sec, but needs occasional 
touch up with Improve Way Accuracy tool.
While doing that I also make lots of corrections to traces by other OSM 
editors with a 2, 5 m or more precision error.
This is partly because they trace roofs from aerial maps, which are not 
at ground location because the camera view and walls are slanted. But 
also the roads are affected by imprecision.
Orthorectification does an incredible job of putting that right, 
impossible to do by hand. It computes the slant angle in one place, uses 
it in another, uses shades on the ground etc. I've seen it detect in 
meadows banks (slopes) that were strictly invisible to the eye.

This raises a problem.
When meeting untagged buildings that have been coarsely traced 5-10 m 
away from their position, should they simply be erased and replaced in 5 
secs or should 20+ sec instead of 5 be spent for conflation?
I asked Paul to add conflation 
. He did it, but with no 
tag merging.
I suggested that Area Selector simply invoked Replace Geometry instead 
.
If you feel that conflation is important, please visit these pages and 
back these requests.
Many of the warehouses have large (3-6m) roofs over the loading dock 
gates, making the building appear bigger.


here is an example.
https://www.openstreetmap.org/way/494766956

if I am mapping this kind of warehouses, which should I:

- map the whole structure as a warehouse

- map on the building portion as a warehouse (as I have done)

- map the building as a warehouse and map an attached polygon as the 
roof (which I haven’t done yet).


I am going to spend the time cleaning up UltimaSnorlax’s bad polygons, 
I might a well draw them correctly the first time.


Javbw



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

Re: [Tagging] [OSM-talk-be] identifier in ref:xOperatorx=y0yyyy to url=http://mijnlijn.be/y0yyyy

[André Pirard]

  
  
On 2018-11-18 19:05, Kevin Kenny wrote:


  

  
On Sun, Nov 18, 2018 at 11:16 AM André Pirard
  <a.pirard.pa...@gmail.com>
  wrote:


  
Jakka's
  point is not that "url" is used but that it could be
  wanted and that this usage would prevent it.

To prevent the "first jumping on it owns it" practice,
the good move would be to consider that anything:url is
officially an URL.
"being officially" meaning principally that listings
make it a clickable link.
Even though any URL can be recognized inside any text
and made clickable.
But I've had problems suggesting to make multiple tags
containing URLs clickable.
The answer was: "the URL tag exists already" ;-)



For whatever it's worth (probably not much), when I
  imported the New York City DEP recreation lands data, most
  of the facilities had multiple URL's - the main URL for
  the facility, the URL for the facility's official map, the
  URL for the site where permits can be obtained (if permits
  are required)...


At the time, JOSM warned me about 'url' and proffered
  'website' in its place, so I went with that in place of
  'url'. For the secondary sites (map, permit service, ...)
  I used 'website:map', 'website:permit', etc.  The tools
  appear to recognize it - at least when I call up a place
  like https://www.openstreetmap.org/relation/6304825,
  the URL's render appropriately as links. I may have got it
  all wrong, but nobody corrected me on talk-us or imports
  at the time.
  

  

In strict parlance, an URL refers to any resource and its name is
self-describing its type (with a scheme), e.g. mailto:me@there.
(if you click on mailto: the software may open a new e-mail message,
and on tel: it may dial a number, there are no coffee: nor tea:)
So, it's a matter of knowing if we want to reopen this discussion
for a new key for each scheme or do it all with url="">
A web site is a collection of web pages.
In any case, it is map:website, the website that is an attribute of
the map and not website:map which is the map of the website.
Just like the door:key is the key of the door and not the door of
the key.
Most general concept comes first and its parts or attributes come
last.

All the best,



  

  André.

  




  


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

Re: [Tagging] [OSM-talk-be] identifier in ref:xOperatorx=y0yyyy to url=http://mijnlijn.be/y0yyyy

[André Pirard]

  
  
On 2018-11-18 13:47, Jo wrote:


  Frank,


url wasn't used yet on the bus stops, so no conflict there.
  

Jakka's point is not that "url" is used but that it could be wanted
and that this usage would prevent it.
To prevent the "first jumping on it owns it" practice, the good move
would be to consider that anything:url is officially an URL.
"being officially" meaning principally that listings make it a
clickable link.
Even though any URL can be recognized inside any text and made
clickable.
But I've had problems suggesting to make multiple tags containing
URLs clickable.
The answer was: "the URL tag exists already" ;-)

All the best,



  

  André.

  



  
Pieter, good to hear De Lijn plans such deep links. I think
  it will be good to have them on our route_master relations.
  The route relations are for the longest variations in
  itinerary, not sure if they fit there.


For the stops, I tend to like the mijnlijn.be/
  form, as that is the information printed on each of the paper
  schedules on the stops. So if De Lijn is not planning to
  abolish those in the medium term, I'd prefer to use them. I'll
  hold off with preparing the data and launching the Project of
  the Month though.


Pieter, is De Lijn planning to introduce uic identifiers we
  could put in uic_ref?


We don't have anything that corresponds to the zones in
  OSM. I'm curious to find out what will be behind those urls. I
  painstakinglly added the zone information on the stops, but
  now that a ticket has a time limitation instead of a zone
  dependent one, they became less relevant.


Marc, we can leave the ref:De_Lijn tags. I'm not strongly
  against keeping them, but I doubt anyone uses them (except me
  in my integraton scripts). If anyone wants to use them, it's
  trivial to extract the identifiers from the url tag values.


There is another tag I'd like to introduce. While reviewing
  the import of bus stops around Finland, they added a direction
  tag.


My first reflex was to remove it after reviewing the stop,
  but now I start to see value in knowing in which direction the
  bus will leave. I plan to add functionality to PT_Assistant to
  calculate it automatically based on the segment of the way the
  stop is adjacent to. And in a second stage a validator rule
  that checks whether the stop is (still) on the correct side of
  the road (right or left, depending on the side of the road
  vehicles drive on)


Polyglot






 
  
  
  
El dom., 18 nov. 2018 a las 11:19, Pieter
  Colpaert ()
  escribió:

Hi Polyglot,
  
  We are in a Linked Data project with De Lijn and we’re going
  to have 
  official persistent identifiers (HTTP URIs) soon for stops
  (but also for 
  things like the routes and zones). It might be interesting to
  integrate 
  these in OSM rather than the mijnlijn.be
  one?
  
   From the moment we have an official URI strategy, I will get
  back to 
  this list in each case.
  
  Kind regards,
  
  Pieter
  
  On 18/11/18 11:10, Jakka wrote:
  > Using key as "url=""http://mijnlijn.be/303079"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mijnlijn.be/303079   
  (<- you can test this, the url is
  >> expanded/translated to a url on www.delijn.be )
  >>
  >> For the conversion, I'd like to launch a Belgian
  "Project of the month",
  >> so the position of the stops can be verified once
  more by locals, but
  >> also shelters and bus_bays can be added and if cycle
  ways split off to
  >> go around those bus bays, that detail can be added as
  well.
  >>
  >> I know that that is what we have been doing for the
  past 5+ years, but
  >> now it would get some more dedicated focus.
  >>
  >> For several years I thought having the identifier n a
  dedicated ref:X
  >> tag and then telling everyone about how to turn it
  into such a url was
  >> the way to go,. That doesn't actually work though.
  Nobody knows how to
  >> get from the identifer to the url. Giving 

Re: [Tagging] highway=crossing used on ways

[André Pirard]

On 2018-10-13 11:22, Mateusz Konieczny wrote:
12. Oct 2018 09:25 by gpetermann_muenc...@hotmail.com 
:


In November 2015 I fix nearly all such ways, since then the number
increased again to 488. I don't know about iD, but JOSM prints a
warning
when you use this tagging, still many edits were made with JOSM. I
wonder if that means that we should accept highway=crossing as a
shortcut for highway=footway + footway=crossing?

I once opened a thread saying that the term "crossing" is contradictory 
with "passage pour piétons".
The English term restrictively suggests being perpendicular to the road 
and is tagged on a node.
The French concept covers zebras that are drawn on & along -- e.g. half 
of -- the road, is tagged on the highway on which the passage runs, and 
they do exist. Unanswered problem: how to tag which side of the road the 
paint is on.
That feature meaning a place where pedestrians can walk safely, even a 
full area applies.


The answers were typical of "tagging for the renderer", e.g. disguising 
sidewalks as being on the road.


How do we tag that without being "fixed"?

All the best,

André.


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

Re: [Tagging] Ignore roundabout flare in counting

[André Pirard]

On 2018-10-05 20:35, Florian Lohoff wrote:

Hi,
is there a tag to ignore a roundabout flare in counting the exits?

Is it a good idea for a navigator to ignore an exit and risk confusion?
What number should it say if that's the way to go?

We have a roundabout with a private driveway connecting to the
roundabout. Visually you wont actually count that service road
as a valid roundabout flare but still its a connection.

A mapper now changed to a faked topology to fix the announcements
of the navigation which i reverted.

Is there tagging to let announcements ignore that flare?

Flo


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


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

Re: [Tagging] Feature Proposal - RFC - Default Language Format

[André Pirard]

On 2018-09-24 14:36, Joseph Eisenberg wrote:
Please see the Proposal page for the new tag, "language:default=" 
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format 
Description: "Specify the default language format used for names, and recommend use

of language-specific name tags.

"By making it easier to use language-specific name:code=* tags to be
used instead of the default name=* tag, this proposal will encourage
the use of name tags that include the language code for all features.
This will improve the quality and utility of the database. It will be
possible to display non-Western languages in their correct orientation
and script, properly display multilingual names, and to research the
most commonly used language formats in a particular area.

"The key language:default=* with a 2 or 3 letter ISO language code
should be tagged on administrative boundary relations, such as
countries, provinces and aboriginal communities. This is the language
used for the majority of named features within a particular region, as
indicated on public signs and in common use by the local community. If
the language can be written in more than one script, a qualifier can
be added to specify the script format. More than one language code can
be listed, separated with a semicolon, if the local community uses
more than one language on signs or by consensus.

"The language tag should be applied to the largest boundary relation
that accurately represents the language used for default names. When a
smaller administrative boundary has a different default language
format, this boundary should receive a language tag as well. This
would include boundaries of provinces or aboriginal lands where a
different language is used.
All tags using defaults should not use their own, different but the same 
mechanism defined by the Defaults 
proposition.

Hence, a default for a tag
language=xxx
which can be coded in any OSM object is
def:language=xxx
coded in the administrative relation you say, or equivalent.

This allows uniformly writing/upgrading the same program to handle all 
defaults instead of each default using its own program.
The Defaults 
proposition 
must obviously be decided before the defaults that use it.


All the best,

André.



"The language tag may also be applied to individual features when the
name is in a different language than the default for the region, or
when the feature crosses a border."

Please read the whole page, which has quite a number of examples and a
detailed rationale for the proposal, then please comment here or on
the discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format

Thank you for all of your comments, criticisms and suggestions
-Joseph

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


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

Re: [Tagging] [OSM-talk-be] cadastral plan now open data

[André Pirard]

cle closer to 1-2 years (for every 
municipalities) for the PICC, but they are still far from it (6.5 
years of average update time).


Is there something i'm missing out in your explication ? If so tell 
me, i may not understand all your point !



Le ven. 21 sept. 2018 à 23:23, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> a écrit :




sent from a phone

On 21. Sep 2018, at 21:32, André Pirard mailto:a.pirard.pa...@gmail.com>> wrote:


The whole cadastral map is offset by that 7m.
...

*Picture 3:* So, I dragged his parcel right onto the wall.
And now it's correctly located, aligned with the fencing all around.



how did you know which source was off, the cadastral map or the
orthophoto?



...

The Belgian cadastre is not the only one with an error shift.
With JOSM, I have similarly proved that Google Map has a 120m NE
shift in Beijing.
Nobody noticed it.



it is well known that the chinese government requires all imagery
and map providers to use chinese algorithms which distort the map
coordinates systematically, in a way that they remain usable as
long as your navigation system uses the same algorithms.

Ciao, Martin
___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging



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


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

Re: [Tagging] [OSM-talk-be] cadastral plan now open data

[André Pirard]

On 2018-09-21 23:22, Martin Koppenhoefer wrote:


sent from a phone

On 21. Sep 2018, at 21:32, André Pirard <mailto:a.pirard.pa...@gmail.com>> wrote:



The whole cadastral map is offset by that 7m.
...

*Picture 3:* So, I dragged his parcel right onto the wall.
And now it's correctly located, aligned with the fencing all around.



how did you know which source was off, the cadastral map or the 
orthophoto?

The ortophoto is guaranteed with a 20 cm precision all over Wallonia.
On the other hand, all aerial photos cannot be off by the same 7m could 
they?
On the first foot, juxtaposing precisely measured parcels produces huge 
errors that vary all over a village.

I just can't figure.
I did not check if this occurs at gaps when crossing roads or what.
I'm not working for the Cadastre. I pay them ;-)

In Beijing, it was Google Maps that moved.
Satellites (several if I recall) were showing OSM in the right place.

All the best,

André.



...

The Belgian cadastre is not the only one with an error shift.
With JOSM, I have similarly proved that Google Map has a 120m NE 
shift in Beijing.

Nobody noticed it.



it is well known that the chinese government requires all imagery and 
map providers to use chinese algorithms which distort the map 
coordinates systematically, in a way that they remain usable as long 
as your navigation system uses the same algorithms.


Ciao, Martin


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


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

Re: [Tagging] Mapping language borders, tagging offical languages?

[André Pirard]

On 2018-09-20 17:16, Kevin Kenny wrote:
On Thu, Sep 20, 2018 at 9:55 AM André Pirard <mailto:a.pirard.pa...@gmail.com>> wrote:


Belgium speaks 3 official languages and their very official
borders *have been* mapped.
This subject was presented several times on this list and "raised"
a total lack of interest.
Especially regarding the need to define a language boundary type.
The most similar country regarding languages is Switzerland.
But they did not care to define borders, AFAIK.
Same for USA, Canada, etc.


"Did not care to define" is an odd way of putting it. USA cannot map 
official language borders because USA has no official language or 
languages. The majority language is, obviously, US English, but there 
is no legislation making it official nor requiring government business 
to be transacted in English. We also have a long and ugly history of 
nationalists suppressing minority languages, but generally speaking, 
the laws that the nationalists claim to be enforcing do not exist. 
"English as official language" legislation has been introduced in 
virtually every session of the Congress, and has never passed. The 
movement to make English official goes all the way back to 1780, even 
before the war of American independence was concluded.
Your comment is very friendly and welcome, but, unless each and every 
case is like what you say, let us first keep the discussion to whether 
OSM should implement language borders and how.

Best regards / meilleurs voeux / (sorry, I don't speak Flemish)
How nice, but what even most French typing persons cannot do is 
correctly type "vœux".
Not supported by Windows. Ubuntu/Debian.Linux/Unix are needed to type 
 o e ;-)


Пока ;-)
I suppose one could tag 'official languages' of  US jurisdictions that 
sort of have them. Until recently, California and Massachusetts had 
laws on the books requiring public schools to teach classes only in 
English. (Arizona still does, but California and Massachusetts 
repealed their laws in the last couple of years and have reinstated 
bilingual education.) Dade County, Florida had a well-publicized local 
law that forbade transportation signage in any language but English, 
requiring Spanish-language signs to be taken down. About half the 
states have laws requiring that the edicts of government must be 
published in English (but not requiring that it be used to the 
exclusion of other languages). Nebraska's legislation after the First 
World War had the effect, briefly, of banning all foreign-language 
instruction in the state's schools (and Heaven help those who wished 
to prepare for travel abroad!).


It is true that in the US, one can expect to find street signs in 
English (augmented possibly with one or more minority languages), but 
that is usually a matter of practicality rather than formal policy.


I suppose that one could also, as an example, draw an official 
language border around the Navajo Nation and indicate that Diné bizaad 
and Spanish, as well as English, are official languages of its 
government, but that again opens the whole debate about how to 
domestic dependent nations, and it is accurate to state that I don't 
care to reopen that debate today.


Best regards / meilleurs voeux / (sorry, I don't speak Flemish)

Kevin



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

Re: [Tagging] Mapping language borders, tagging offical languages?

[André Pirard]

  
  
Hi,

Yes, only official languages should be mapped.
They're difficult enough already to be verified "on the ground" in a
survey.
Belgium speaks 3 official languages and their very official borders
have been mapped.
This subject was presented several times on this list and "raised" a
total lack of interest.
Especially regarding the need to define a language boundary type.
The most similar country regarding languages is Switzerland.
But they did not care to define borders, AFAIK.
Same for USA, Canada, etc.

Meilleures salutations,
Beste groeten,
Bestem Gruß,
Best regards,



  

  André.

  




  


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

Re: [Tagging] What is a terrace after all?

[André Pirard]

On 2018-09-10 02:27, André Pirard wrote:

Hi,

According to my OSM readings, I thought that a terrace was something 
very special, but, according to dictionary.com 
<https://www.dictionary.com/browse/terrace>, a terrace is most exactly 
like French, mainly a) raised ground, b) flat top of a building c) an 
accessible area connected to a building at ground or upper level, such 
as for living or other purposes..
But beside that, dictionary.com defines a Terrace as a plain row of 
houses without a terrace at all and so does building=terrace 
<https://wiki.openstreetmap.org/wiki/Tag:building%3Dterrace>, unlike 
French and Wikipedia which calls it Terraced_house 
<https://en.wikipedia.org/wiki/Terraced_house> (adjective).


Practically, I'm correcting hundredths of houses tagged at 3-5m+ away 
from their true location, with incorrect shape and without any addr:* 
at all. And during this I met areas tagged building=terrace that, of 
course, are just as imprecise: they get across the houses.
If I map the houses that are inside, I get a very logical JOSM 
congratulation: "building inside a building".

In my mind, building=terrace is a bad tag. It should be:
building=house
house:terraced=yes
be it as a row of houses or a single one.
But I'm sure a reply will be "we" are not doing like that.  Like what, 
then.
What should I do? building=terrace 
<https://wiki.openstreetmap.org/wiki/Tag:building%3Dterrace> describes 
mapping separate houses as an *alternative*.

Erase what another mapper did, and replace that element with houses?
While waiting, I converted them to landuse=terraced (invisible).

On the other hand, I once asked how to map a part of the street that 
is fitted with tables and seats near a café or restaurant.

That is a *real* terrace.
No answer.

All the best,

André.


So, in summary of this discussion, we have terraces, flat surfaces, and 
we have houses that are houses and not those flat terraces but that we 
call building=terrace and not houses. The wiki suggests to map then 
separately which stops calling them terraces and to call them 
building=house because they are not another kind of houses that some do 
not call houses but detached.
I said that, while waiting to know what to do, I would temporarily keep 
the outline tagged with landuse=terrace. Someone suggested that I should 
keep the outline (permanently, I suppose) but he didn't say with which 
tag. Someone suggested that I should use landuse=residential instead. I 
said that I kept the outline temporarily and a so-called terrace landuse 
shouldn't be transformed to residential which already exists and is 
around the village instead of a few houses.


I disagree with suggesting a whole menagerie of tags for houses, so that 
someone making a search for them has to consult a whole inexisting 
catalog of keywords to use.
I suggest a single building=house plus a series of attributes like 
house:terraced=yes if you like it, dot disappearing if the house stops 
being mapped as a row, house:detached=yes for those who didn't notice 
and to avoid calling 90% of the houses like that, house:row=yes etc to 
your imagination and liking.


Now, finally, the only terrace in that story is (thanks, Marc) called a 
leisure.


Thanks to all,
All the best,

André.



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

[Tagging] What is a terrace after all?

[André Pirard]

Hi,

According to my OSM readings, I thought that a terrace was something 
very special, but, according to dictionary.com 
, a terrace is most exactly 
like French, mainly a) raised ground, b) flat top of a building c) an 
accessible area connected to a building at ground or upper level, such 
as for living or other purposes..
But beside that, dictionary.com defines a Terrace as a plain row of 
houses without a terrace at all and so does building=terrace 
, unlike 
French and Wikipedia which calls it Terraced_house 
 (adjective).


Practically, I'm correcting hundredths of houses tagged at 3-5m+ away 
from their true location, with incorrect shape and without any addr:* at 
all. And during this I met areas tagged building=terrace that, of 
course, are just as imprecise: they get across the houses.
If I map the houses that are inside, I get a very logical JOSM 
congratulation: "building inside a building".

In my mind, building=terrace is a bad tag. It should be:
building=house
house:terraced=yes
be it as a row of houses or a single one.
But I'm sure a reply will be "we" are not doing like that.  Like what, then.
What should I do? building=terrace 
 describes 
mapping separate houses as an *alternative*.

Erase what another mapper did, and replace that element with houses?
While waiting, I converted them to landuse=terraced (invisible).

On the other hand, I once asked how to map a part of the street that is 
fitted with tables and seats near a café or restaurant.

That is a *real* terrace.
No answer.

All the best,

André.



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

Re: [Tagging] Tagging suggestions for electricity

[André Pirard]

On 2018-08-31 23:51, Graeme Fitzpatrick wrote:
Going back to the original suggestion, wouldn't it be much simpler 
just to say this house / building has power connected / available: 
electricity = yes / no? :-)


Could this actually be set up as a country default?


Alas, OpenStreetMap is a database that speaks of defaults all the time 
but that refuses to encode them 
.

OSM's defaults must be encoded in other databases.
Best known are the default speed limits that belong to every other GPS 
programs.
Instead of just reloading OSM data, users must upgrade those application 
when they change.

So, this discussion belongs in those other databases.

All the best,

André.




eg in Australia, UK, Western Europe, US "most" buildings will have 
mains power of one type or another connected, while in less developed 
countries eg a lot of Africa, "most" buildings wouldn't?


Thanks

Graeme


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


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

Re: [Tagging] Tagging suggestions for electricity

[André Pirard]

On 2018-08-31 00:47, Warin wrote:
Agreed with Paul statement about earthing system which is specific to 
each building
Earthing systems are usually mandated and common to some bureaucratic 
boundaries.

My earthing system was extremely specific indeed.
The terrace soil squashed down and, although duly inspected and 
validated, the stakes in it pulled the wires out of the house.

Yes, I paid bureaucracy indeed.

All the best,

André.


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

Re: [Tagging] building = house vs detached.

[André Pirard]

On 2018-07-22 20:56, Mike H wrote:
The definitions of building=house and building=detached on the wiki 
are very similar and don't seem to have any meaningful difference.


I've seen people say that house is meant for rowhouses, and detached 
should be for stand-alone houses, but there is no documentation that 
explains that. If that is the intended meanings of the tags, then the 
wiki pages need some work.


As far as how I've seen things actually mapped, I've only ever seen 
the building=house tag. Taginfo shows 1.2 million uses of detached, 
and 27.2 million uses of building=house, so they are both used quite a 
bit, but house is used a lot more.


Can anyone elaborate on these tags, or have ideas on how they could be 
better written about?


https://wiki.openstreetmap.org/wiki/Tag:building%3Dhouse
https://wiki.openstreetmap.org/wiki/Tag:building%3Ddetached

Not speaking of semi-detached that I stumbled upon and which is not in 
the wiki at all.


So, we have building=house and building=yes at least.
If we start using building=detached we no longer know if it's a house or 
a plain building, do we?

So, detached is not a type of building but an attribute of it.
Else, we would use building=detached for a church.
Detached is not a really useful attribute because it can be seen on the 
map and a program can easily determine that one ore more walls are shared.
But if the feeling is that it should be coded, the syntax should be 
something like house:detached=yes|semi or rather 
building:detached=yes|semi or something like that.
Similarly, if one and the wiki speak of terraced (adjective) houses, is 
a terrace a single object with a single house (ahem) number or should 
the houses be mapped separately with the attribute building:terraced=yes?

All that must follow strict logic rules and not vague feelings.
And probably the feeling to code building:color=red will be even 
stronger because it cannot be seen on the map, but in that case don't 
forget to tell the owners to warn about new paint ;-)
As to adopt the terminology of a specific country, it would mean that a 
map reader were expected to know all of them to be able to read the map.


Could the wiki be updated to discourage detached=yes and probably 
introduce building:= as needed so that this discussion 
is not repeated periodically? (there are timid 
building:cadaster/fireproof/levels already)


All the best,

André.


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

Re: [Tagging] tagging bicycle charging stations

[André Pirard]

On 2018-06-28 13:40, Paul Allen wrote:
On Thu, Jun 28, 2018 at 4:40 AM, André Pirard 
mailto:a.pirard.pa...@gmail.com>> wrote:


On 2018-06-27 16:28, Paul Allen wrote:

[Suggestion to use amenity=charging_station + charging:bicycle=yes + 
charging:car=yes


I remember having been told off by someone who doesn't like
namespaces: "we are not doing like that" ;-)


People on this list have strong opinions.  Often those opinions are in 
opposition.  But whoever told you not
to use namespaces is ignoring the fact that OSM already does use 
namespaces. If most people say yes
and one person says no but presents no valid argument for his 
objection, ignore that one person.
OK, but they shout louder and the problem is that it's the other 
contributors who must ignore them.
And it's painful to read replies with just what is sub-optimal in a 
proposition and no better alternatives towards the same goal.


But you are, like me, perfectly right using it because we could have

charging:bicycle:amperage=* different from charging:car:amperage=*


Do we need it?

Please understand what I meant.
I'm just demonstrating the general versatility and usefulness of 
namespace, not discussing amperage.

"could have things like..." if you prefer.
(But then, charging:amperage=* won't hurt and be consistent)

The connectors have a maximum amperage, which may fall off as the battery
becomes nearly full, or because battery temperature monitoring 
throttles the current.  If there are
different physical sockets for cars and bicycles then you specify 
their maximum current with
socket:typeX=7 or whatever.  If it's the same socket for both then you 
just specify the maximum
current and it's down to whatever you plug in to draw as much or as 
little as it needs.


You'd only need the charging:bicycle:amperage if it's a common socket 
but with the smarts to
detect what kind of thing is plugged into it and limit the maximum 
current accordingly.


All that said, if cars and bikes have different sockets then tagging 
the socket type is enough
to determine if bikes can charge there.  If it's a common socket then 
the maximum current is
enough to figure out if you can charge only a bike, or a bike and a 
car, or a bike, a car and a
truck there.  Of course, there may be other constraints: the charging 
point may have a connector
capable of being used by bikes, cars and trucks but trucks won't fit 
in the parking space and the
operator doesn't like bikes taking up a socket but only permits cars.  
Which puts it into the

realm of access restrictions.

--
Paul



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

[Tagging] Identifying language regions

[André Pirard]

On 2018-04-18 21:41, Yuri Astrakhan wrote:
> What would be the best tags to use for mapping language regions?  I
> would like to create a map of primary languages spoken in an area.
> This will greatly help with multilingual maps, allowing data consumers
> to calculate which language name tags to use for which locale. This
> will also give OSM community a much greater control over such maps.
>
> Proposal (relations only, must have closed polygons):
> type=language
> primary=xx   (required)
> secondary=yy;zz;...  (optional)
>
> A relation may span multiple countries (e.g. US and most of Canada for
> English), or split countries (e.g. EN and FR regions in Canada). In
> some cases, the relation will reuse country border ways.
>
> What do you think?
>
We do have language mapping in Belgium
. Look at the subareas:
>
>   * Relation German-speaking Community (2425209)
>  as subarea
>   * Relation French Community (78967)
>  as subarea
>   * Relation Flemish Community (53136)
>  as subarea
>   * Relation Wallonia (90348)
>  as subarea
>   * Relation Brussels-Capital (54094)
>  as subarea
>   * Relation Flanders (53134)
>  as subarea
>
Beside the 3 administrative boundaries for regions Wallonia, Flanders
and Brussels, we have 3 *official* French, Flemish and German speaking
communities. These, failing a suitable boundary type, have been tagged
as political as follows :
> boundary 
>   political
> 
> name 
> Communauté française
> name:de 
> Französische Gemeinschaft
> name:en 
> French Community
> name:fr 
> Communauté française
> name:nl 
> Franse Gemeenschap
> nat_name
> 
> Communauté française de Belgique
>
The language boundaries subtree (nesting) is made possible for
non-administrative boundaries with the extremely clever (*) and
practical subarea concept. Administrative boundaries, such as
municipalities, are included as parts of the language trees at the bottom.

I have several times suggested a "language" boundary type (with
provision for minority languages etc.) and using the cleverness of subareas.
The conclusion from the total lack of answers is that the OSM community
is interested in neither (hence my astonishment reading this conversation).

All the best,

André.


(*) be it only the possibility to show the boundaries as simply as in
this message rather than saying look for and gather the boundaries with
admin level=x or find and use a program that does it and if there is no
admin level say goodbye to your project.

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

Re: [Tagging] Tagging turn restriction defaults

[André Pirard]

On 2018-04-05 05:16, Paul Johnson wrote:
> What would be the best way to handle setting unusual defaults on a
> regional basis?  For example, all of the City of Tulsa and State of
> Oregon prohibit U-turns at traffic lights.  How would one tag for
> this, and the inverse, tagging where such a turn is allowed by a sign?

OSM does not encode defaults in its database.
There is a Proposed features/Defaults
 , but
instead of being validated or improved, it was abandoned.
Defaults are encoded in external databases, one per routing engine.

> Most complicated example I can think of is one intersection I remember
> is at https://www.openstreetmap.org/node/4597658691 and it's
> immediately adjacent companion for the other carriageway just south. 
> U-turns are banned in Oregon at traffic lights, but facing Canyon Road
> eastbound and westbound is a sign that says "U Turn OK, CARS ONLY". 
> Northbound and southbound traffic cannot U-turn at the light.  So
> there would need to be an exception for motorcars coming from the east
> or west to allow a U-turn and a statewide regional default to deny
> U-turns at lights for all modes.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Tagging request: unnecessary admin_level tags

[André Pirard]

On 2018-03-11 00:37, Eugene Alvin Villar wrote:
> On Sun, Mar 11, 2018 at 12:41 AM, André Pirard
> <a.pirard.pa...@gmail.com <mailto:a.pirard.pa...@gmail.com>> wrote:
>
> Hi all,
>
> Please all, take a very attentive look at this.
> Please note the subject change: unnecessary.
> Please note the disambiguation boundary vs borderline.
>
> The problem with admin_level tags is that numbers need to exist to
> *be **able* to nest boundaries and hence that only administrative
> boundaries are nestable.
> That problem does not exist with subarea relation roles [...]
>
>
> Subareas will not work for my country. We generally have the following
> hierarchy: region > province > city/municipality.
>
> However, we have two cases where a city inside a province is part of a
> different region from the rest of the cities and municipalities of
> that province. In this case, using admin_level=* to properly indicate
> the administrative boundaries in type=boundary +
> boundary=administrative relations is unavoidable.
Not at all.
Using an inner way role, a boundary area can have a hole in it: the hole
that your city makes in the wrong province
and that hole can be a subarea somewhere else in the tree: your city
must be a subarea of the right province.

I don't know the cities you speak of, but we have a similar case in Belgium.
Even a bit more complicated.
We use country > region > arrondissement> province > city/municipality.
Brussels capital is a city that doesn't belong to province Brabant where
it's in, not even Flanders where Brabant is.
Brussels-Capital belongs to Belgium directly as you can see in the part
of the quote that you removed.

If you look at France <https://www.openstreetmap.org/relation/2202162>,
you will see many subareas that are holes somewhere else.
>
>   * Relation Metropolitan France (1403916)
> <https://www.openstreetmap.org/relation/1403916> as subarea
>   * Relation Guadeloupe (1401835)
> <https://www.openstreetmap.org/relation/1401835> as subarea
>   * Relation Martinique (1891495)
> <https://www.openstreetmap.org/relation/1891495> as subarea
>   * Relation French Guiana (1260551)
> <https://www.openstreetmap.org/relation/1260551> as subarea
>   * Relation Réunion (1785276)
> <https://www.openstreetmap.org/relation/1785276> as subarea
>   * Relation Mayotte (1259885)
> <https://www.openstreetmap.org/relation/1259885> as subarea
>   * Relation Saint Pierre and Miquelon (3406826)
> <https://www.openstreetmap.org/relation/3406826> as subarea
>   * Relation Saint Barthélemy (537967)
> <https://www.openstreetmap.org/relation/537967> as subarea
>   * Relation Saint Martin (1891583)
> <https://www.openstreetmap.org/relation/1891583> as subarea
>   * Relation Wallis and Futuna (3412448)
> <https://www.openstreetmap.org/relation/3412448> as subarea
>   * Relation French Polynesia (3412620)
> <https://www.openstreetmap.org/relation/3412620> as subarea
>   * Relation French Southern and Antarctic Lands (2186658)
> <https://www.openstreetmap.org/relation/2186658> as subarea
>   * Relation Clipperton Island (2573009)
> <https://www.openstreetmap.org/relation/2573009> as subarea
>   * Relation New Caledonia (3407643)
> <https://www.openstreetmap.org/relation/3407643> as subarea
>
In the north of BE there are such holes belonging to NL and even some of
those NL hole have holes belonging to BE !!!

Subareas work for everything and they are a dream. One just has to
practice and understand them.

Cheers

André.




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

Re: [Tagging] Tagging request: unnecessary admin_level tags

[André Pirard]

Hi all,

Please all, take a very attentive look at this.
Please note the subject change: unnecessary.
Please note the disambiguation boundary vs borderline.

The problem with admin_level tags is that numbers need to exist to *be
**able* to nest boundaries and hence that only administrative boundaries
are nestable.
That problem does not exist with subarea relation roles which:

  * can do the nesting without any sort of level number, including none,
and with any boundary type
  * can even nest one boundary type such as administrative inside
another such as political to avoid duplicating identical trees of
two types
  * hence make never-ending discussions unnecessary about which numbers
to use or how to insert a level between 6 and 7; levels can and
should be replaced by names such as "province" and "district" with
the result that a map can tell (name) "province Liège" from
"arrondissement Liège" (and "city Liège")
  * are much more explicit than levels (plain list of provinces instead
of having to discover them by level)
  * can easily cross-check subareas with existing levels, and would
probably easily find level mistakes
  * similarly, could easily be *generated* from existing levels
  * are much more easier to design and tag, I can tell
  * to answer a frequent duplication criticism:
  o they certainly duplicate less than a myriad of cases like
boundary Belgium 
and place Belgium
 (that should be
identical and are certainly different), and other uncriticized
duplications
  o it's not really duplication if the form is so different
  o and if both subareas and levels existed everywhere and we got
accustomed to subareas, I wonder which we would find superfluous

Notorious cases of subareas are

  * "ceremonial" Berkshire
 that is not
administrative, has no level and yet contains administrative "councils"
Berkshire itself, however, is not a subarea of a higher level but it
could
  o Relation Bracknell Forest (113682)
 as subarea
  o Relation Reading (115074)
 as subarea
  o Relation Slough (117097)
 as subarea
  o Relation West Berkshire (116938)
 as subarea
  o Relation Windsor and Maidenhead (111014)
 as subarea
  o Relation Wokingham (114311)
 as subarea
  * Belgium  is the top of
two boundary subtrees that share much of the same lower subtrees:
  o administrative
  + Relation Flanders (53134)
 as subarea
  + Relation Brussels-Capital (54094)
 as subarea
  + Relation Wallonia (90348)
 as subarea
  o political, which is linguistic administration
  + Relation Flemish Community (53136)
 as subarea
  + Relation French Community (78967)
 as subarea
  + Relation German-speaking Community (2425209)
 as subarea
  * multilingual Switzerland would be another good candidate

There should be a "language" type of boundaries and the second Belgian
subtree could be of that type.
For fast and easy navigation, there should be a "parent" role for a
boundary relation to indicate the tree(s) under which it belongs. And
also some manner for the borderline ways to indicate all the boundaries
that they belong to, at least the top one.

I'm not going to go into that, but, in theory, subareas make the "outer
way" roles unnecessary for higher boundaries of the tree. I think it's
always true that the borderline of a level is the sum of the borderline
ways of all the levels below it from which the ways that appear twice
are eliminated.
The process, however, is recursive, long for top levels like a country.
It needs accessing all its borderline pieces, both external and
internal. While that sometimes stated remark is true, it's better to use
a utility that does that process at tagging time.
That process is also at the core of a boundary consistency check, such
as being closed etc.

In a first phase, the subareas could be generated by an automatic process.
In a second phase the level based nesting could be automatically derived
from the subareas.

Thanks for your attention,

Cheers

André.

Re: [Tagging] Heat distribution networks for district heating

[André Pirard]

On 2018-02-08 14:44, Pieter Vander Vennet wrote:
> Hi Tagging List,
>
> In Bruges, we have a pipeline carrying hot water (~120°C) from a waste
> furnace to a hospital, a bakery, ...
>
> How should I map this? Is there a wiki page documenting those? Or how
> would I continue creating such a page?
Try to find out if & how Islanders map the distribution of the heat from
their geysers to homes.
Also, in Verviers, there was a steam distribution called Intervapeur

through much of the town, but I see that it has been discontinued in
2003. Similar features probably exist here and there.

Cheers
Cordialement,

André.


> Met vriendelijke groeten,
> Pieter Vander Vennet
>

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

Re: [Tagging] How to tag shop areas in a shopping mall ?

[André Pirard]

On 2018-01-24 20:46, OSMDoudou wrote:
>
> Following the discussion here, I changed the mapping of the mall to
> move tags from individual nodes to an area.
>
>  
>
> For one shop, it attracted feedback from the commercial entity who
> maintains its data on OpenStreetMap saying the change broke something
> at their side. See the discussion on the changeset: [1].
>
>  
>
> I'm very glad a company enriches the map and actively maintains the
> data (1700 nodes, they say), so I really want to support them and I
> reverted the change.
>
>  
>
> But as they're asking to maintain their shops tagged as node, this is
> effectively asking the community refrains itself from improving the
> tagging of the mall (following the idea that shops are better mapped
> as areas than nodes), and this is not in the interest of the community
> (which is to have a complete, coherent, accurate and maintained
> mapping of the place).
>
>  
>
> So, I wanted to ask your views on how to deal with this situation.
>
A shop is, as surprising as it may seem, not a building but an activity
that takes place somewhere.
In a conventional building or anywhere: in a tent, in a hall, on the
side of the street etc.
It can be tagged on a building or any area or on a node inside it, which
is the preference that I see around here.
The advantage of a node is best seen when you try to add several shops
tags to the same building/area: a nightmare.
Doing it with a number of nodes is just straightforward.
Also, a node is usable if you know too little of the geometry of the
area to map it decently.
I have often drawn buildings around shop nodes that were already there.
It's really nice to see people map their belongings.
Usually, the opposite happens: they completely ignore messages telling
them it has been done.

Cheers

André.



>  
>
> [1]
> https://www.openstreetmap.org/changeset/55640175#map=19/50.45645/3.93247
>
>

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

Re: [Tagging] access=yes|permissive allow all transport modes

[André Pirard]

On 2018-01-14 22:28, Mateusz Konieczny wrote:
> On Sun, 14 Jan 2018 21:17:12 +0100
> André Pirard <a.pirard.pa...@gmail.com> wrote:
>
>> access=no  motor_vehicle=yes  make much sense if that's the
>> intention
> This seems a poor idea, it will break everything that is not parsing
> motor_vehicle (starting from a typical rendering).
Not sure I understand what you mean with that.

They are the best tags if, as I said, only motor vehicles are allowed.
Of course, it depends on the exact intention, but with
> bicycle <https://wiki.openstreetmap.org/wiki/Key:bicycle?uselang=en>  no
> foot <https://wiki.openstreetmap.org/wiki/Key:foot?uselang=en>no
> mofa <https://wiki.openstreetmap.org/wiki/Key:mofa?uselang=en>no
> moped <https://wiki.openstreetmap.org/wiki/Key:moped?uselang=en>  no
>
as strange as it may seem, one allows horses, ski, ice_skates, and
inland_skates, and that doesn't seem to be the intention. And it may
well be that carriage=no is necessary too.
With access=no  motor_vehicle=yes, one disallows all that but I
shouldn't have written so fast: mofa=no and moped=no must be kept
because they are exceptions to motor_vehicle=yes.

In fact, the poor idea is to try to solve each and every particular case
by giving its tags.
The best answer to such a question is "how it works".

Starting with access=yes, in the land-based
<https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation>,
water-based
<https://wiki.openstreetmap.org/wiki/Key:access#Water-based_transportation>
or rail-based
<https://wiki.openstreetmap.org/wiki/Key:access#Rail-based_transportation>
transportation tables,

  * all category (indentation) levels directly below a category=yes, 
inherit the *=yes status
  o if one of these subcategory=yes is wrong, the subcategory=no tag
must be added
  o all category (indentation) levels below such a
=no,  inherit the *=no status
  + if one of these sub_subcategory=no is wrong, the
sub_subcategory=yes tag must be added
  + etc.

all that recursively.  One ends up with a complete yes/no table.
It depends on the intention and it's very simple.

Cheers

André.


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

Re: [Tagging] access=yes|permissive allow all transport modes

[André Pirard]

On 2018-01-14 17:41, OSMDoudou wrote:
>
> Hello,
>
>  
>
> Osmose is giving an error at many places around the R50 trunk with
> reason "access=yes|permissive allow all transport modes" and
> additional info "Including ski, horse, moped, hazmat and so on, unless
> explicitly excluded". For example, this way [1] has the error [2].
>
>  
>
> The road is clearly signed as forbidden to pedestrians, bikes and
> moped. [3]
>
>  
>
> I'm not sure how to improve the tagging to resolve the error.
>
>  
>
> Should I remove the entire "access" tag ?
>
>  
>
> Or set it to something else, like "access=designated" ? The road is
> not designated as for motor vehicles only and hazmat is not forbidden,
> but if care enough for you horse, you wouldn't let it go there :-) and
> nobody in his right mind would try to go ski there even on snowy days… :-)
>
>  
>
> What do you suggest ?
>
Access tags are only needed when they contradict a wider scope access
tag or rule.
access=yes is never necessary when there is nothing forbidding general
access (the highest scope).
Just like bicycle=yes is not needed when no other tag or rule forbids
bicycles.
But in access=no bicycle=yes, it is needed because allowing bicycles
contradicts forbidding all traffic.

Although there is no nuisance allowing with *=yes what is already
allowed, I advise to remove them because many contributors do their
mapping by copying the tags of similar cases. And those too many
unnecessary *=yes are not exactly teaching them this fundamental, very
basic rule of the access tags: they are confusing.
(it's a pity to find a whole list of bicycle=yes foot=yes horse=yes etc.
when nothing forbids them)

But access=no  motor_vehicle=yes  make much sense if that's the
intention (horse=no too, not speaking of elephants).

Cheers
Cordialement,

André.


>  
>
> Thx.
>
>  
>
> [1] https://www.openstreetmap.org/way/328935225#map=18/50.46032/3.95820
>
> [2] http://osmose.openstreetmap.fr/en/error/15187485950
>
> [3]
> https://www.mapillary.com/app/?lat=50.4602335=3.95913054=17=eaxXlnQC_nxGAzi9T7JU5g=photo=0.5468615573991835=0.49186316322319024=1.81360201511335
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] area=yes on object without kind + using PICC & JOSM

[André Pirard]

On 2018-01-12 14:52, Jo wrote:
> You are right in that we shouldn't base any of our mapping on what is
> visible on Google Streetview. Which is why I was suggesting that
> somebody go check it out locally. I've been looking at Belgian aerial
> imagery we are allowed to use, taken over several years. But nothing
> useful can be seen on them either. What can be seen is that almost
> never more than 1 car was parked there when the planes flew over. So
> it's definitely not a parking lot.
>
> I don't think we really have a way to tag an empty piece of land with
> no defined "function" nor vegetation on it,
>
> Jo
I have overlaid OSM with the PICC (the digitalized version of those
aerial photographs).
The PICC shows nothing more than the road border.

The PICC has a 20cm precision, is extremely well done and we can trace
it (not to be confused with "copy").
I often *highly* recommend to use the PICC with JOSM in Wallonia.
In fact, I'm spending much time to use them to correct what is
neigbouring what I'm mapping.
Often, for example, the buildings are traced as roofs based on
imprecise, vague aerial photos.
PICC shows building bases instead, very cleverly and precisely
calculated from multiple photo angles.
And with Area Selector, one can trace a streetfull of houses in a single
click each, including numbers.
I've been asked why ID and Potlatch would be worse than JOSM.
I don't know. Just that when I meet something to leave as is, I know and
I can check that it's JOSM.
See my picture. It's Potlatch.
The "area" is offset 2 m on the right and 6 m on south.
The building is 5 m away from its place and it has no number 2.
The pedestrian crossings 2m and 5m, the wood on the right 6 m.
Etc ... Often, more complicated maps are simply horrifying.
The roads are mostly right but I believe that it's better to follow
PICC's way choices closely to show that PICC was used. And PICC does the
conversion of curved to straight lines for you.
Mistakes are sometimes easily corrected with JOSM's Improve Way
Accuracy, but it's harassing to spend much time doing that while other
mistakes continue to be made. And mapping a new house is much, much
faster than correcting a bad one.

*PLEASE, PLEASE* use PICC with JOSM in Wallonia !!!
Wallonia have lost 6 years while I was trying to have the SPW correct
their PICC server's mistake and I was helping JOSM to improve.
JOSM is not really difficult to use. Use it more ans more in parallel
with another software, which you can use when you're stuck until you
find out how to do it with JOSM. You will appreciate what more you can
do with JOSM.

Cheers
Cordialement,

André.




>
>
>
> 2018-01-12 14:38 GMT+01:00 José G Moya Y.  >:
>
> Please notice that, for doing something similar to what you do
> here (reading a lot of maps and aerial imaginery, being only one
> of them [3] google maps) I was forced to erase my edition and do
> it again.
> Just to warn you.
>
> El 12/1/2018 8:30, "Jo"  > escribió:
>
> It definitely doesn't look like a public parking lot. It would
> be good if someone local could resurvey if the shop is still
> in that house.
>
> Jo
>
> 2018-01-12 5:19 GMT+01:00 Marc Gemis  >:
>
> is there street view imagery ? do you have local knowledge ?
>
> If not, you might consider not fixing it. Yes it will be a
> useless
> polygon in the database, but isn't that better than
> changing it e.g.
> to a parking lot while it is a private property ?
>
> just my .5 cents
>
> m.
>
> On Fri, Jan 12, 2018 at 12:05 AM, OSMDoudou
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com
> > wrote:
> > Hello,
> >
> > Osmose is complaining an area is mapped but not further
> specified: [1] and
> > [2]
> >
> > Here is how the place looks like: [3]
> >
> > I was thinking it's a side walk, but they're not to be
> mapped as area [4]
> > and the place doesn't really look like a square or plaza
> [5] nor like a
> > parking.
> >
> > How would you tag it ?
> >
> > Thx.
> >
> > [1] http://osmose.openstreetmap.fr/en/error/15140678368
> 
> > [2] https://www.openstreetmap.org/way/223853253
> 
> > [3] https://goo.gl/maps/yhA3rx2WVhM2
> 
> > [4] https://wiki.openstreetmap.org/wiki/Key:sidewalk
>

Re: [Tagging] building=maisonette(s)

[André Pirard]

On 2017-12-02 23:21, Warin wrote:
> On 03-Dec-17 09:09 AM, Graeme Fitzpatrick wrote:
>>
>> On 3 December 2017 at 04:58, marc marc <marc_marc_...@hotmail.com
>> <mailto:marc_marc_...@hotmail.com>> wrote:
>>
>>
>> In french, a "maisonette" is a small detached house or a tiny
>> house or a
>> shed.
>> Did this word also exist in english
>>
>
> English has stolen many words from other languages. This may well be
> one of them.
> My dictionary says "maisonette"; 1) small house 2) semi-detached house
> 3) self contained flat over 2 floors

That's what  On 2017-12-02 20:16, André Pirard wrote:
> Hi,
>
> Er (link to the dictionary)
> <http://www.dictionary.com/browse/maisonette?s=t>
>
> And, BTW, the French is maiso*nn*ette. English is both right and wrong.
>
> Cheers
> Cordialement,
>
> André.
>
That isn't stealing. That's unification, standardization.
>>
>>  Have heard the term in Australia but not for many years.
>>
>> These days, it's apparently been replaced by "Granny Flat", which is
>> a similar concept of a self-contained flat attached to a house, but
>> with it's own entrance.
>>
>
> Granny flats can be attached (or semi-detached) or completely separate
> from the main residence.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] building=maisonette(s)

[André Pirard]

  
  
On 2017-12-02 19:58, marc marc wrote:


  Hello,

https://taginfo.openstreetmap.org/tags/building=maisonette
https://taginfo.openstreetmap.org/tags/building=maisonettes
Nearly all in England.

In french, a "maisonette" is a small detached house or a tiny house or a 
shed.
Did this word also exist in english or thoses tags are a bad use of a 
french word in stead of the english one ?

Regards,
Marc


Hi,

Er

And, BTW, the French is maisonnette. English is both right
and wrong.

Cheers

Cordialement,



  

  André.

  


  


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

Re: [Tagging] [OSM-talk-be] how to map a fr:talus?

[André Pirard]

On 2017-11-24 10:55, ralph.ayt...@ntlworld.com wrote:
>
> I have had a look on the Wallonia website. If you zoom out you will
> see that this feature runs exactly parallel to the road to the south
> of it. It is man made. It would have been created at the same time as
> the road. It was done to raise the road to a higher level as a flood
> defence against the river to the north. I do not know but it may be
> that there is a retaining structure of stone or concrete to strengthen
> it but is covered with soil and grass.
>
>  
>
> The tag for this could be /man_made=dyke/ with /material=soil/.
>
>  
>
> You will see that the farmland to the south of the road has something
> similar. This is not flood defence, it is terraced farming to stop the
> run off of water on sloping farmland.
>
>  
>
> The tag for this could be /barrier=retaining_wall/ with
> /material=stone/soil/ (or whatever material is used)
>
> Hope this has been helpful.
>
>  
>
> Ralph
>
Thank you, Ralph.
If you look down below (as people started to write bottom up in the XXth
century) you will see that I found Projet de canal Meuse et Moselle
<https://fr.wikipedia.org/wiki/Projet_de_canal_Meuse_et_Moselle>
(Genglish
<http://translate.google.be/translate?u=https%3A//fr.wikipedia.org/wiki/Projet_de_canal_Meuse_et_Moselle=fr=auto%7Cen=1=UTF-8>),
seeming to confirm what I wrote: that talus is the remnants of that old
canal, commonly called "canal de l'Ourthe", washed away by the frequent
flooding of the Ourthe and of various fate along its course.
So, what I should normally do is map a canal.
But as nobody ever saw a canal with a single bank looking like a talus,
that would get me in troubles.  Not counting that the rendering, even if
we cannot tag "for" it, would try to fill it with water and cause even
more flooding ;-)

So, good-bye canal, what it has now become is a crumbled bank, a
crumbled wall I suppose..

That is just as queer, so, unless you change your mind, I'll tag it man
made=embankment
<https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment>,
according to your repeated consent, but only as a single way at the top
of the slope I suppose.
But I'll name it an old canal's bank.

Thanks to all,
Cheers,

André.


> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>  
>
> *From: *André Pirard <mailto:a.pirard.pa...@gmail.com>
> *Sent: *Thursday, November 23, 2017 10:29 PM
> *To: *OpenStreetMap Belgium <mailto:talk...@openstreetmap.org>
> *Cc: *Tag discussion, strategy and related tools
> <mailto:tagging@openstreetmap.org>
> *Subject: *Re: [Tagging] [OSM-talk-be] how to map a fr:talus?
>
>  
>
> On 2017-11-23 17:26, joost schouppe wrote:
>
> 2017-11-23 16:48 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> I'm looking for how to map what is called in French a talus
> <http://www.cnrtl.fr/definition/talus> (Google's translation).
> I would call this a 1.8m simple step running for some reason
> for several 100s meters across meadows.
> Steep slope. There are "top of slope" and "bottom of slope"
> lines. Rest is perfectly flat either side.
> It might be the remnants of a old canal's bank whose other
> side would have been eroded by the often overflowing nearby river.
> A "talus" made of plain ground is often frequent at one side
> of a path or track.
> According to the wiki, it's not a "scree" nor a "shingle".
> It's much less matter specific.
> So what?
> I'll use "scree" unless/until I hear of better for a French talus.
>
> Cheers
>
> André.
>
> I'm not entirely sure this is what you have in mind, but in the
> cases where it is associated with roads, I've seen
> historic=hollow_way (when the slope is caused by the fact that
> there's an old road), and "embankment" or "cutting" when the slope
> is deliberatly constructed. In other cases, I've seen what I think
> you describe mapped as natural=cliff, which is obviously wrong,
> but does get the message accross. For example where sand or rock
> was quarried this is common to see on the map. I'm hoping someone
> has seen better ideas.
>
> Thanks for all your fast answers from which I had to choose the first
> one to reply to.
> A photo was asked. I might go back there to make one, but you wouldn't
> see more that the surface of a meadow looking like this on a long
> distance, at varying steepness and width.
> 

Re: [Tagging] [OSM-talk-be] how to map a fr:talus?

[André Pirard]

On 2017-11-23 17:26, joost schouppe wrote:
> 2017-11-23 16:48 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> I'm looking for how to map what is called in French a talus
> <http://www.cnrtl.fr/definition/talus> (Google's translation).
> I would call this a 1.8m simple step running for some reason for
> several 100s meters across meadows.
> Steep slope. There are "top of slope" and "bottom of slope" lines.
> Rest is perfectly flat either side.
> It might be the remnants of a old canal's bank whose other side
> would have been eroded by the often overflowing nearby river.
> A "talus" made of plain ground is often frequent at one side of a
> path or track.
> According to the wiki, it's not a "scree" nor a "shingle". It's
> much less matter specific.
> So what?
> I'll use "scree" unless/until I hear of better for a French talus.
>
> Cheers
>
> André.
>
> I'm not entirely sure this is what you have in mind, but in the cases
> where it is associated with roads, I've seen historic=hollow_way (when
> the slope is caused by the fact that there's an old road), and
> "embankment" or "cutting" when the slope is deliberatly constructed.
> In other cases, I've seen what I think you describe mapped as
> natural=cliff, which is obviously wrong, but does get the message
> accross. For example where sand or rock was quarried this is common to
> see on the map. I'm hoping someone has seen better ideas.
Thanks for all your fast answers from which I had to choose the first
one to reply to.
A photo was asked. I might go back there to make one, but you wouldn't
see more that the surface of a meadow looking like this on a long
distance, at varying steepness and width.
   _
  /
 /
/

It can be seen on this map share
<http://geoportail.wallonie.be/walonmap#BBOX=233801.45736786586,233864.69291100363,138369.75440413086,138396.60966617474#SHARE=5EAB0363BC0C4A92E053D0AFA49D3CB8>,
pan it to the left and right.
The two striped, faint lines are the upper and lower edges (rims,
levels) from the BE SPW(allonie) PICC numerical imagery
<wms:http://geoservices.wallonie.be/arcgis/services/TOPOGRAPHIE/PICC_VDIFF/MapServer/WmsServer?SERVICE=WMS=1.1.1=image/png8=TRUE=GetMap==%7Bproj%7D=%7Bwidth%7D=%7Bheight%7D=%7Bbbox%7D=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29>
(JOSM) overlay allowing me to map it. As you zoom out, you will see that
the aerial photo is darker along that line.
The Cartoweb background (Fond de Plan) draws it as the typical "behind
which to hide" line of old military maps.
Well, in OSM parlance, it's not a cree because there is no cliff (1),
not a shingle because there is no sea and not an embankment because
there is no road to be an attribute of.
Well, as I said it, what I'm facing seems to be, as I found more
specifically, the remnants of this old canal @ N°12
<https://fr.wikipedia.org/wiki/Projet_de_canal_Meuse_et_Moselle#N.C2.B012_Devant_Rosi.C3.A8res>.
The river often overflows as high as above the road. When the water goes
back, it washes the left bank of the canal towards the river but the
right bank is mostly just overflown.

So, there's nothing in OSM for that precisely.
Would man_made=dyke be the most resembling and acceptable with an
explanation note?

Thanks and TIA,
Cheers

André.


(1) there's a very beautiful one, but at the other side of the river,
called "La Roche aux Faucons" (Falcons' Cliff).

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

[Tagging] how to map a fr:talus?

[André Pirard]

Hi,

I'm looking for how to map what is called in French a talus
 (Google's translation).
I would call this a 1.8m simple step running for some reason for several
100s meters across meadows.
Steep slope. There are "top of slope" and "bottom of slope" lines. Rest
is perfectly flat either side.
It might be the remnants of a old canal's bank whose other side would
have been eroded by the often overflowing nearby river.
A "talus" made of plain ground is often frequent at one side of a path
or track.
According to the wiki, it's not a "scree" nor a "shingle". It's much
less matter specific.
So what?
I'll use "scree" unless/until I hear of better for a French talus.

Cheers

André.


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

Re: [Tagging] name with name:en

[André Pirard]

On 2017-11-15 21:34, Warin wrote:
> Hi,
>
> There looks to be a duplication taking place (map.me problem ?) where
> both the name=* tag and name:en (the local language)=* are being
> entered as the same value.
There is nothing saying what language name=* is, what the failed
language=* proposal intended to do.
I stated that to do so either language=* would have to be tagged for
each name=* or that a default rule like Proposed features/Defaults
 should
be used but it was answered that this proposal is for speed limits
(which is obviously untrue), that it is abandoned (which is a huge
mistake), and that language=* needs no defaults (which is untrue too).

I just cannot imagine that, by having no default mechanism, OSM is such
that the values of many of its tags are located in various other databases.

Cheers

André.




>
> I don't think this serves any function other than data bloat and
> possible confusion if the 2 values are different.
>
>
> I am tempted to simply delete the extra name:en.
>
>
> Thoughts?
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement

[André Pirard]

On 2017-11-14 19:34, David Marchal wrote:
> Hi, Yuri.
>
> Though I understand your request and find it relevant, I’m unsure
> about altering a proposal page after the vote had started; AFAIK, I’m
> supposed to let it as is, apart from the vote section. Could you show
> me if my assumption is wrong, or can someone on the ML confirm or
> infirm that?
>
> Awaiting your answers,
Here is one.
I'm rather surprised by this remark.
I agree that a proposal which is what other persons "signed" must not be
changed.
But there are so many undiscussed changes to the wiki*_s_* (even
unnotified ones, do you remember that noexit=yes story battle? I'm
keeping the most stupid of it yet to be told) that I would praise, not
blame, Yuri for his general way of doing.
I would suggest to leave the proposal alone, except for mentioning the
following, to create a final wiki page and to ask the consent of this
list for minor modifications, especially correcting typos.

And here is one correction, with wider justification...

If I had voted (I didn't have the occasion, sorry), I would have put as
a yes voting condition to change
"Give a way to distinguish the different types of sinkholes" with "...
of natural=sinkhole

(read that article)".

The reason is

  * that foreigners non-English speakers (everyone is a foreigner to
most of the world) are liable to ignore what is a sinkhole is, and
that it would be a shame to spoil its unusually great description in
natural=sinkhole
 to tell
them
  * that one could believe that sinkhole=*
 can
go without natural=sinkhole
.
OK, it's explained below but...
  * that I suppose that many a one quickly read as far as they think
they have understood and that any means to make them feel that there
is more to it is welcome
  * that too many wiki articles use insufficient definitions (e.g.
source=survey has improved but would need a link to the explanation
inside) and
  * the net result of that is many mapping mistakes (such as the totally
useless bicycle=yes)
  * the most regrettable result is GPS mistakes because routing logic
obeys exactly what it's told

Cheers

André.


> Regards.
>
>> Le 12 nov. 2017 à 21:17, Yuri Astrakhan > > a écrit :
>>
>> David, hi, just an thought - could you combine the rationale and
>> examples sections?  The way you have it now is first you describe
>> each concept, and afterwards you have the same concept but with a
>> picture.  I think it would be better to list each variant with the
>> picture right away.
>>
>> Thanks!
>>
>> On Sun, Nov 12, 2017 at 8:30 AM David Marchal > > wrote:
>>
>> Hello, there.
>>
>> Almost 3 weeks passed and only 3 people told that they preferred
>> karst=yes instead of karstic=yes. As the first one was also the
>> one stated as the proposal, and the second one was only mentioned
>> in erroneous examples, I assume this relative unanimity is enough
>> to confirm karst=yes as the one to use, and will create the wiki
>> page accordingly. Thanks to all who voted; the proposal process
>> is now fully finished, apart from creating all the Wiki pages.
>>
>> Regards.
>>
>>
>>> Le 24 oct. 2017 à 19:16, David Marchal >> > a écrit :
>>>
>>> Hello, there.
>>>
>>> The vote period passed, and the proposal received a total of 16
>>> approvals, 1 spoilt vote and 0 refusals, so I closed the vote
>>> and marked the proposal as approved. Thanks to all the voters;
>>> I’ll create the according Wiki pages and edit existing ones to
>>> reflect the vote on the following days.
>>>
>>> As a side note, there is a secondary vote on the proposal page;
>>> indeed, some voters noticed an inconsistency in the proposal,
>>> ie. a proposal example carried karstic=yes tagging instead of
>>> the proposed karst=yes. To make sure of what version the voters
>>> approved, I have to ask them to go back on the proposal page and
>>> vote, in the dedicated subsection, amongst karstic=yes or
>>> karst=yes. Once the choice will have been asserted, I’ll be able
>>> to create the corresponding Wiki page.
>>>
>>> Thanking you for your patience, and awaiting your votes,
>>>
>>> Regards.
>>>
 Le 8 oct. 2017 à 09:51, David Marchal > a écrit :

 Hello, there.

 The normal voting duration passed, but there are not enough
 votes yet to approve or reject the proposal, so I extend the
 voting period 

Re: [Tagging] Public wifi (Fon)

[André Pirard]

On 2017-09-29 02:22, Graeme Fitzpatrick wrote:
> Hi
>
> Noticed in the discussion of the devices tag, mention of devices
> attached to telephone booths, which got me thinking.
>
> Here in Australia, Telstra provides public wifi access via it's
> Telstra Air network (https://www.telstra.com.au/telstra-air), which is
> also linked to the international Fon network (https://network.fon.com/).
>
> A lot / most of Telstra's wifi spots are mounted on public telephone
> boxes (the pink bit's shown on the above link :-)) - I don't know
> about Fon?
Fon works as a public service on consenting private WiFi routers
.
The router software completely isolates the private and public parts of
the router
Access to any working Fon router is granted to anyone who consents to
open the service on his own router or for a price. Consenting people are
charged on their home bill the traffic they use elsewhere.
Usually, router users are unaware of Fon and are consenting by default.
It would, of course, be a totally useless chore to update Fon comes and
goes on OSM and to duplicate the Fon map.

Cheers

André.


> So, do we have a tag for public wifi / internet spots? 
>
> I can't see anything for one, but I guess it would come under
> amenity=*, same as amenity=telephone for public phones?
>
> If we don't, should we?  
>
> Thanks
>
> Graeme


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

Re: [Tagging] Setting a preferred routing

[André Pirard]

Hi,

Wouldn't it be appropriate for this kind of discussion to ask
routing/GPS programmers like OSMand and Graphhopper etc. what they use
for route optimization and what else they would like to use, hence us to do.
I always say that the biggest routing problem (some people openly LOL at
OSM routing) is that taggers and wiki writers don't realize that it's a
matter of following the very strict, same rules in OSM as in the routers.
I'm disappointed to see basic misunderstanding show in tags like many
unnecessary bicycle=yes
or [OSM-talk-be] Missing oneway:bicycle=no 2017-02-14 17:33 where
oneway:bicycle
=no, an
instruction to routers, is confused with Key:cycleway, the indication of
the presence of a cycleway.
The explanation of cycleway
=opposite* and its
presence in the "access" page make believe that it's an access tag when
it's not (a cycle map confuses them and a friend tagged them both
everywhere where there is no cycleway).
I'm also disappointed that I, instead of the LOL above, have been called
sarcastic for saying things like this and help.

Cheers

André.



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

Re: [Tagging] phone validity - phone "preset"

[André Pirard]

On 2017-09-05 21:01, Lukas Sommer wrote:
> It would likely yet help a lot if th editors would simply check if
>
> - the number does not start with “+”
> - the number (after the starting “+” sign) contains other characters
> then digits, spaces (and maybe dashes).
>
> This is quite simple and could nevertheless catch yet a lot of issues…
Yes it is not too complicated.
Typing this at Ubuntu or any Linux command line does what you say:

$ read -p 'Phone number: ' number; [[ $number =~ ^[+][0-9\ \-]*$ ]] &&
echo GOOD
Phone number: 866 356 8207
Phone number: +1 866-356-8207
GOOD

It can be included in a program and easily improved to enforce a
separated country code, maximum of digits, etc.

I'll suggest this to JOSM and they'll probably do it. They're the best.

Use JOSM.  JOSM is the best.

Using Ubuntu/Linux is fun.  One can even use it without leaving Windows:
Install VirtualBox and use it to install Linux.  Ubuntu MATE recommended.

Cheers

André.


> 2017-09-05 16:51 GMT, marc marc :
>> Hello,
>>
>> on the french-speaking mailing, a contributor noticed a high rate
>> of incorrect value for the tag "phone". the most common error is using
>> the national format number instead of the international format.
>>
>> A monthly project 'll maybe fix some of those errors.
>> Some quality tool can help those fix.
>>
>> But the best would be to avoid the mistake when a user fill
>> in the data in iD, josm or whatever.
>>
>> Is anyone aware of a kind of "preset" that can be used for phone ?
>> Otherwise it would be useful to create with local communities a wiki
>> page containing a list of valid prefixes example + 322xxx is valid,
>> +331 also but 01 is not valid in France.
>> Or using something like https://github.com/googlei18n/libphonenumber/
>> https://github.com/googlei18n/libphonenumber/blob/master/FAQ.md#where-do-we-get-information-from-to-determine-if-a-number-range-is-valid
>>
>> Would it also be useful to put a corrective suggestion?
>> for example 01 #+331
>>
>> Of course, I am not talking about the exact form of the list,
>> nor the fact that some countries will have a list,
>> while others not.
>> nor the difficulty when a poi has several corresponding numbers
>> attached several countries.
>> I 'm talking about the general guideline.
>>
>> The aim is not to forbid some values but to allow
>> common editor to guide the user to avoid a very common error.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>

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

Re: [Tagging] Feature Proposal - Voting - (Language information)

[André Pirard]

On 2017-08-30 13:34, Lukas Sommer wrote:
> Voting at 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information
> is open.
Hi Lukas,

The syntax is wrong. It must be :language=
(qualifier to the right).
Example too  language:name=bg  -->  name:language=bg

Many wiki definitions are unclear about term definitions and don't say
well why the tag is used.
This one too.
Because contributors rarely read long explanations, you should briefly
say that language=* is used so that programs knew the language of name=*
if they want to display a name in a particular language or if they want
to use special fonts for a particular language, and then refer to Rationale.
For example, people said that name:ja=北京市 is already defined and that
language=ja is unnecessary.
This means that they did not understand your proposal.
An OSM contributor should understand the wiki.

The proposition says that language= is not necessary for every name but
it is.
It is so that software knows that name=* contains e.g. the French name
if it asked to use French.
Otherwise, the local name=* must be duplicated as name:fr=*

I said before that either we use language=* on every name (key) or we
rely on *a default* for those having no language=*.  That is plain
logic.  Else there will be names for which software cannot know the
value of language=*.
(your) example: name:language=ja on all Japanese names or as a Japan
default somewhere *in the OSM database*.
You replied that language= needs no default. That sentence needs a
justification like mine.
You replied that Proposed_features/Defaults
 is
abandoned. First, doing so is a big mistake. Second, doing so does not
suppress the need for defaults. You said that that proposition relates
only to maxspeed and it's untrue.
Lack of defaults is a problem that exists for other keys. Solving the
OSM lack of defaults is a priority.
I have just repeated a comment about that in "Defaults are paramount"
message on this list.

The proposition says that OSM.org do intentionally not use tags like
name:en, name:ja, name:de…
It is not intentional. It's because map tiles can only have one language
and it's impossible to display the languages in the user's order of
preferences.

The proposition says that the BCP-47 codes must be used.
But it does not say why codes different from ISO 639 (used by OSM) are
necessary and how to use them.

You say that Bulgarian Cyrillic is written differently than Russian.
Could you show more examples (URLs) that just one word?
I have read Bulgarian many times and I never saw a difference.
https://www.google.be/search?=site:bg+мап+карта
 
does not show different Cyrillic.
Here is their alphabets according to Russian ВикипедиЯ and Bulgarian
УикипедиЯ (they should know).

Russian
А а Б б В в Г г Д д Е е Ё ё Ж ж З з 
И и Й й К к Л л М
м   Н н О о П п Р р С с Т т У у Ф ф Х х 
Ц ц Ч
ч   Ш ш Щ щ Ъ ъ Ы ы Ь ь Э э Ю ю Я я
Bulgarian
А а
Б б
В в
Г г
Д д
Е е

Ж ж
З з
И и
Й й
К к
Л л
М м
Н н
О о
П п
Р р
С с
Т т
У у
Ф ф
Х х
Ц ц
Ч
ч
Ш ш
Щ щ
Ъ ъ

Ь ь

Ю ю
Я я


What difference do you see exactly?

> Example: For the Bulgarian city of Montana use:
>
> name=Монтана
>
> language:name=bg
>
> Usually rendering engines default to russian cyrillic, but this city
> is in Bulgary. See here the significant difference in russian
> rendering (above) and the bulgarian (below) rendering:
>
> Montana.svg 
>
>
This example is really confusing. You say that Bulgarians write the name
as the second line.
According the Bulgarian's mouth itself, the bottom name is no Bulgarian
for Монтана

at all. The top one is.
In fact, the bottom name is just similar to cursive Cyrillic

in which letter "tee" is written like a "emm" in both Russian and
Bulgarian as well as in other Cyrillic languages.  Quite a mind boggling
script to read for latin users BTW.
And indeed, I see on this Монтана map
 that they use cursive Cyrillic at
low zoom but plain Cyrillic at high zoom.
Using cursive Cyrillic is not a matter of language but of font.
If you use one of these fonts:
style="font-family:FreeSerif,Georgia,'Times New Roman','Nimbus Roman No9
L','Century Schoolbook L','Trebuchet MS','URW Bookman L','URW Chancery
L','URW Palladio L',Teams,serif"
you are 

[Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[André Pirard]

Hi,

Examples: either each road is tagged with *maxspeed*=*
 speed limit and
*driving_side*=* 
or there are defaults.
I'm reviving this remark because the examples are numerous:

  * The Belgian Flemish community wants to tag *maxspeed*=*
 on every road
instead of using a default. Is this a new specification and where is
it written? Must that now be done in every country?
  * The current language= proposition wants to do it without defining
defaults. Really? language= on every name= ?
  * Other examples are maxheight in tunnels. Osmose just accused me of
someone else's omitting maxheight. It shouldn't be necessary if it's
the default, that is if there is no sign for it, but Osmose likes to
yell just in case.
  * countless etc.

Please choose.

Either the defaults are in the OSM database and it takes just a
routinely map fetch to get them all updated timely,
or each other router (GPS) writer implements them each their own way
from various random other files. It's not well clear how contributors ca
update all those files instead of OSM and it typically needs a full
software update for each little default change, depending on writer's
availability.

Please choose.

There is a Proposed_features/Defaults
 that
puts the defaults in OSM and it's an EXTREMELY HUGE mistake to have
marked such a paramount good work as abandoned because nobody continued
the work.  For the sake of OSM, especially routing, please reopen it.
I don't claim that it is the good solution but I do claim we should work
on such a default database *in priority*.

I didn't analyze it in full depth, but I have the following remarks:
- Why not allow the def keyword in the border relation itself? But it
could be called zzdef to cluster at the key end.
- If a separate relation is preferred, it should be pointed at by a
"defaults" role in the corresponding border or other relations so that
it can be found.
- to ease scanning a border tree upwards, a "parent" relation should
exist in border relations.

In hope of a well structured OSM,

Cheers

André.




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

Re: [Tagging] Toll road sections

[André Pirard]

On 2017-08-28 18:42, marc marc wrote:
> Please avoid creating a new key like toll_ref
> All references refer to something, but we don't create road_ref, 
> shop_ref, hydrant_ref, building_ref, we just use "ref" key
> sometimes with a subname HU for the country (in capital)
> sometimes with another subname for the source name
>
> If you really want to add the word "toll",
> maybe something like ref:HU:toll:edid=123456
>
> Regards,
> Marc
It would obviously be  toll:ref:HU:edid=123456  then.
It's the ref of the toll, and not the toll of the ref.
ref is an attribute of toll and not toll an attribute of ref.
Qualifiers come to the right of qualified terms when using name spaces.

Strangely enough, when I advocate using name spaces like Marc does,
someone pops up and says: "you again? it's not the way we do it".
But he never said who "we" is.

Please use HTML when replying to HTML to avoid messes like below.

Cheers

André.



> Le 28. 08. 17 à 18:22, Jo a écrit :
>> I would use the following:
>>
>> toll=no
>> toll:hgv=yes
>> toll_ref:HU:edid=123456
>>
>> That's the easiest to query for later on.
>>
>> You can add contents to existing wiki pages.
>>
>> Polyglot
>>
>> 2017-08-28 16:35 GMT+02:00 Dömötör Ákos :
>>
>> Hi,
>>
>> I won't mess with the generic "toll" tag because some of the roads
>> are highways with tolls for all vehicle types so I'd leave them as
>> they are.
>> Naturally, I was already planning to add the "toll:hgv=yes" for each
>> road in question.
>>
>> Of the two proposed tags, "toll_ref=HU_edid_123456" seems to be more
>> specific than "ref:hu:edid=123456" so I'd prefer the first one.
>> However, creating an OSM Wiki page for a new tag (like "hu:edid") is
>> a clean issue. But where to put this information in case of "toll_ref"?
>>
>> Greets
>>
>>
>> Hi Ákos,
>>
>> I would do this : "toll=hgv_only" and "toll_ref=edid_123456" or
>> "toll_ref=HU_edid_123456"
>> (according to the wiki, it should not be toll=hgv_only but :
>> *toll*=no, *toll*:hgv
>> > >=yes)
>>
>> 2017-08-28 12:30 GMT+02:00 Topographe Fou
>> 
>> > >>:
>>
>>  I'm not aware of other toll systems but official country
>>  references are tagged using the prefix ref:XX where XX is the
>>  country code. Note that HU represent the country and hu the
>>  language (see ISO codes). So your prefix would be ref:HU.
>>
>>  LeTopographeFou
>>
>>Message original
>>  De: domotor.a...@itineris.hu
>> 
>> >
>>  Envoyé: 28 août 2017 11:51 AM
>>  À: tagging@openstreetmap.org
>> 
>> > >
>>  Répondre à: tagging@openstreetmap.org
>> 
>>  > >
>>  Objet: [Tagging] Toll road sections
>>
>>  Hi,
>>
>>  The road toll system for HGVs has sections in Hungary.
>> There are appr.
>>  2400 of such sections in a varying length from 100 metres
>> to 13 kms.
>>  We'd like to tag roads with the corresponding toll ID. The
>> base tag
>>  would be "edid" as the official files use this field name.
>>  The question is how we should use it. As it's only Hungarian, a
>>  "hu:" or
>>  "hu:ref:" namespace prefix may be appropriate.
>>  Furthermore, it's only for HGVs so inserting "hgv:" might be
>>  sensible as
>>  well.
>>
>>  Are there any other local toll systems that already use some
>>  tagging? We
>>  could use the same format/logic then.
>>
>>  Greets,
>>  Ákos
>>
>>  ___
>>  Tagging mailing list
>> Tagging@openstreetmap.org 
>> > >
>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>>  > >
>>  ___
>>  Tagging mailing list
>> Tagging@openstreetmap.org 

Re: [Tagging] [OSM-talk-be] Missing oneway:bicycle=no / Wiki editing

[André Pirard]

On 2017-05-10 21:08, Thilo Haug OSM wrote:
>
> Hi André,
>
> according to this documentation,
> the tagging mailing list is the wrong platform to address this  :
> "*If you have ideas for the wiki, you can generally just do them, by
> editing the wiki! *
> If you need any assistance the *wikiteam* are here to help."
> https://wiki.openstreetmap.org/wiki/Wiki#Wikiteam
>
Have you perchance seen the long and multiple discussions about
noexit=yes and similar subjects?
Yes, this place is exactly the one where to discuss that *tagging*
errors are made, what the wiki actually means, that it may be
misunderstood and that it should be clarified.

In this caseit seems clear to me that cycleway
<https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite* defines a
cycleway and some use it to tag a oneway exception.
And that oneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no is the
access tag defining the oneway exception, that it is sometimes omitted
and that like misusing any access tag it produces routing (GPS) errors.
Some uncommented people openly laugh at OSM routing globally; in
contrast, I say "change this if you want better routing" and I'm the one
being criticized.
The horror comes when someone said that a wiki article (he didn't show
which) deprecates oneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no and when the
very attractive map http://mijndev.openstreetmap.nl/%7Eligfietser/fiets/
introduces confusion.
I have no time to make corrections and improvements to every wiki topics
that need it and I hope that the persons who wrote them or acquaintances
will listen and do it.

For example, if I understood well, I'd recommend this or better:
cycleway
<https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite*indicates
the presence of a sort of cycleway called "cycle plug",  a very narrow
part of aoneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no way that
runs alongside it for cyclists to ride contraflow on.
Just that and not a long explanation of contraflow, making believe that
it's the subject, with a seemingly casual mention of "cycle plug" in the
end where one may have stopped reading. And oneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no is not
"normally" tagged with it but is the fundamental reason for choosing the
value "opposite" and hence mandatory.
And I suggest replacing other possible explanations of that subject
scattered in the wiki with a pointer to the one and only.

OSM and I thank you for your attention,
Cheers,

André.


> Unless some always ask for a proposal to edit /amend anything in the wiki.
> IMHO this leads to the result you mentioned :
> "Unfortunately, I'm very sorry to say, OSM is often much of a chaos."
> There seem to be very few people which first like to request a request
> form
> to be able to help the community to improve *.
>
> A "code of conduct"** would be helpful in which cases
> you may just add a minor specification, unfortunately I couldn't find
> such up to now.
>
> Cheers,
> Thilo
>
> * For those who don't know the concept of sarcasm :
> https://en.wikipedia.org/wiki/Sarcasm
>
> ** Certainly this will also leave some (border) cases which are
> disputable,
> but at least there would be SOME agreed guideline.
> https://en.wikipedia.org/wiki/Code_of_conduct
>
> Am 10.05.2017 um 15:10 schrieb André Pirard:
>> Hi,
>>
>> In this thread, I said, in agreement with others,
>> that oneway:bicycle
>> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no (click to
>> open that page) is the tag to be used *to tell routing
>> software**(GPS)* that *oneway*=yes
>> <https://wiki.openstreetmap.org/wiki/Key:oneway>does not apply to
>> bicycles
>> that cycleway
>> <https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite* has
>> noting to do with routing and contraflow but indicates that *there is
>> a cycleway* that *happens* to be "opposite".
>>
>> Could you please make the wiki documentation more clear about that?
>> Because mappers often believe that cycleway=opposite means to
>> indicate bicycle contraflow oneway:bicycle=no.
>> Unfortunately, sometimes contradictory sentences about the same
>> concept are often spread all over the wiki.
>> Find them all!
>>
>> I have written this script
>> <http://overpass-turbo.eu/?Q=%0A%5Bout%3Ajson%5D%5Btimeout%3A60%5D%3B%0A%2F%2F%20gather%20results%0A%28%0A%20%20%2F%2F%20query%20%0A%20way%5B%21%22oneway%3Abicycle%22%5D%5Bcycleway%7E%22opposite%22%5D%28%7B%7Bbbox%7D%7D%29%3B%0A%20%20%0A%29%3B%0A%2F%2F%20print%20results%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%2

Re: [Tagging] [OSM-talk-be] Missing oneway:bicycle=no

[André Pirard]

Hi,

In this thread, I said, in agreement with others,
that oneway:bicycle
=no (click to
open that page) is the tag to be used *to tell routing software**(GPS)*
that *oneway*=yes does
not apply to bicycles
that cycleway
=opposite* has noting
to do with routing and contraflow but indicates that *there is a
cycleway* that *happens* to be "opposite".

Could you please make the wiki documentation more clear about that?
Because mappers often believe that cycleway=oppositemeans to indicate
bicycle contraflow oneway:bicycle=no.
Unfortunately, sometimes contradictory sentences about the same concept
are often spread all over the wiki.
Find them all!

I have written this script

to find where many cycleway=opposite* exist without oneway:bicycle=no
and even without oneway=yes.

Look at this street  to
which GRi added cycleway=opposite without oneway:bicycle=no, to which
JanFi added oneway:bicycle=no  probably after reading this thread (thank
you!) and from which I removed cycleway=opposite because there is no
cycleway at all.

The worst of all is that the map
http://mijndev.openstreetmap.nl/%7Eligfietser/fiets/ shows
"cycleway=opposite or oneway:bicycle=no" ways, hence neither identifying
the cycleways  nor the contraflow correctly and not testing in its bugs
tag that cycleway=opposite must contain oneway:bicycle=no.
That is pitiful complete misinformation and the author did not even
reply to my message.

Unfortunately, I'm very sorry to say, OSM is often much of a chaos.

Hoping this will help,
Cheers

André.



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

Re: [Tagging] Feature Proposal - RFC - Language information for name

[André Pirard]

On 2017-05-05 13:51, Lukas Sommer wrote:
> Feature Proposal - RFC - Language information for name
>
> URL: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name
>
> Definition: Describes the language in which the value name=* is (using
> the same code as Multilingual names).
>
> Feel free to ask questions if things are unclear!
You say "This tag is not always necessary" which, as often in OSM, is
not really precise.
That means that if there is no name=* tag, the region's default
languages applies.
Alas, OSM seems to hate tagging default values inside its database.
Rather they are scattered in many other places and if one changes, all
applications have to be updated instead of a transparent OSM map update.
See the nice  Proposed features/Defaults
  that
they removed (even though it is used).
So, your proposal puts the cart before the horses and default languages
should be defined first.
If you want to do that, call on my advice on how to do it.
Here in Belgium, we have defined the linguistic regions relations.
But, owing to that OSM shortcoming, they are of course not used as defaults.

Cheers

André.


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

Re: [Tagging] Tagging detail on Rest Areas

[André Pirard]

On 2017-04-27 00:48, Warin wrote:
> Hi,
> I have come up with some detail tagging for rest areas but want to get
> some oversight on it and help with one aspect. 
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area
> Easy(?) Details
> Some of these have time limits - easy enough to use a conditional max
> stay tag
>  rest_area:condition:maxstay=20 
> Stops people 'camping' over a long period. 
>
> Restricted to HGV use only, use access tags 
>  access =no
>  with hgv 
> =yes
> 
> More difficult detail
> One I am having problems with, where they can be used for 'camping' with a 
> caravan/camper-van (but probably not a tent).
> rest_area:camping=caravan  
>
> or
>
> rest_area:camping:caravan=yes  
>
> would convey the meaning .. but is it a 'good' tag that would allow for other 
> things and follow other tagging methods? 
>
> caravan=yes could simply mean access and not convey the camping
> aspect? Note the max stay would still apply (if there).
>
>
> Any thoughts on tagging these features for rest areas?
>
>
Hi,

Your questions show that there is no OSM formal definition of the usage
of name space.
I once sketched one, a key of which is rules to make a canonical
representation of the tags.
It says that for the main tag (the one representing the object (vs
attributes))
highway=rest_area canonically means highway:rest_area=yes
and that attribute tags append to that.
So, your examples become
highway:rest_area:rest_area:camping=caravan
which in its canonical form is
highway:rest_area:rest_area:camping:caravan=yes
obviously, one rest_area is too much and it must be:
camping=caravan ==> highway:rest_area:camping:caravan=yes
camping:caravan=yes ==> highway:rest_area:camping:caravan=yes
same canonical representation but allowing other attributes of camping
than caravan.
camping=yes (attribute of rest_area) would mean that camping is allowed
caravan=yes (attribute of rest_area) would mean that the area can be
used by caravans
(but an access=* would be the normal way to do it)
camping=caravan=yes would mean that the caravans can be used for camping

I hope I made no mistake.

Well, it's risky writing this.
Someone may come down on me again to scold me and say : "we" do not do that.
Very logically not saying who is "we".
That's apparently not you.

BTW, a rest_area can be just some space beside a road.
It is not a parking but it can be used to momentarily stop out of the
traffic.
Right?

Cheers,

André.



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

Re: [Tagging] Language information for name=* (and defaults)

[André Pirard]

On 2017-04-23 17:18, Lukas Sommer wrote:
> Hello.
>
> There are many applications that use the name=* tag in OSM. You will
> usually use the name=* tag when you intentionally want to use the name
> in the default language. (Example: OSMand lets you optionally choose
> between “local names” or a specific language. And the default style at
> openstreetmap.org uses exclusivly name=* because it wants to use
> always the local names. They do intentionally not use localized tags
> like name:en, name:jp, name:de…)
It is not "intentionally" that OSM.org uses name=* but because they use
picture tiles that can contain only one name flavor.  Osmand, on the
contrary builds (renders) the display from the vector map and can do
what you suggest.
To do the same, OSM.org should, for example, use nameless tiles (I think
that they exist somewhere) and overlay the text at the client side (on
their computers) according to their wishes.
Many contributors usually simply reply "render the map yourself".
> The content of name=* is plain Unicode. Problem: This is not enough to
> render the text correctly. There are glyphs (character shapes) that
> are different in the four variants (japanese, traditional chinese,
> simplified chinese, korean) of the CJK script, but Unicode encodes
> them at the same codepoint. Also there are four variants of some
> cyrillic glyphs (russian, bulgarian, serbian, mazedonian) that are
> encoded at the same Unicode codepoint. In the web, this problem is
> easily solved: The HTML code contains a language tag that gives the
> necessary information about the language. So the Internet browser can
> display everything correctly. In OSM this information is missing.
>
> Deduce this information by the country in which our OSM element is
> located is not very reliably. Also within the same country may exist
> (much) more than only one language. It’s also error-prone. That’s not
> an option.
>
> Deduce this information by comparing with the other name:en, name:jp,
> name:de … tags does also not help. Example: The node
> http://www.openstreetmap.org/node/25248662 (english: Beijing) has
> name=北京市 and name:ja=北京市 and name:zh=北京市. They are identical. We
> cannot reliably determine the language of the name value. It would
> also not work for double-language names like “Bruxelles - Brussel”
> where none of the name:??=* tags has an identical value.
>
> I was thinking about a new tag that could give us the necessary
> language information for the “name” tag. Something like TAGNAME=es to
> express that the “name ” tag is in spanish…
Adding a tag to every name would be cumbersome.  It is a matter of
defaults. Any exception could be specifically tagged beside name=*. Not
not the short sighted so-called "by country defaults" but "by region
defaults".
But, obviously, OSM prefers defaults being encoded in dozens of external
files (like Nominatim now seems to use for the language of name=*)
rather than in its own database. Instead of discussing/improving the
excellent work in the (already used) Proposed features/Defaults
, they
sent it to the trash. That's typical OSM.
After discussing if the tag syntax is OK, one thing that could have been
improved is adding a role tag pointing to its defaults relation from any
relation that defines a region (if those tags are not coded in the
region relation already).
For the Belgian case, note that languages are not defined by
administrative relations but by political relations and that they could
be by not yet invented language relations.

Cheers

André.



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

Re: [Tagging] historic=tank and surprises with tags like car-sharing

[André Pirard]

On 2017-04-16 00:20, Michal Fabík wrote:
> Hi,
> I just mapped my third tank in about a month and I'm still wondering why it 
> isn't documented in the Wiki alongside historic=aircraft, historic=locomotive 
> etc. There's quite a few of them mapped already, according to Taginfo. One 
> could argue that tanks are more often than not parts of war memorials (like 
> here: 
> https://upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Starovi%C4%8Dky-pam%C3%A1tn%C3%ADktankov%C3%A9bitvy-1.JPG/1067px-Starovi%C4%8Dky-pam%C3%A1tn%C3%ADktankov%C3%A9bitvy-1.JPG)
>  so they don't have to be mapped as stand-alone objects, but this is not 
> always the case (today, I mapped a tank that's an open air museum exhibit, 
> the other day I saw one serving as a mascot of a military school). Is it 
> perhaps because the word "tank" can also mean a container for liquids? Maybe 
> we should use something like historic=armoured_vehicle?
> Regards,
For the nearby tanks, one is a historic=monument
 and the other a
tourism=attraction, attraction=tank
.
To me, tourism attraction sounds disrespectful for the men who died and
I prefer memorial=tank.
Usual OSM inconsistencies.
Other searches seem to show that "tank" is known around the world, so,
adding historic=tank or better memorial=tank is a +1 to me.
Else, it would be *=war_tank, but nobody would search for that.
And what's the problem with tank anyway, is there anything like a
historic liquid container anyway?

That problem is a mild one.
I asked how to tag posts where people wait for cars to pick them, both
subscribed to a system called fr:covoiturage=en:car-sharing.  Nobody
would answer.
So, I tagged them as car-sharing with a sub-tag indicating hike-sharing.
They were nicely showing on OSM.org and I showed samples to the organizers.
But in the meantime they had that rendering removed and I sounded like a
fool.
That's the way OSM goes. Your perfect tagging is turned to mistakes too
without warning.
And that's what's unhappily turning me away from OSM much.

Cheers

André.



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

Re: [Tagging] address property of features

[André Pirard]

On 2017-03-18 14:16, Martin Koppenhoefer wrote:
> if there's a whole building or area with one housenumber you can put
> the feature inside and it can inherit the address from the area,
There are two ways to tag multiple features (or a single one) of the
same building:

  * name space tags, but it's complicated, not well formalized, a number
of people don't like namespace although it's widely used and others
don't understand it well
  * use separate feature elements inside the buildings

I polled several people near me and separate features are by far preferred.
On the other hand, I'm tagging many buildings (very precisely) and very
often the features are already there and I tag the building around (or,
most often, I move the feature inside :-)).

I see it almost the same way as you, except that because a feature is
not an object (visible "on the ground" etc.) it is not normally allowed
to stand alone on OSM and it has to conceptually be merged with the
building so that the building inherits the features too to achieve the
same as method #1.

So, indeed, a feature can be tagged with the same street address as one
of the building, not only because it can be multiple on the building but
because, even with a single address, *someone listing the feature tags
will not see the address* and may well not think of finding it in the
building tags.

*So, the wiki should clearly state and Osmose should be notified that
forbidding to use the same address twice holds between buildings
(objects) and not between features (non objects) and other elements.*
The tags of the features are the tags of the object they belong to and,
BTW, having the same street address as the object is a good way to show
to which object (or entrance thereof) they belong.

Cheers

André.


> it seems like a good way to map, but in many cases this is not
> possible. In Italy in general, every entrance and even some potential
> entrances get their own number. Features on the ground floor can
> easily be accessible by several numbers (store fronts tend to get a
> number for each window), even 
> on different streets (if they're on a street corner). But often the
> shops only use some of these numbers (often their main entrance). It
> makes sense to add address information to those features (the address
> they use) rather or in addition to adding the address to the entrance
> (alternatively we could associate the entrance with a relation to the
> feature, but this seems less stable and more complicated for less
> experienced mappers).
>
> This practice isn't reflected by the current documentation of Addresses:
> https://wiki.openstreetmap.org/wiki/Addresses
>
> I would like to add it, but I'm unsure if this is Italy-specific or if
> we could recommend to map like this in general.
>
> What is your opinion?
>
> Cheers,
> Martin 
>
>
> sent from a phone
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Missing oneway:bicycle=no

[André Pirard]

  
  
I once read that routes of cyclists using OSM were laughed at by the
others...

oneway=yes is a routing
tag (used by GSM) indicating that only one way of the highway can be
used.
That page says that the exception for bicycles to run contraflow is
oneway:bicycle=no.
And that cycleway=opposite* is added
for compatibility.
Also, Key:cycleway says that oneway:bicycle=no.
must be used with cycleway=opposite.

All in all it makes much sense that only one oneway:bicycle=no
  routing tag be used to allow bicycle contraflow.
And that other tags like cycleway=* are not routing tags to be used
by routing software (GSM).
They are just tags giving more detail about how the bicycles run.
Why would a multitude of duplicating routing tags like detour:bicycle=yes
or shortcut:bicycle=yes be used Indeed?

Unfortunately, while writing an overpass script I noticed that many
cycleway=opposite* exist without oneway:bicycle=no and even
without _oneway_=yes.
Please
  run this script to find some of them.
I'm not going to give the nonOSM people I work with overly
complicated instructions.  I'm not going to make a complicated
script. To write it "for the errors".

Could we please correct those mistakes?

Cheers



  

  André.

  


  


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

Re: [Tagging] 'ongoing' U-turn restriction, plus side turns

[André Pirard]

On 2016-12-08 09:36, Volker Schmidt wrote:
> On 2016-12-08 03:09, André Pirard wrote:
>> On 2016-12-07 22:53, Martijn van Exel wrote:
>>> Hey all, 
>>>
>>> Apparently there are roads that have an 'ongoing' U-turn
>>> restriction, see the sign here for
>>> example: http://openstreetcam.org/details/10053/304 
>>>
>>> I know how to tag this for an intersection but not how to do it for
>>> an entire way where U-turns are prohibited.
>> The concept of a node where one cannot U-turn and where one could
>> U-turn 1 meter before it is a strange one.
>> In Belgium, signal C33
>> <http://www.code-de-la-route.be/textes-legaux/sections/ar/code-de-la-route/251-art68>
>> indicates that one cannot U-turn from the position of the signal up
>> to and including the next crossing.  It's obviously always in force
>> over a span of the highway, it indicates a one-way section and the
>> simplest way to indicate that is oneway=yes.
>
> This is interesting and closely related to the question how we tag, on
> two-way roads, continuous middle lines (or double continuous middle
> lines) that imply continuous stretches of road with "no-u-turn", no
> passing/overtaking, and "no-left-turn" (in countries with right-hand
> traffic).
> In addition there seems to be countries (I am not sure) where u-turns
> are generally forbidden on certain classes of roads.
> Why do we not use u_turn=no on highways, similar to the overtaking
> tag? I am also wondering why "overtaking" in reality is not frequently
> use either, worldwide only 40,000 tags.

I have taken permission to reintroduce the quote showing what's interesting.
And thank you for recalling a subject I once raised.
Those Belgian white lines preventing U-turn (without oneway) are
jurisdiction-dependent indeed as well said further.
I had abandoned the discussion, taking it as the usual "no" the answers
that it's not so everywhere.
But as said further too, what we map is not the color or form of the
lines but their meaning.

And what I mostly mentioned before, is that those Belgian lines not only
forbid U-turn,
but also turning left (in right-hand drive) when coming from a side road.
I find this important because it makes a lot of missing, difficult to
map turn relations unnecessary.
But I suppose it would have, because of jurisdiction-dependency, mapped
differently than U-turn.

Interesting discussion.

Cheers

André.



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

Re: [Tagging] 'ongoing' U-turn restriction

[André Pirard]

On 2016-12-07 22:53, Martijn van Exel wrote:
> Hey all, 
>
> Apparently there are roads that have an 'ongoing' U-turn restriction,
> see the sign here for example: http://openstreetcam.org/details/10053/304 
>
> I know how to tag this for an intersection but not how to do it for an
> entire way where U-turns are prohibited.
The concept of a node where one cannot U-turn and where one could U-turn
1 meter before it is a strange one.
In Belgium, signal C33

indicates that one cannot U-turn from the position of the signal up to
and including the next crossing.  It's obviously always in force over a
span of the highway, it indicates a one-way section and the simplest way
to indicate that is oneway=yes.

I find the road-signal-like tagging dangerous.
I have seen municipality limit tags that did not show on which side the
municipality is and that would be called redundant by someone disliking
that tagging.
I have seen give-way tags right in the middle of 3-way junctions. 
Really, what did the tagger have in mind?
Priority to the right?  i did not find tagging for this one.
Etc.

Cheers

André.


> Any guidance?
>
> Thanks,
> Martijn van Exel
> http://mvexel.github.io/
>

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

Re: [Tagging] Proper way to tag highways located in "dangerous" areas

[André Pirard]

  
  
On 2016-11-16 14:08, André Pirard
  wrote:


  
  

  2016-11-16 2:04 GMT+01:00 Nelson A.
de Oliveira <nao...@gmail.com>:

  Since

they can't find another tag to indicate those
"dangerous"
places, they argue that access=destination is valid for
this case.

Other group (including me) find that this is wrong: we
should not tag
streets considered dangerous in OSM (specially when
"dangerous" is
subjective).
We also think that access=destination is being wrongly
used for this.

Since we can't reach a consensus on this, we would like
to hear some
opinions and suggestions on how to handle such problem,
please.

  
  
  The "danger" you're talking about is otherwise called a
  "hazard".
  I have mentioned several times that a  Proposed features/hazard  exists that, IMHO,
  is very well done. But OSM doesn't seem to care about hazards,
  especially children related, except you and I and a few.
  That page needs some care, but, as things go, it can be
  removed in secret any time like  Relations/Proposed/Defaults  which,  maybe not
  in that form, is badly needed because it would put default
  values inside the OSM database instead of scattered
  everywhere.
  One should not remove a badly needed proposition, but mark it
  "don't use", "unsuitable', "to be reworked" ...
  I would have liked to tackle the job but I've had too many
  disappointments from the answers on these lists and my time is
  used by other hobbies.
  
  As to "access=destination", previous answers said alright that
  danger is not a legal matter.
  I personally don't think of that as legality but as
  instructions for routing, whether and how a GPS can use that
  road.
  access=* shouldn't be mixed with other considerations like it
  was done with access=dedicated.

  

Oops, I thought of saying but I forgot, that many non-access tags,
especially hazard, can be used for routers to prefer one route over
the other.  Unfortunately, supporting dangers to be killed by
robbers or so would need a "fearful" option for the mode of
transportation.
Don't laugh!  In my mind an itinerary could me made of different
segments using different modes.  And even with a single mode, I've
never seen a "crow" vehicle yielding an "as the crows fly" itinerary
which is that of a plane or of an orienteering adept, not counting
crows themselves.

  
 Only the length of the discussions it
  has generated is a proof of that.  Normal access=* rules are
  very clear cut.  But on the wiki, you can read that
  access=dedicated is meaningless in Belgium and on Belgian
  pages, the instructions are to use it.  Go figure.
  
  So, go and finalize  Proposed features/hazard, making sure they
  include what you think of.
  
  Cheers 
  
  

  
André.
  

  
  

  


  


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

Re: [Tagging] Proper way to tag highways located in "dangerous" areas

[André Pirard]

  
  

  
2016-11-16 2:04 GMT+01:00 Nelson A. de
  Oliveira :
  
Since
  they can't find another tag to indicate those "dangerous"
  places, they argue that access=destination is valid for
  this case.
  
  Other group (including me) find that this is wrong: we
  should not tag
  streets considered dangerous in OSM (specially when
  "dangerous" is
  subjective).
  We also think that access=destination is being wrongly
  used for this.
  
  Since we can't reach a consensus on this, we would like to
  hear some
  opinions and suggestions on how to handle such problem,
  please.
  


The "danger" you're talking about is otherwise called a
"hazard".
I have mentioned several times that a  Proposed features/hazard  exists that, IMHO, is
very well done. But OSM doesn't seem to care about hazards,
especially children related, except you and I and a few.
That page needs some care, but, as things go, it can be removed
in secret any time like  Relations/Proposed/Defaults  which,  maybe not
in that form, is badly needed because it would put default
values inside the OSM database instead of scattered everywhere.
One should not remove a badly needed proposition, but mark it
"don't use", "unsuitable', "to be reworked" ...
I would have liked to tackle the job but I've had too many
disappointments from the answers on these lists and my time is
used by other hobbies.

As to "access=destination", previous answers said alright that
danger is not a legal matter.
I personally don't think of that as legality but as instructions
for routing, whether and how a GPS can use that road.
access=* shouldn't be mixed with other considerations like it
was done with access=dedicated.
Only the length of the discussions it has generated is a proof
of that.  Normal access=* rules are very clear cut.  But on the
wiki, you can read that access=dedicated is meaningless in
Belgium and on Belgian pages, the instructions are to use it. 
Go figure.

So, go and finalize  Proposed features/hazard, making sure they
include what you think of.

Cheers



  

  André.

  



  

  


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

Re: [Tagging] mapping default values?

[André Pirard]

On 2016-10-05 11:00, Martin Koppenhoefer wrote:
>
> 2016-10-05 3:35 GMT+02:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>>:
>
> On 2016-09-27 11:43, Marc Gemis wrote:
>> Hallo,
>>
>> op 1/1/2017 daalt de snelheid op Vlaamse gewestwegen van 90 naar 70.
>> Normaal gezien zullen we die wegen (zonder expliciete borden) dan
>> moeten taggen met
>>
>> maxspeed=70
>> source:maxspeed=??:rural
>>
>> maar wat komt er op de plaats van de vraagtekens ? Volgens [1] staat
>> daar de landcode, maar het geldt enkel voor Vlaanderen.
>> Ik zou tegen dan de BENELUX presets willen aanpassen.
>>
>> -
>> English:
>>
>> On 1/1/2017 the maxspeeds on Flemish roads is lowered to 70. We should
>> map those roads (without signs) with
>>
>> maxspeed=70
>> source:maxpseed=??:rural
>>
>> Which "country" code should I use in the BENELUX plugin ? See [1] for
>> the syntax of maxspeed.
> I don't think that default values like maxspeed=*, 
> driving_side=*, or even oneway=no should be tagged on highways.
> Most roads (in Belgium and in the world) don't contain any, BTW,
> and it makes no sense using a few.
> A default values specification should be used instead.
> Those tags should be contained in the highest level administrative
> boundary relation or equivalent in which they apply.
> maxspeed=70 should apply to Flanders and maxspeed=90 to Wallonia.
>
>
> what you propose is not working, because speed limits are about roads,
> not administrative entities. You have to know the context (rural/urban
> inside settlement according to traffic law, etc.) in order to assign a
> maxspeed, and the only way we currently use to understand which
> context applies are the source:maxspeed values. It is very simple,
> doesn't require preprocessing, can be applied by everyone without
> looking for and downloading surrounding administrative polygons, and
> is also quite reliable. Why would we give this up?
Please don't remove important quotations.

What you are saying is that every road in the world should have a
maxspeed=*. driving_side=*, etc.
It's far from being the case.  Hurry up to do so.  Presently, GPSes
cannot deal with defaults.
What I am saying is that there should be in the Walloon/Flemish
administrative boundaries relations or so a tag saying
if zone is rural then maxspeed=90/70.
That is what "def:highway
<https://wiki.openstreetmap.org/wiki/Key:highway>=primary
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary>|highway
<https://wiki.openstreetmap.org/wiki/Key:highway>=secondary
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Dsecondary>;maxspeed
<https://wiki.openstreetmap.org/wiki/Maxspeed> = rural" does in
Relations/Proposed/Defaults
<https://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults>.
Instead of destroying propositions again please propose improvements.
I think that this proposition is sound but I don' agree with the too
complicated details of it.
Yes, default speed limit rules are about administrative entities for
someone who understands what Flemish and Walloon mean.
No, GPS dealing with administrative polygons is not complicated as they
keep saying on and on.
It would even be simple with subareas but that's another subject.
No tagging default maxspeed everywhere is not reliable because it
depends on many tags being correct instead of a few.
As to using signals, that's the worst idea.  They are valid up to the
next crossing, but not a private road, and they must be repeated.
Indicating which direction they apply to is tricky and a source of
error. The few  signals I looked at were municipality limits. They were
redundant with boundaries (a disparaged feature) and they did not mind
indicating on which side of the signal was the indicated municipality.
Imagine that with speed limits and you get the picture.

Cheers

André.



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

Re: [Tagging] mapping default values? (was: Maximum snelheid in Vlaanderen, maxspeed in Flanders)

[André Pirard]

On 2016-09-27 11:43, Marc Gemis wrote:
> Hallo,
>
> op 1/1/2017 daalt de snelheid op Vlaamse gewestwegen van 90 naar 70.
> Normaal gezien zullen we die wegen (zonder expliciete borden) dan
> moeten taggen met
>
> maxspeed=70
> source:maxspeed=??:rural
>
> maar wat komt er op de plaats van de vraagtekens ? Volgens [1] staat
> daar de landcode, maar het geldt enkel voor Vlaanderen.
> Ik zou tegen dan de BENELUX presets willen aanpassen.
>
> -
> English:
>
> On 1/1/2017 the maxspeeds on Flemish roads is lowered to 70. We should
> map those roads (without signs) with
>
> maxspeed=70
> source:maxpseed=??:rural
>
> Which "country" code should I use in the BENELUX plugin ? See [1] for
> the syntax of maxspeed.
Note to "foreigners" (as Americans would call you):
Belgium is made of Flanders and Wallonia: Flanders steps down to 70 km/h
default while Wallonia stays at 90.

I don't think that default values like maxspeed=*,  driving_side=*, or
even oneway=no should be tagged on highways.
Most roads (in Belgium and in the world) don't contain any, BTW, and it
makes no sense using a few.
A default values specification should be used instead.
Those tags should be contained in the highest level administrative
boundary relation or equivalent in which they apply.
maxspeed=70 should apply to Flanders and maxspeed=90 to Wallonia.
Please note this (fuzzy again) sentence about driving_side=* : "Only add
it to a highway when it's driving side is an exception to the general
rule (and check that the general rule is tagged in your country
relation)." (they mean "its" driving side).
Which relation?  It's certainly not tagged in the Belgian boundary
 and not even in the
duplicate place .
So, a default value procedure is badly needed but is not implemented and
when a hacked fuzzy lookalike is documented, it is not used.

Cheers

André.


> regards
>
> m
>
>
> p.s. Ruben, please let me know which preset you want for variable
> maxspeeds. I'll add it when I change the above.
>
>
> [1] https://wiki.openstreetmap.org/wiki/Key:source:maxspeed
>
> ___
> Talk-be mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [Tagging] Routing in Liège (consulting Michelin)

[André Pirard]

On 2016-09-17 20:46, Richard Fairhurst wrote:
> André Pirard wrote:
>> Last point is what source:???=Michelin ??? to use to prevent a 
>> StijnRR or like arbitrarily destructing well thought out tagging 
>> without notifying the author. I suggest
>> source:highway=https://viamichelin.be/web/Cartes-plans 2016 2016.
> No, you must not copy from copyrighted maps, which includes Michelin's.
>
> Please confirm that you have not added, and are not going to add, any data
> (including classification judgements) from Michelin maps, otherwise I guess
> we'll have to ask the Data Working Group to suspend your OSM account and
> revert your edits.
>
> Richard
Of course not, I did not use that Michelin map as a source and I won't.
It would be stupid because it's coarse compared to other allowed sources.
And everything of it and much more is in OSM already.
Even a road classification does not interestingly exist in it (1).
This Subject: and suggested source= are inappropriate and misleading.

The only thing I did is to notice that Michelin runs the N3 in red from
Ans to La Dérivation, compare it to my turbopass map, discover that OSM
has a gap in this primary and post the URLs of a few streets containing
ref=N3 and highway=secondary.  You have read that, haven't you, I posted
their URLs in this thread.
Now if I hope that you won't say that this is copying from Michelin and
that you would send to prison someone who would correct those mistakes
and that you would put the mistakes back in OSM.

I have been *extremely* shocked by what you said after my attempt to help.

Beside mapping the boundaries of South Belgium and other major works, I
have done excellent mapping, I very often correct a huge number of
houses and roads, almost all, misplaced by 3-5-+ meters, I help mappers,
I even help JOSM and others to improve their software for a better OSM.
Revert my edits? 
Remove the Walloon borders?  Remove the other many things? Remove my
humanitarian tagging?  Put houses and roads back to the wrong place?  etc...
Very rarely a word of thanks, except Marc in this thread, close friends,
some developers and the humanitarians.
Always reproaches and destruction.
Even the DWG vandals messed up the marvelous job of the boundaries of
Wallonia.

That total lack of consideration for what I'm doing made me decide to
stop contributing to OSM.

André.


(1) On that map, Michelin unhelpfully draws the equivalents of both
OSM's secondary and tertiary in yellow.
Tertiary can't be distinguished from secondary.
The only thing that can be done with it is to build a route to compare
with an OSM and so to have hints to modify the  OSM route.
This said, I tried on Michelin the route Beaufays-Oupeye that I know well.
Definitely, their route #2 27 km via E25 is much better than their
recommended #1 26 km via E40.
And within #2, Bd de Douai -> Poincaré is better than quai des Ardennes,
it is even the signposted route!
So, Michelin is not even always a good adviser!

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

[Tagging] using Michelin's road classification (was: Routing in Liège)

[André Pirard]

Hi Marc,

Could you please forward/translate this reply to Michael and anyone who
believe that Liège (and other places?) contain main road classification
errors that produce bad routing.  One-way streets and the like will be
another subject.
I suggested below to compare the OSM classification with that of Michelin.
Martin Koppenhoefer replied down below that Michael is wrong because
"we" (they) "do more or less like Michelin". But he doesn't say if it is
more or less and how much.
He asks "Where do you see differences?", meaning that he did not try to
find them.

Consequently, I have made my own Michelin compatible overpass query
<http://overpass-turbo.eu/?q=CltvdXQ6anNvbl1bdGltZcSCxIQ2MF07Ci8vIGdhdGhlciByZXN1bHRzCigKICDElyBxdcSeeSDEqiB3YXlbImhpZ2jEtnkiPSJtb3RvcsS_Il0oe3tiYm94fX0pxJXEq8S_xLnEu8S9xYnFgnByxI1hcsWAxYvFjcWPxZHFk8WVxLTFl8S3xZnEvMS-xLfFgSJzZWPEiGTFocWjxYzFjsWQxZLFlMSVxLTFmMS6xa7FnCJ0xJ7EjMW4xYrFusWmxb3FqcWrxLjGgsWbxbDFgnVuY2xhc3NpZmllZMaKxaXFvMWoxZbEtcWsxpHFr8WAxYLEocabZGVuxohsxqHFu8Wnxb7EtArFqcStxZ5pxrDEoMSixKTEpgrEkCDFkGR5xJU-xJXHg3NrZWzErnTFv8WNc3R5bGU6CsSWKkRlZmHHgCDFs3TEjG5ncyBmxYfGpnlzKi8KxL8ge8S0b3BhY2nHlTowLjXGpXdpZMScOjPGpcW1bMWHOmJsxLDGpX3HmsWYxZrGqT3FhMWGxYjEt13Hs8Wqx7bHuMe6ece8LjnIgMiCyIQ0yIdvyIlyOsShZMiPyJHFrMiTxL89xrttxbjImse0xKsgyJ3Huce7x73Io8aAyKVoOsinxLTIiMiKyK3Ir8exyLHGg8S3PcWzxbVuxbfFosi4yJzHt8i9yKDIv8ikyIPJg8mFxKvJh8ireceOyIl3yYrIksmNeT3GhnLGiMmUyJvIusi8yJ_IocmAxZfJgsmEyKjIqjrJomzJpMmmyYzGksmpxqzIgsavxrHJlcmwyZfJssmayYHJnMm3yYbIqciKZ8Shx4fEtMiQx5rHm0jFrmzFrnQgxJxlIMe4xIx2yp_HsmFmyasgxpdpY2vGvGfHr8mLyKDKoWnKo8mvxKvJsci-yKLJm8iEOMm4yYjGn8mKCsWT=BL83OJVENO>
(thanks to the author of the original) that is using the same colors as
Michelin (1).

At *very first (short) sight*, I am surprised that Martin did not spot
that the ref=N3 road that's going north-west is primary (in red) mostly
but is interrupted by secondary segments (in yellow) Rue de Hesbaye
<http://www.openstreetmap.org/way/301189193#map=17/50.64889/5.55263> and
Rue Eugène Houdret <http://www.openstreetmap.org/way/237917909>.  As
well as in Rue Louis Jamme
<http://www.openstreetmap.org/way/368855374#map=18/50.63813/5.58499> to
connect Place Delcour <http://www.openstreetmap.org/way/28611081> to
primary N90 <http://www.openstreetmap.org/way/28659889> and primary N610
<http://www.openstreetmap.org/way/368855373> (2). N610 should in theory
be secondary but I completely agree with Michelin to make it debatable
and make it primary like the Namur road should.

I did not investigate further (I'm short sighted indeed) but I suggest
that anyone contesting an OSM route compared it with the same routing by
Michelin, tried to find an explanation by comparing my overpass
<http://overpass-turbo.eu/?q=CltvdXQ6anNvbl1bdGltZcSCxIQ2MF07Ci8vIGdhdGhlciByZXN1bHRzCigKICDElyBxdcSeeSDEqiB3YXlbImhpZ2jEtnkiPSJtb3RvcsS_Il0oe3tiYm94fX0pxJXEq8S_xLnEu8S9xYnFgnByxI1hcsWAxYvFjcWPxZHFk8WVxLTFl8S3xZnEvMS-xLfFgSJzZWPEiGTFocWjxYzFjsWQxZLFlMSVxLTFmMS6xa7FnCJ0xJ7EjMW4xYrFusWmxb3FqcWrxLjGgsWbxbDFgnVuY2xhc3NpZmllZMaKxaXFvMWoxZbEtcWsxpHFr8WAxYLEocabZGVuxohsxqHFu8Wnxb7EtArFqcStxZ5pxrDEoMSixKTEpgrEkCDFkGR5xJU-xJXHg3NrZWzErnTFv8WNc3R5bGU6CsSWKkRlZmHHgCDFs3TEjG5ncyBmxYfGpnlzKi8KxL8ge8S0b3BhY2nHlTowLjXGpXdpZMScOjPGpcW1bMWHOmJsxLDGpX3HmsWYxZrGqT3FhMWGxYjEt13Hs8Wqx7bHuMe6ece8LjnIgMiCyIQ0yIdvyIlyOsShZMiPyJHFrMiTxL89xrttxbjImse0xKsgyJ3Huce7x73Io8aAyKVoOsinxLTIiMiKyK3Ir8exyLHGg8S3PcWzxbVuxbfFosi4yJzHt8i9yKDIv8ikyIPJg8mFxKvJh8ireceOyIl3yYrIksmNeT3GhnLGiMmUyJvIusi8yJ_IocmAxZfJgsmEyKjIqjrJomzJpMmmyYzGksmpxqzIgsavxrHJlcmwyZfJssmayYHJnMm3yYbIqciKZ8Shx4fEtMiQx5rHm0jFrmzFrnQgxJxlIMe4xIx2yp_HsmFmyasgxpdpY2vGvGfHr8mLyKDKoWnKo8mvxKvJsci-yKLJm8iEOMm4yYjGn8mKCsWT=BL83OJVENO>
with the Michelin map
<https://fr.viamichelin.be/web/Cartes-plans/Carte_plan-Liege-_-Liege-Belgique?>
(my "Michelin info" message helps the wise JOSM users too), and asked
people with local knowledge if they know better than Michelin.

Last point is what source:???=Michelin ??? to use to prevent a StijnRR
or like arbitrarily destructing well thought out tagging without
notifying the author. I suggest
source:highway=https://viamichelin.be/web/Cartes-plans 2016 2016.

Kéne afêre à Lîdje and I hope that this work will be useful elsewhere too,

Cheers

André.


(1) As white would not fit for residential, I used grey.  I'm surprised
indeed that no unclassified roads turn up in blue but that doesn't
affect routing.
(2) why the heck do those people adore splitting?

On 2016-09-15 17:02, André Pirard wrote:
> On 2016-09-13 18:21, Marc Gemis wrote:
>> Hallo,
>>
>> I was contacted by a mapper from Germany with whom I worked on turn:lanes.
>> He has to following question, can someone with local knowledge inform
>> us about the road classifications ? I have the impression a lot of
>> streets are indeed residential. Feel free to reply in French, I'll
>> translate it to English for him.

[Tagging] Michelin info

[André Pirard]

*Reply* to this message *privately* to receive info about how to easily
compare OSM with the Via Michelin map using JOSM.

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

[Tagging] using Michelin's road classification (was: Routing in Liège)

[André Pirard]

On 2016-09-13 18:21, Marc Gemis wrote:
> Hallo,
>
> I was contacted by a mapper from Germany with whom I worked on turn:lanes.
> He has to following question, can someone with local knowledge inform
> us about the road classifications ? I have the impression a lot of
> streets are indeed residential. Feel free to reply in French, I'll
> translate it to English for him.
>
>
> [snipped]
> Now I want ask you about another problem.
> Coming from here
> http://forum.mapfactor.com/discussion/comment/13515#Comment_13515
> I checked Liege to find out the mapping of roads there:
> http://overpass-turbo.eu/s/imn
> My guess is, that unclassified is used wrong there and that is the
> reason for strange routings. My opinion is that unclassified as the
> lowest kind of connecting roads do not end at city borders and have or
> need common connection to same or higher class inside of towns or
> villages. For me routers should avoid residentials and lower as much
> as possible. Do you have any idea to check and correct this in Liege
> to make routing better?
>
> If there are any questions, please ask.
>
> Regards
> Michael aka hurdygurdyman
In order to produce good routing using the *main* roads (1), ...
why not adopt in OSM the same classification as Michelin

(2)?
They should know something about routing, shouldn't they?

Michelin



BE ID/type
Nxx
Nxxx
other
many houses
rare houses
OSM
primary
secondary
tertiary
residential
unclassified


Inside town, the main advantage is that streets are then classified as
either secondary/tertiary or residential/unclassified
according to whether they should be used or not for routes from town
place to place.
Please note that when a street is promoted to tertiary status, the fact
that it contains houses gets disregarded
(and hence I wonder if it's a good idea to consider houses  for road
classification rather than using an additional residential attribute
(yes, I know it's the way "we" do it)).

I am willing to explain JOSM users how to compare OSM and Michelin easily.
Please send me a *private **reply* to the next message "Michelin info"
to get it.
I would do a part of Liège myself if it's organized by someone
distributing the tasks.

Cheers

André.


(1) several de-contributors claim loudly that OSM routing is an every
contributors' hoax; I tend to agree with them for routing finer than
main roads given the complexity of making a no-turn relation, the
general misunderstanding of access restriction rules ("bicycle=yes"
alone), etc.; but I hate the "we don't do it like that" answers without
any constructive remark towards my goal when I suggest improvements. 
The "dedicated" subject alone makes whole chapters just because the
"dedicated" concept is not an (already existing) access restriction but
a reason for one ("but "we" do it like that").

(2) I suppose that Michelin doesn't mind just that since they updated
OSM themselves in their 2012 experiment
.


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

Re: [Tagging] bus route with reversing

[André Pirard]

On 2016-09-02 22:20, Svavar Kjarrval wrote:
> On fös 2.sep 2016 14:07, André Pirard wrote:
>> On 2016-09-02 15:19, Jo wrote:
>>> The way I understand this, no explicit tagging is needed. You could have
>>>
>>> aBBc
>>>
>>> Where c is the service way of the terminal.
>> I think that, just like within a plain highway, using the same node
>> (B) twice in succession makes no sense.
>> I bet that JOSM won't be happy about it.
>>
>  JOSM doesn't allow the user to add any repeats at all. Fortunately, it
> doesn't remove repeats which were already there.
I was showing nodes and Jo is showing ways.
Repeating nodes is not allowed but repeating ways is all-right.

Cheers

André.



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

Re: [Tagging] bus route with reversing

[André Pirard]

On 2016-09-02 15:19, Jo wrote:
> The way I understand this, no explicit tagging is needed. You could have
>
> aBBc
>
> Where c is the service way of the terminal.
I think that, just like within a plain highway, using the same node (B)
twice in succession makes no sense.
I bet that JOSM won't be happy about it.

Cheers

André.


>
> Polyglot
>
> 2016-09-02 14:13 GMT+02:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>>:
>
> On 2016-09-02 11:43, Michael Tsang wrote:
>> Hi all,
>>
>> I am mapping bus routes in my city. There is a route where the buses 
>> need 
>> reversing in order to enter the bus terminus. Is there a "standard" role 
>> in 
>> the route relation which denotes that the bus is to reverse through that 
>> segment of the road?
>>
>> Michael
> Hi,
>
> Supposing that the bus passes the T(erminus) point, goes to the
> E(nd) point and comes back to T(erminus) point,
> your relation will simply contain  .abcTET
> The other relation that describes the return journey will probably
> contain only Tcba...
>
> Cheers
>
> André.
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> <https://lists.openstreetmap.org/listinfo/tagging>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] bus route with reversing

[André Pirard]

On 2016-09-02 11:43, Michael Tsang wrote:
> Hi all,
>
> I am mapping bus routes in my city. There is a route where the buses need 
> reversing in order to enter the bus terminus. Is there a "standard" role in 
> the route relation which denotes that the bus is to reverse through that 
> segment of the road?
>
> Michael
Hi,

Supposing that the bus passes the T(erminus) point, goes to the E(nd)
point and comes back to T(erminus) point,
your relation will simply contain  .abcTET
The other relation that describes the return journey will probably
contain only Tcba...

Cheers

André.



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

Re: [Tagging] Multiple values for one key - the cuisine problem.

[André Pirard]

On 2016-08-24 22:06, Marc Zoutendijk wrote:
> How to tag multiple values for a key? The cuisine problem.
>
> Whenever we tag a restaurant, we also have the option of tagging the 
> kind/style of food that is offered:
>
> amenity=restaurant
> cuisine=french
> ...
BTW, the correct English spelling is

cuisine=French

I saw that the OSM people are very picky about correct spelling.

Cheers
Cordialement,

André.



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

Re: [Tagging] [OSM-talk-be] OSM in French and Dutch [or any monolingual]

[André Pirard]

On 2016-08-11 23:59, Ruben Maes wrote:
> On donderdag 11 augustus 2016 18:26 André Pirard wrote:
>> (...)
>> OSM.org displays the names according to the Language preference of the
>> browser (1).
>> Precisely, it displays a name in the first language of that preference
>> that matches one in the map.
>> Else, it displays the common default name.
>> E. g. if the preference is fr,ru :
>> if name:fr exists, display it, else if name:ru exists, display it, else
>> display name.
>> (...)
> I don't know where you get this, but it is completely false.
> For what you say to be possible, there would have to be separate tiles for 
> every language. That's not the case, everyone gets 
> https://{a,b,c}.tile.openstreetmap.org/{zoomlevel}/{}/{}.png.

What I said is in fact how OSM.org display names in the Nominatim search
left pane.

What Joost is asking, "a rendering of OSM in Dutch and French" ("or", I
suppose)
can be done by overlaying a nameless background and names foreground
like this example for Liège and Russian:

http://c.tile.openstreetmap.de:8002/tiles/1.0.0/bg//11/1055/688.png
http://c.tile.openstreetmap.de:8002/tiles/1.0.0/labels/ru/11/1055/688.png
http://c.tile.openstreetmap.de:8002/tiles/1.0.0/labels/ru,_/11/1055/688.png

The foreground overlay could be rendered in text mode for speed.

Cheers

André.



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

Re: [Tagging] OSM in French and Dutch [or any monolingual]

[André Pirard]

On 2016-08-09 11:37, joost schouppe wrote:
> Hi,
>
> Someone asked on Twitter about a rendering of OSM in Dutch and French
> to avoid the clutter of bilingual names in the standard rendering.
>
> https://twitter.com/iciBrussels/status/762743820358418432
>
> The French render is easy, OSM France provides it. But how about a
> Dutch rendering? Do you know of one?
>
> It might be cool to create a little webmap on OSM.be with the three
> official languages. If you help me find a Dutch rendering, I can make
> that (I've just learned the basics about leaflet).
>
> It looks rather easy to make a style with mapbox, but you need to
> extract the data through Overpass for exotic languages like Dutch, so
> it would be a bit of a job to keep that up to date.
I don't understand exactly what the problem is.
OSM.org displays the names according to the Language preference of the
browser (1).
Precisely, it displays a name in the first language of that preference
that matches one in the map.
Else, it displays the common default name.
E. g. if the preference is fr,ru :
if name:fr exists, display it, else if name:ru exists, display it, else
display name.
Hence, to reliably display Dutch, the preference must be nl,... and
name:nl must exist.
Or name=* must be in Dutch, but see gotcha.
That is a gotcha, of course.  If name=French_name has been coded and a
good soul adds mane:ru=России_имя, the fr,ru French speaker accepting
Russian will see the Russian name.  When adding name:ru=*, name:fr=*
must also be added.
This is especially strange in a region like Brussels.
The law says that the names must be written in both fr and nl.
But no Belgian sees that because their preference uses fr or nl.  Only
foreigners do.

So, what could be improved is

  * a = in the OSM.org URL to force the preference and do
without (1)
  o assuming a name:ll=* tag equal to name=* where ll is the only
language of the names
  o or running a bot to add the name:ll=* names automatically

Cheers

André.


(1) or the simulation of the browser's preference as Ben noted
On 2016-08-09 16:31, Ben Laenen wrote:
> On Tuesday 09 August 2016 11:37:58 joost schouppe wrote:
>> Someone asked on Twitter about a rendering of OSM in Dutch and French
>> to avoid the clutter of bilingual names in the standard rendering. 
> How about this one: http://mlm.jochentopf.com/ Fill in "nl" or "fr" in
> the box to get the names rendered in those languages
> Ben

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

Re: [Tagging] Which access tag for school buses?

[André Pirard]

  
  
On 2016-04-26 12:11, Martin
  Koppenhoefer wrote:


  
  

sent from a phone
  
Il giorno 26 apr 2016, alle ore 11:51, Volker Schmidt 
ha scritto:

  
  
My tagging would be 

tourist_bus=no
  (no private busses)

bus=no (no
  public transport buses)

school_bus=yes

  
  
  
  
  
  +1
  
  
  

  But "school_bus" is  used only a few
times. The only thing I found is 
http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5,
which proposes "school" as access tag for this, but this is
not good either, as it may be interpreted as including
private cars that carry children to school


  
  
  
  +1, "school" is too generic, there isn't even a relation to
access (could be used for school types etc.)
  


In my mind it should be
access:bus:school=*
because the namespace based structured approach would lead all
taggers to build tags the same way naturally, without asking any
such questions questions and replying +-1.
But I quit the idea after reading remarks such that the second word
shouldn't be the determinant. Here, "bus" determines what kind of
access it is and "school" determines what kind of "bus" it is. Some
would have made it school:bus which is incoherent (preventing access
to the schools that are buses) (1).
I had written a whole set of strict rules to propose and it's in the
trash.

Cheers



  

  André.

  


(1) OSM is unfortunately a place where you read an article about
namespaces that does not specify the order of the names and tags
such as "source=survey" that do not define what a survey is (my best
notion of it is an e-mail questionnaire I reply to).

  


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

Re: [Tagging] Rue réservée aux jeux - play street

[André Pirard]

On 2015-08-13 00:00, Jo wrote:
> Since this is only a temporary restriction, lasting 1 day in a whole
> year, or for a very few streets 4 weekend days during a holidays
> month, it hadn't occurred to me to try and map these.
If you look at my example, you will see that it's not lasting 1 day in a
whole year but every day during 2 months of it, most of the day, and
it's not in a very few streets but, according to here (sorry for a
stupid PDF)
<http://www.sprimont.be/commune/sprimont-infos/sprimont-info-pdf/sprimont-infos-aout-2014>,

> "rue Victor For
> -
> thomme (entre la rue du Hollu et la rue des Comines), rue
> des Hadrènes, rue de la Baligaine, rue de Gyppe (tronçon),
> Chemin des Goffes, rue de la Fontaine, rue d’Adzeux (tron
> -
> çon), rue Jean Doinet, rue Haie des Pauvres, rue Del Wède,
> rue Houreuse, rue de Wachiboux (tronçon), rue El Bedire"

That makes most of the streets in a village except the two main roads.

The deep question is: would it be useful?  Would it be visible on a map
(1)? Would Osmand detect that a destination is unreachable at the
calculated time of arrival and advise to start the journey ½h sooner or
later? 
Or are time conditional restrictions a loss of mapping time?

(1) that for example shows paths where pedestrians can go but not road
crossings where they must go

Cheers

André.


> It's a bit like roadworks that don't go on for months.
>
> Polyglot
>
> 2015-08-12 19:16 GMT+02:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> What are the tags for this?
>
>
> Article 22septies. Circulation dans les rues réservées au
> jeu
> 
> <http://www.code-de-la-route.be/textes-legaux/sections/ar/code-de-la-route/186-art22septies>
>  
> (en
> 
> <http://translate.google.be/translate?u=http%3A//www.code-de-la-route.be/textes-legaux/sections/ar/code-de-la-route/186-art22septies=fr=auto%7Cen=1=UTF-8>)
>
> *9.2bis. Signal C3 avec le panneau additionnel " rue réservée au
> jeu *
> 
> <http://www.code-de-la-route.be/textes-legaux/sections/am/am-111076/864-hs2art9#9.2bis>
>  
> (*en
> 
> <http://translate.google.be/translate?u=http%3A//www.code-de-la-route.be/textes-legaux/sections/am/am-111076/864-hs2art9%239.2bis=fr=auto%7Cen=1=UTF-8>*)
>
> access:conditional=no@opening_hours=Jul-Aug: 08:00-20:00
> bicycle=yes
> motor_vehicle=???
>
> Only access=no has time limits, outside which any permission is
> redundant.
> OK so far?
>
> But I can't find a permission tag allowing motor vehicles of local
> residents.
>
> ???
> is not /*destination*/ which is not a permission and is granted to
> anybody
> is not /*private*/ or /*permissive*/ which is not a permission and
> is granted by the owner
> shouldn't /*local_resident*/ be added to that list?
>
> But how can I have one such tag act as a permission during the
> restriction period without being a restriction itself outside the
> period?  By can, I mean simply, readably.
>
> André.
>
>

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

Re: [Tagging] boundary relations and the subarea property

[André Pirard]

On 2015-11-27 10:06, Martin Koppenhoefer wrote :
>
> 2015-11-26 21:12 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>>:
>
> It is even mandatory when you have to make nested boundaries that
> have no admin_level like the two boundary systems we have in
> Belgium (political and linguistic).
>
>
> can you give an example how this is modeled, e.g. a relation in osm?
> Having 2 kind of different boundary systems at first glance seems to
> be best modeled with 2 kind of boundary types in OSM.



The boundary system we have in Belgium (that you mention).
Any other language partitioning of a country.
The ceremonial counties case.
...

Cheers

André.



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

Re: [Tagging] boundary relations and the subarea property

[André Pirard]

On 2015-11-27 10:04, Martin Koppenhoefer wrote :
>
> 2015-11-26 20:24 GMT+01:00 Colin Smale  >:
>
> I use the subarea member because it makes cross-checking easy.
> Have all the lower-level boundaries in my higher-level admin area
> been added to OSM?
>
>
> what comes next? Have all the roads in a given administrative area
> listed with an "administrates" role in the relation? Cross-checking to
> me sounds like unhealthy redundancy here. It means having to do the
> work twice and having the information stored double.

Redundancy???  Have you noticed that some borderlines are *hexaplicated*
(that they appear in 6 different relations) and that *that* is unhealthy
redundancy that is made unnecessary by subareas?

And that, unlike wanting to destroy an enemy, the programs I spoke of
would be a great help building and checking the boundary ways mess using
the non duplicated, simple, clean UK=England+Wales+Scotland subarea
definitions?

> Unfortunately the various admin levels do not always form a strict
> hierarchy. A small area at (lets say) admin_level=10 might be
> enclosed spatially by entities at level 8, 7, 6, 5 etc but it only
> has a direct administrative relationship with one of them, which
> might not be the next-highest level (next-lower number).
>
>
>
> in which way does a subarea role help here to solve real problems?
> Which administrative aspects/powers/relationships/fields are those
> that are looked at? Do you have concrete examples?
Read the messages and look at OSM.org.

Cheers

André.



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

Re: [Tagging] boundary relations and the subarea property

[André Pirard]

On 2015-11-27 22:16, Georg Feddern wrote :
> Am 27.11.2015 um 15:46 schrieb André Pirard:
>> Have you noticed that some borderlines are *hexaplicated* (that they
>> appear in 6 different relations) and that *that* is unhealthy
>> redundancy that is made unnecessary by subareas?
>>
>> And that, unlike wanting to destroy an enemy, the programs I spoke of
>> would be a great help building and checking the boundary ways mess
>> using the non duplicated, simple, clean UK=England+Wales+Scotland
>> subarea definitions?
>
> Well, next usecase then:
> I want the border/outline of any of those entities ... and not the area.
> Mostly there are two sides of a view - or two views on one problem ...
An area is defined with its border.
Read a previous subarea thread where I explain how the borders can be
recursively, automatically computed from the level below but that it's
good to keep them at each level, but as a trouble-free and error-free cache.

Cheers

André.



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

Re: [Tagging] boundary relations and the subarea property

[André Pirard]

On 2015-11-27 13:13, Martin Koppenhoefer wrote :
>
> 2015-11-27 12:02 GMT+01:00 Colin Smale  >:
>
> One concrete use case is "return the boundary relations for the
> constituent parts of a given boundary relation", for example "all
> the district councils in Kent" 
>
>
> you can do this with overpass API (if all boundaries are mapped). Of
> course you should not rely on rectangular bounding boxes but use the
> Kent-area/border for this.
>
???
For the overpass API to work, you need to connect your GPS to the Internet.
For a GPS to do that with subareas, just a few, lightning fast program
instructions are needed.
Bboxes?  Borders? In what way are they necessary to answer Colin's question:
UK=England+Wales+Scotland
 (+Ireland).
???

Cheers

André.




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

Re: [Tagging] boundary relations and the subarea property

[André Pirard]

  
  
On 2015-11-26 20:08, Marcos Oliveira
  wrote :


  It's an handy and intuitive way of organizing
boundaries in a neat hierarchy visible from the database itself.

It is even mandatory when you have to make nested boundaries that
have no admin_level like the two boundary systems we have in Belgium
(political and linguistic).  I don't think that the Belgian
government would appreciate Martin's idea to move the Belgian
boundaries to a talk page where we would discuss that with the
Swiss, the USA (Spanish and even French) and the other multilingual
countries.
Or when you want to make simply an admin_level depend not on the
upper one but on one higher like Brussels is and like someone wanted
to do for Munich if I recall well.
They are visually very easy to verify and there can be a very simple
program to use them to check the boundary ways nightmare and even to
create them. It's a bad idea to say they're redundant. (I almost
wrote that program but I lost that page of code).  Place=* and their
tags are redundant with boundary=administrative relations and  they
are much much less useful than subareas.
When we were creating the boundaries of Belgium, a friend was
writing in a file the numbers of the boundaries he created. 
Inevitably, we made the same job twice. The problem stopped when he
understood he should create a subarea as soon as a new boundary
relation is created.
It's a really bad reaction to say "I don't understand that", may I
erase it? Understand first.
There should be a parent role to the mother as well. A
relation tree could be scanned both directions in a wink with just
direct links without resorting to complicated methods.

It is nice to see that those who did try to understand subareas and
did try to use them do appreciate them.
I recently fixed a part of the German border that was going outside
Germany.

Cheers



  

  André.

  



  
Take for example this boundary [1]. If the subarea role was
  deprecated then it would be a lot harder of finding out which
  are its father, grandfather, etc. relations, which would make
  verifying them a more tedious task. 


[1] http://www.openstreetmap.org/relation/4172448
  



  
2015-11-26 18:51 GMT+00:00 Martin
  Koppenhoefer :
  

  

  

  I just noticed that a lot of boundary
relations have the lower ranking parts included
as members with the "subarea" role.
  
  This role is documented here: 
  http://wiki.openstreetmap.org/wiki/Relation:boundary
  

But I wonder how it got on this definition page. Was
this discussed anywhere? I don't think it's a good
idea to add all those lower entities in nested
relations (they are already spatially structured,
this is redundant and makes the relations more
complicated for no good reason).

  
  I propose to remove this property from the definition
  page and move it to the talk page.
  

Comments?



Cheers,
  
  Martin


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

  





-- 
Um Abraço,
  Marcos Oliveira

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



  


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

Re: [Tagging] Wikipedia

[André Pirard]

  
  
On 2015-11-25 09:00, Dave Swarthout
  wrote :


  Can someone provide the correct way to tag a
wikipedia link? It seems the Wiki wants it one way and JOSM
another. The wiki wants version 1) but JOSM reports an error
when coded that way. WTF?


I want to use a tag written in English that describes a
  certain tree
Is this correct?


1) wikipedia=en.wikipedia.org/wiki/Teak


or this?


2) wikipedia:en=wikipedia.org/wiki/teak

  

In general, smart programs make clickable links of any URL
in any text field they display.
But, to be recognized as such, an URL must start (as always) with
http://...
So, you may have something like source=http://wikipedia.org/...
2015; http://anything.else... 2010
OSM.org will make two links (1).

The wikipedia=* tag is special in that it need no http://... to make
a link: the renderer will compose the URL.
But, to have it compose correctly, =* must have the prescribed
contents.
Just "en:Teak" etc. as explained in Martin Koppenhoefer's excellent
reply.


  

  André.

  


(1) But waymarkedtrails.org
did not understand this. Would someone explain better than I?

  


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

Re: [Tagging] improve tagging of traffic_calming

[André Pirard]

On 2015-11-20 17:10, Rafael Avila Coya wrote :
> Hi:
>
> What happens when a traffic calming is a crossing for pedestrians at the
> same time? I have some examples in this avenue of my home town where I
> live: https://www.openstreetmap.org/node/1080908514
>
> I find it is more important to mark it as a highway=crossing than a
> highway=traffic_calming
>
> Cheers,
>
> Rafael.
Always the same discussion.  With LST syntax it's extremely simple.

highway=crossing   means that the attribute "crossing" applies to the
object "highway".
It is equivalent to:

highway=yes(void attribute)
highway:crossing=yesmeans that the attribute "crossing" is true for
"highway"

Then we can *also* have
highway:traffic_calming=yesmeans that the attribute
"traffic_calming" is *also* true for "highway"
And, finally, as, by default, an attribute applies to the main attribute
or, if it does not exist ("yes"), to the object,
this is syntactically equivalent:

highway=yes
crossing=yes
traffic_calming=yes

(and "yes" can be replaced with a (single) attribute of crossing and
traffic_calming if needed

Please note that this is a question of syntax. I am not discussing here
if we should use highway=* or not. I'm assuming you do.

Cheers=yes

André.


> On 20/11/15 16:19, GerdP wrote:
>> Hi all,
>>
>> I've noticed that a few (940) traffic_calmings are mapped as 
>> highway=traffic_calming , most of them also have the tag
>> traffic_calming=*, but ~ 10% did not.
>>
>> The vast majority (> 212000) of the nodes tagged traffic_calming=* is not
>> also tagged highway=traffic_calming. I looked at the wiki and thought that
>> it
>> is simply a bit missleading as traffic_calming appears on the highway side 
>>  
>> So I started to cleanup, found a few nodes which where highway=crossing
>> instead of traffic_calming, found a few nodes not (yet) connected to roads
>> and finally decided to do a few larger changes today.
>>
>> After the last change one of the bigger changes was commented by user chilly
>> as an undiscussed mechanical edit, see
>> http://www.openstreetmap.org/changeset/35457641
>>
>> As stated in the changeset comment I hope that the change is okay, 
>> and I am sorry that I start this discussion now instead of asking first.
>>
>> Please let me know what you think about the edit itself and whether or not
>> I should revert all changes related to this tag.
>>
>> Gerd
>>
>>

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

[Tagging] Friendliness with attacked mapped places in Paris

[André Pirard]

Hi,

OpenstreetMap often extends friendliness by humanitarian tagging.
In this case of desolation, there is little to tag.  Little...
Wikipedia have been extremely fast
 in all
languages !!!
After some mourning period, the note below may be replaced by this (but
how?):
Attentats du 13 novembre 2015 en Île-de-France


I have just uploaded this change set (scroll down the left pane):
Our deepest condolences about the horrible terrorist attacks that
happened here on 2015-11-13.

It adds the following note 
to the OSM elements at the 6 attacked locations.
(they were perfectly mapped, bravo)
> Nos plus sincères condoléances à propos des monstrueuses attaques
> terroristes qui ont eu lieu ici le 2015-11-13. Vous avez l'amitié de
> tous les contributeurs à OpenStreetMap de par le monde.
In their language.  Sorry no room for added English in <256 characters. 
Translates to:
Our deepest condolences about the horrible terrorist attacks that
happened here on 2015-11-13.
Receive the friendship of all the Openstreetmap contributors around the
world.

Please forward this to other concerned OSM mailing lists.
Please let me know any change you come to an agreement with.
I will make any change easily using my *.osm file.

By Monday, you may like to send the URL to the Press.
It won't be bad advertising for OpenStreetMap to show the places and to
join the world's cry .
But let us hope that vandalism will not be added to terrorism.

Cheers

André.


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

Re: [Tagging] Friendliness with attacked mapped places in Paris

[André Pirard]

On 2015-11-14 19:35, Frederik Ramm wrote :
> André,
>
>OSM is not a place for condolences in note tags.
>
> I'm sorry if this sounds harsh but sticking to facts is what keeps most
> conflicts out of OSM - if something is observable on the ground, we map
> it, and if not, we (mostly) don't.
>
> Emotions are one such thing we don't map.
>
> Yes, a tragedy has happened, or more precisely a horrific crime; and
> yes, you and I and many others wish to extend our hearfelt condolences
> to the victims and their families. But OpenStreetMap is not the right
> medium to do that.
>
> There are many places in the world where tragedy, crime and injustice
> have happened on a grand scale. But we don't have condolence messages in
> OSM at Auschwitz, Srebrenica, or Columbine, and for a reason - because
> we as a community can't "feel" sympathy, only individuals can. How would
> we decide where to put such messages and how to word them, and what
> would we do in situations where a tragedy has happened but people
> disagree about who's the victim and who the perpetrator?
>
> Let's stick to facts on the ground and keep our emotions out of OSM,
> hard as it may seem.
>
>> By Monday, you may like to send the URL to the Press.
> Please don't. By giving the world the idea that OSM is a place to
> express emotions, you will invite everyone to express theirs, and
> certainly not all emotions are friendly and peaceful.
>
>> But let us hope that vandalism will not be added to terrorism.
> That's exactly what you are inviting here. You may have the best
> intentions but you're doing the wrong thing.
>
> Bye
> Frederik
Frederik,

Thanks for your time writing that explanation.
I wanted to revert that update (1).
But I got in trouble with revert conflicts and I panicked.
It turned out that, while you were writing, M!dgard
 had already silently
removed it.
Is it normal OSM practice to step on each other's feet?
Like one day:
X: help! can you explain this?
me, helpfully: I don't see what you describe in OSM
Y had read X and silently changed OSM.
It made me feel like no longer wanting to help.

And BTW, I once was falsely accused of bad tagging in 3 changesets
visible for 100 objects.
Nobody made your remarks.
While I admit that OSM is not a place for kind condolences, I wonder if
it is one for insults.

Cheers

André.


(1) definitely but reluctant to do immediately because I received
heartbreaking thanks from mappers about that.




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

Re: [Tagging] "What can I ask ..." list for browsing people

[André Pirard]

On 2015-11-03 05:38, Marc Gemis wrote :
>
> On Mon, Nov 2, 2015 at 8:26 PM, André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>> wrote:
>
>>> What can I show to Mr X?
>>>
>> This is extremely off topic btw.
> *you* are perfectly off topic.
> You seem to confuse the mappers and the public.
>
>
> What Simon probably means is that this topic does not belong on the
> tagging mailing list.
> It belongs on the general talk mailing list IMHO.
Thanks for your guessing what Simon means. Thanks for watching on us,
constable.
To be sure to write an understandable message, the topic of this thread
has been removed again.

IMHO, it's perfectly a matter of the Tagging list to make an index of
the most useful tagging documents they wrote.
The general public has absolutely no notion of what tags exist nor what
what they could request for the OSM elements of their concern and they
could find that in that list.
That list could be pointed to by the Notes page
<http://wiki.openstreetmap.org/wiki/Notes>
<http://wiki.openstreetmap.org/wiki/Notes>("Do s: Use this feature to
report an error ... or to give some additional information", making a
map omission less fuzzy and subtle
<http://wiki.openstreetmap.org/wiki/Notes#Use_of_notes_for_adding_a_marker_for_personal_use>)
which could be pointed to by the OSM.org Help page if it had not been
refused <https://github.com/openstreetmap/openstreetmap-website/issues/871>.

André.



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

Re: [Tagging] Tagging dangerous intersections

[André Pirard]

On 2015-11-10 10:24, Kieron Thwaites wrote :
> Hi,
>
> I recently passed through an intersection in a particularly dodgy part
> of town that actually had warning signs up, warning motorists that
> said intersection is a hotspot for "smash and grab" robberies.  (If
> anyone is interested, it's on Google Streetview too:
> https://goo.gl/maps/kYkdMR9Kmpk)
>
> I'd like to add this information to OSM -- certainly, it could be used
> by routing software to avoid the area unless there was no other
> sensible alternative.  However, I'm not sure how best to tag it.  The
> only thing that I've found is the proposed "hazard" tag
> (http://wiki.openstreetmap.org/wiki/Proposed_features/hazard), but as
> it seems to be in a permanent draft state (since 2009), I'm not sure
> if this is the best solution.
Of course yes it would be the best solution to resurrect that draft
.
Presently, OSM takes little care for road security, especially for children.
And it's not a good reason to neglect the existing kitchen because there
are no eggs.
I have mapped a number of 30km/h zones.
I was literally abashed that, among all the zones mapped in Belgium,
Germany, France and Netherlands, not a single one indicated a school
zone

hazard.
I stopped my mapping because I don't like to redo everything correctly
later.

On 2015-11-10 17:15, Mateusz Konieczny wrote :
> For start, traffic sign itself may be also mapped. It would also make
> clear that hazard (or other method to tag this) is based on something
> verifiable, not opinion of the mapper.
The problem, as with most traffic signs, is that they are not located
where the problem is and that, as I see them used, they do not even
indicate the direction to where it is.
As well as duplicating other information albeit the word "duplicate" is
spoken as an OSM sin.
GSM software is perfectly able to draw most traffic signs on the screen
without an added element.

André.




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

Re: [Tagging] "What can I ask ..." list for browsing people

[André Pirard]

On 2015-11-01 23:25, Simon Poole wrote :
>
> You click on "Help" then on "Beginners Guide"

> This *Beginners' Guide* will show you how to add data to OpenStreetMap.
> You need a computer connected to the Internet and some time to gather
> information and then enter it. A GPS unit and connecting cable are
> purely optional, but will be required if you want to collect data that
> way. Given the excellent aerial photography available in the editors
> these days, a GPS is less important than in the early days of the
> project
>
Are you sure that this is information helping the owner/runner/... of
some feature, let us say a shop, to tell a mapper which available tags
he would like to see, like I explained?

It seems that there is no such information and that doesn't help the
public composing Notes to improve their elements.
> Am 01.11.2015 um 19:10 schrieb André Pirard:
>> ...
>>
>> What can I show to Mr X?
>>
> This is extremely off topic btw.
*you* are perfectly off topic.
You seem to confuse the mappers and the public.
And, btw the correct, fully meaningful quote is
> X
;-)

Cheers

André.




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

Re: [Tagging] tunnel=culvert

[André Pirard]

On 2015-10-29 16:03, Martin Koppenhoefer wrote :
>
> 2015-10-29 13:40 GMT+01:00 Richard  >:
>
> On the other end of the complexitiy scale it would be nice to have
> a simple method to map insignificant culverts with a single node.
>
>
>
> IMHO, if you don't consider them significant enough to be mapped as a
> way you should maybe not map them at all.
> What is the advantage of a node, one click less?
You might get in troubles explaining Osmose or such that a node at a
lower layer is crossing a way.
Especially if there is no node.
If you like small culverts, JOSM is able to make them as small as 1.25
cm (½").

André.



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

Re: [Tagging] More human readable values for traffic signs

[André Pirard]

On 2015-10-29 21:00, John Eldredge wrote :
>
> I think he is referring to the "do not enter" sign, a red circle with
> a horizontal white bar.
>
Jo sometimes speaks vaguely and publishes search/guessing exercises ;-) 
. What he means is:
> Also keep in mind there are 2 'oneway' signs. A blue one that can be
> round or rectangular
>  [an
> information sign] and a round red one
>  [a
> prohibitory sign].
The rectangular F19
 is
disputably classified as "information" because it in fact also prohibits
driving in the other way and hence to U-turn.
The no-U-turn sign C33
 might be
thought of as one-way, but it is not (it doesn't forbid other cars going
contra-way).
There is no round one-way sign that I know of.  But, of course, a follow
the direction
ahead
D1
 placed
withing a street (not at a crossing) amounts to a no-U-turn with the
same remarks as for F19.

Once again, such a specialists' controverted discussion makes  one thing
certain:  those fuzzy road signals must certainly never be used for
routing (restrictions).  oneway=yes is much more obvious and foolproof. 
And it allows software to represent corresponding signals without any
need to tag them if someone likes to turn that option on (with the risk
of having two instead of one).  Remember the noexit=yes story !!!

Cheers

André.





> -- 
> John F. Eldredge -- j...@jfeldredge.com
> "Darkness cannot drive out darkness; only light can do that. Hate
> cannot drive out hate; only love can do that." -- Martin Luther King, Jr.
>
> On October 27, 2015 9:13:40 PM Colin Smale  wrote:
>
>> Only the rectangular blue sign means one way traffic... The round
>> blue one tells you which way to drive at a junction which is subtly
>> different. What is the round red one you have in mind?
>> --colin
>>
>> On 28 October 2015 00:30:58 CET, Jo  wrote:
>>
>> Also keep in mind there are 2 'oneway' signs. A blue one that can
>> be round or rectangular and a round red one.
>>
>> 2015-10-27 23:05 GMT+01:00 Michael Reichert > >:
>>
>> Hi Mateusz,
>>
>> Am Mon, 26 Oct 2015 08:58:08 +0100 schrieb Mateusz Konieczny:
>> > I recently started tagging traffic signs and I am surprised
>> by wide
>> > usage country-specific traffic sign codes.
>> >
>> > I think that at least common signs may be tagged by
>> human-readable
>> > values. Some (see
>> > http://wiki.openstreetmap.org/wiki/Key:traffic_sign#Human-
>> readable_values
>> > ) are already used
>> >
>> > I propose to add more like
>> > - traffic_sign=oneway
>> > - traffic_sign=no_stopping
>> > - traffic_sign=no_parking
>>
>> At least the oneway sign looks different from country to
>> country. Or do
>> you expect that a French oneway sign looks like the German
>> one? (The
>> German one contains the word "Einbahnstraße", the German
>> translation of
>> oneway)
>> https://commons.wikimedia.org/wiki/File:Zeichen_220-20.svg
>>
>> And even traffic signs without text often look different because
>> different countries use different fonts.
>>
>> That's why I suggest to use the country prefixes followed by
>> a number or
>> the name depending if the country numbers its traffic signs (like
>> Germany) or not (like Austria).
>>
>> Best regards
>>
>> Michael
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> 
>>
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https:/ ​/​lists​.​openstreetmap​.​org/​listinfo/​tagging
>> 
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - Voting - Motorway link no default oneway

[André Pirard]

On 2015-10-29 20:45, Joachim wrote :
> I invite you to vote on the proposal "Motorway link no default
> oneway". The following is proposed:
>
> Strongly recommend explicit tagging of oneway=* on highway=motorway_link.
>
> Define that highway=motorway_link without tagged oneway=* has no
> implied oneway=yes and also the standard default of oneway=no does not
> apply. The oneway=* status of such a way would be undefined.
>
> * For rendering purposes ways with undefined oneway should be
> displayed like the default, i.e. without oneway arrows.
> * For routing purposes no recommendation for ways with undefined
> oneway is made. A provider should decide on it's own considering the
> documentation history and current data.
> * In map editors undefined oneway should be displayed as tagging
> error. Corresponding tickets will be opened for JOSM/iD/Potlatch.
>
>
> Link: 
> http://wiki.openstreetmap.org/wiki/Proposed_features/Motorway_link_no_default_oneway#Voting
It says:
> Strongly recommend explicit tagging of oneway=* on highway=motorway_link.
> For routing purposes no recommendation for ways with /undefined
> oneway/ is made. A provider should decide on it's own considering the
> documentation history and current data.
It is totally unacceptable to let a GPS provider "decide on its (not
it's) own" (what?) based on fuzzy and vague "documentation history and
current data".  OSM is the place that *must* contain the data to be used
and, should the oneway status be undetermined, routing must obviously be
*requested* to not let the cars go through that place.
If that undetermined status existed, contributors should not be
recommended but requested explicit tagging.
And hence, quality assurance providers should be *requested* to check
motorway_link statuses and to warn the culprit and not an innocent as
Osmose does, and even this Tagging list in such grave security cases.

Please let us not make OSM responsible for car crashes.

Cheers

André.












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

Re: [Tagging] tunnel=culvert and splitting

[André Pirard]

  
  
On 2015-10-25 07:44, GerdP wrote :


  Hi all,

up to now I've used tunnel=culvert 
http://wiki.openstreetmap.org/wiki/Tag:tunnel=culvert
like this:
1) JOSM warns that a waterway and highway are crossing
2) I split the waterway into 3 parts and add 
tunnel=yes, layer=-1 to the short one in the middle (or 
split the road and add bridge=yes,layer=1)


I keep the stream at layer=-2, I add the culvert in an additional
small way segment on top at layer -1 and both are crossing the road
which is at layer=0.
This keeps the stream at layer=-2 from spring to end, which is
perfectly correct and convenient.
A Nominatim search of a JOSM selection shows the whole stream and
not stupid pieces.

I never understood the remark "it is not necessary to not split, one
can consolidate splits in relations (easy, isn't it)".  To me, it is
"it is not necessary to split".  Why not avoid splits in the first
place?
The same can be done for bridges which are in fact pieces of
concrete under the uninterrupted tarmac foil and not an interruption
(split) of the road.

I once wrote an OVERLAY suggestion (to be discussed, that I much
improved since) that generalizes the principle of an overlay way
segment that, in one of its usages, applies tags such as speed limit
to a segment of the highway. Roads, as seen by an editor, Nominatim
etc., are kept unsplit but the programs that do not want to deal
with the overlay segments can prepare the OSM data by using the
overlay ways to split the main ones, discarding them and continue
with the same logic as presently.
In a second usage, it can avoid a hiking route that is using a main
highway over 50m before leaving it to split that main highway.


  

  André.

  











  


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

Re: [Tagging] How one may tag object as castle?

[André Pirard]

On 2015-10-15 09:29, Martin Koppenhoefer wrote :
>
> sent from a phone
>
>> Am 14.10.2015 um 23:49 schrieb André Pirard <a.pirard.pa...@gmail.com>:
>>
>> Under the thread "château" I pointed out that there are buildings that can 
>> be called château ≃ castle and that are not historic at all.
>
> the question what is historic is a philosophical one. Anyway, some château 
> are castles, others not. Similarly in Italian there are different 
> translations for the English word castle, one of them being castello, but 
> others are different and not all castelli are castles in English. We should 
> go by our own definitions for the tags, and not analyze all different 
> meanings of the word in a tag and which meaning they have in different 
> contexts 
>
> http://www.larousse.fr/dictionnaires/francais/château/14902
The problem that I explain in the important part of my message that
isn't quoted is that we are obviously talking of
building=castlea building that is a castle, and not
historic=castle a historic that is a castle; but a castle, like many
other objects, can be
historic=yes or not

Exactly like
natural=water
water=lock
artificial=yes
Should be
water=lock
artificial=yes
As well as
water=lake
natural=yes

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

Re: [Tagging] Parcel box tagging

[André Pirard]

On 2015-10-07 00:43, Martin Koppenhoefer wrote :
> sent from a phone
You are excused ;-)
>> Am 06.10.2015 um 23:31 schrieb Daniel Koć :
>>
>> In my opinion having popular amenity type only for one country
> it's not about the country, it's about the system I guess. Some time ago I 
> spotted a DHL Packstation at the main station in Rome, so they're not limited 
> to Germany. I agree this definition is not nice, and using a brand name as 
> amenity value is not nice.
cc: Marc Gemis has spotted in Belgium and discussed on talk-be@ similar
boxes that have nothing to do with DHL, Germany or other countries, pure
Belgian (no beer, no chips inside, though).

Cheers

André.



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

Re: [Tagging] how to tag a salt flat

[André Pirard]

  
  
On 2015-09-29 17:29, joost schouppe
  wrote :


  Hi,


I haven't found much about the
  subject. A salt flat is a large deposit of salt. They are
  usually where a river ends in the middle of a desert. Or where
  a valley is completely surrounded by mountains, leaving no way
  out for any water. So salt starts accumulating as salty waters
  evaporate. Some of them rarely see any water, others are
  inundated every year or might be under water a lot of the
  time. Because they tend to be dry most of the time, and plants
  tend to dislike pure salt, they tend to look like a desert.


How should one tag such a thing?
  I've seen three very different ideas:
  

You might find some inspiration by searching for "marais
  salant", which is French for similar areas, but fitted for
salt production.  The discussions will take you further to tags as
salt_pond, natural=wetland and the like.
As salt is cheap, this is just 2 ¢. €¢.


  

  André.

  





  


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

Re: [Tagging] Handle with care

[André Pirard]

On 2015-09-24 17:32, Kotya Karapetyan wrote :
> Hi André, all,
>
> Shall we discuss an "object_warning" tag? To begin with, it will
> simply contain information. Editors can also choose to show it when
> the tagged object is about to be changed.
Gladly (of course), I suppose that all those discussions were meant to
come to a concrete result.
But beware that it is not "object_warning" that seems to protect the
whole element.
It is
:warning=
which acts only when that key is changed.
geometry:warning=  to protect the coordinates of the element
name:warning=  to protect its name.
Those tags do not warn against changing other tags.

But it's a good implicit remark that the whole object could be
protected, including from deletion.
warning=

"about to be changed" is not "about to be uploaded" (needing to identify
several elements" but when the user clicks for changing (normally) one
element.

Cheers

André.





>
> Kind regards,
> Kotya
>
>
>
>
>
> On Fri, Sep 18, 2015 at 12:53 AM, André Pirard
> <a.pirard.pa...@gmail.com <mailto:a.pirard.pa...@gmail.com>> wrote:
>
> On 2015-09-17 18:02, Kotya Karapetyan wrote :
>> Hi André,
>>
>> I don't know why your text was removed. 
>>
>> > It would produce a message saying something like:  
>> > "The coordinates you are trying to change are accurate to 25 cm.  
>> > You probably shouldn't change this tag, certainly not with GPS data.  
>> > Are you certain that you will not destroy valuable data and do you 
>> want to continue?".
>> > And if he replies "no", his attempt is canceled.
>>
>> I like this approach. I wonder if it is technically feasible.
> Forget about my bad examples and the eagerness to pick them.
> Here is the original text.
>>> ... Despite a "don't touch" note explaining why not, a good soul
>>> passes, not reading note and makes a "correction".
>>> What is needed here is an "are you sure?" tag named such as 
>>> [keyname:]warning="text" that the map editing softwate  uses any
>>> time a mapper wants to change that keyname's value  to display
>>> the message and ask for a confirmation (by the tag, at the time
>>> he tries to change it, not when he tries to upload a dozen of
>>> such changes).
>>> ="Reasons why you shouldn't change that tag.  Do you
>>> really want to change it?"
>>> Replying "no" cancels the attempt.
>>> Or should it be [keyname:]note:warn="text" and spare another
>>> wiki page?
>>> keyname can be "geometry" as in source:geometry.
>>> Et voilà.  An all-purpose simple guardrail, a small update to
>>> the wiki and passing the word to the editors.
>>
>> My point was that to make it generic may be more difficult than
>> creating a very specific tag/function for survey-based data.
> IMHO it may be simpler that some specific implementations and
> certainly when their numbers reaches 2.
> The answer will be given by JOSM et al.
> It doesn't address "mechanical" updates, but the persons doing
> them are supposed to know what they're doing, aren't they?
>> And I didn't understand the benefit for your other examples. But
>> otherwise I support it.
> Those examples forgotten, other voices are needed, the wiki update
> has almost been written.
>>
>> Cheers,
>> Kotya
> General tip: Kotya, do you know that you can have your
> kotya.li...@gmail.com <mailto:kotya.li...@gmail.com> account use
> filters to store messages in by-the-list folders and access those
> folders using IMAP with software like Thunderbird and do things
> like answering to ancient mail?
>
> Cheers
>
> André.
>
>
>

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

Re: [Tagging] Handle with care

[André Pirard]

On 2015-09-26 22:43, moltonel wrote :
>
> On 26 September 2015 19:05:09 GMT+01:00, "André Pirard" 
> <a.pirard.pa...@gmail.com> wrote:
>> It is
>> :warning=
>> which acts only when that key is changed.
>> geometry:warning=  to protect the coordinates of the element
>> name:warning=  to protect its name.
>> Those tags do not warn against changing other tags.
> May I suggest 'edit_warning', or something else that explicit (because a 
> 'warning' key could be used for so many purposes) ? And use proper namespace 
> ordering, ie edit_warning:name=blah rather than name:edit_warning=blah 
> (because many keys, like name or phone, are also namespaces that can be 
> followed by arbitrary sufixes).
OK with me for a more explicit term as long as it is not too long.  The
best inventor will win.
But I'm afraid that the correct namespace order is name:edit_warning=*.
edit_warning is a qualifier of name and not the opposite.
It is the edit warning of (for) name and not the name of the edit warning.
It's just like the order of the words in an English phrase.
Adding a qualifier makes the word more specific, "with warning" rather
than plain.
If you speak of the building antenna type, it's building:antenna:4G=yes
The left side of the road is road:left and not left:road.
And BTW, source:maxspeed is a mistake, there is no such thing as the
speed of a source
The source of the maxspeed should be maxspeed:source.
And its date should be maxspeed:source:date and not
source:date:maxspeed or source:maxspeed:date or date:maxspeed:source..
But it's typical of an OSM article about namespaces not to speak of the
order.
Let us stop making more mistake.
> That said, you should open bugs on the various editors as soon as possible to 
> discuss with them what they think of such a feature. Unless this tag gets 
> editor support, it doesn't bring anything that the already popular 'note' tag 
> doesn't give. Sadly, inexperienced mapers are the ones most likely to miss a 
> plain 'note' tag, but they are also most likely using iD, whose developers 
> are pretty warning-averse...
Don't speak like that of mappers and developers ;-)  You're going to get
in trouble with Julien Fastré who will say that you're trying to
convince us, and yourself, that "they are doing bad job" and that you
will frighten newcomers (sic) ;-)
This said, seriously and frankly, I have a serious dilemma when I'm
hippy hopping the JOSM Area Selection Plugin along the way and I meet
polygons completely askew and 4-5 m or more away from their place with
just "building=yes" and that in one single click I can draw the house
with a 20 cm precision and complete tags, the house number being
incremented for the next house !  I feel like a 5 years' work has to be
restarted afresh.  Fortunately, not afresh for fixing road geometry in
Improve Way Accuracy mode of that JOSM again.
Isn't there a convincing tutorial to compare methods and show that (fixing)?
I know two friends who are ¾ convinced but who can't get rid of their
habits and make the first step.
I myself know too little of the other products to be a good comparator
and convincing advisor.
All that I can say is that a good migration method is to use the old and
the new programs simultaneously, more and more of the new one.  It's
what I did when simulating a shift from JOSM to Merkaartor, but it
turned out that there were too many things that Merkaartor couldn't do.

Cheers

André.



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

Re: [Tagging] Handle with care

[André Pirard]

On 2015-09-17 18:02, Kotya Karapetyan wrote :
> Hi André,
>
> I don't know why your text was removed. 
>
> > It would produce a message saying something like:  
> > "The coordinates you are trying to change are accurate to 25 cm.  
> > You probably shouldn't change this tag, certainly not with GPS data.  
> > Are you certain that you will not destroy valuable data and do you
> want to continue?".
> > And if he replies "no", his attempt is canceled.
>
> I like this approach. I wonder if it is technically feasible.
Forget about my bad examples and the eagerness to pick them.
Here is the original text.
>> ... Despite a "don't touch" note explaining why not, a good soul
>> passes, not reading note and makes a "correction".
>> What is needed here is an "are you sure?" tag named such as 
>> [keyname:]warning="text" that the map editing softwate  uses any time
>> a mapper wants to change that keyname's value  to display the message
>> and ask for a confirmation (by the tag, at the time he tries to
>> change it, not when he tries to upload a dozen of such changes).
>> ="Reasons why you shouldn't change that tag.  Do you really
>> want to change it?"
>> Replying "no" cancels the attempt.
>> Or should it be [keyname:]note:warn="text" and spare another wiki page?
>> keyname can be "geometry" as in source:geometry.
>> Et voilà.  An all-purpose simple guardrail, a small update to the
>> wiki and passing the word to the editors.
>
> My point was that to make it generic may be more difficult than
> creating a very specific tag/function for survey-based data.
IMHO it may be simpler that some specific implementations and certainly
when their numbers reaches 2.
The answer will be given by JOSM et al.
It doesn't address "mechanical" updates, but the persons doing them are
supposed to know what they're doing, aren't they?
> And I didn't understand the benefit for your other examples. But
> otherwise I support it.
Those examples forgotten, other voices are needed, the wiki update has
almost been written.
>
> Cheers,
> Kotya
General tip: Kotya, do you know that you can have your
kotya.li...@gmail.com account use filters to store messages in
by-the-list folders and access those folders using IMAP with software
like Thunderbird and do things like answering to ancient mail?

Cheers

André.


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

Re: [Tagging] Cycle cafes ... and Repair Cafés

[André Pirard]

On 2015-09-14 21:41, Richard Fairhurst wrote :
> How would you tag a "cycle café"?
And, while we are at it, a "Repair Café ".
Also, usually www.repaircafe.CC.
Those I've seen use amenity=cafe, which many are not, using other premises.
It's one case again in which I suggested to use OSM and I didn't receive
a single answer.
And yet, I showed them this nice map

where n° 1 is in a better place than in this dull one
.

Cheers

André.



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