[Tagging] traffic_signs: human readable values vs. ISO and law codes

[yo paseopor]

Well, let's start. As you know there are values in traffic sign key that
are human readable and others that are the ISO code of the country plus the
code inside the traffic law of every country (from South Africa to USA). It
is not a big problem...except they are using the same key.
Probably human readable values are the future of OSM, because you don't
know very specific knowledge about that. So a newbey mapper can use iD
Editor and put a maxspeed traffic sign, or can use hazard from a proposal
from the wiki.
But in the other hand major use in traffic_sign key are the legal and
specific values for each traffic sign (or a combination of that). You can
use the traffic laws of each country or specific presets, plugins and
styles to edit them without big difficulty, too.
What can we do? What value has to prevail in OSM: the specific or the
verbose? What can we do if we want to maintain both of them?
What do you think about that? With which tags would you separate that
values?

Salut i mapes
yopaseopor

PD: same thread here, you can answer wherever you want
https://community.openstreetmap.org/t/traffic-signs-human-readable-values-vs-iso-and-law-codes/111821


Libre
de virus.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [Voting] Feature Proposal - traffic signs national id and human readable values (traffic_sign=* and traffic_sign:id=*)

[yo paseopor]

Hi

As you would know or you can have read in some places there is a proposal
about the mapping of traffic signs.You can have the proposal here, read it
, and if you consider vote it:

https://wiki.openstreetmap.org/wiki/Proposal:Extended_traffic_signs_tagging

And the discussion is here:

https://wiki.openstreetmap.org/wiki/Proposal_talk:Extended_traffic_signs_tagging

Now it is the time of voting !

Thanks for reading and commenting and voting (if you want)
yopaseopor


Libre
de virus.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Last week for [RFC] for traffic signs national id and human readable values (traffic_sign=* and traffic_sign:id=*)

[yo paseopor]

Hi

As you would know or you can have read in some places there is a proposal
about the mapping of traffic signs.
You can have the proposal here.

https://wiki.openstreetmap.org/wiki/Proposal:Extended_traffic_signs_tagging

And the discussion here.

https://wiki.openstreetmap.org/wiki/Proposal_talk:Extended_traffic_signs_tagging

Now it is in the last week of RFC time. If there is not substantial comment
to ammend the proposal probably next week I will start the time of voting !

Thanks for reading and commenting it.
yopaseopor

PD: Also you can comment on
https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508

Discussion in Spanish


Discussion in Catalan

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

[Tagging] [RFC] traffic signs national id and human readable values (traffic_sign=* and traffic_sign:id=*)

[yo paseopor]

Hi!
After a month of latest discussion on the Community forum, and after
consulting Spanish and Catalan Community for comments , variations and
corrections I ask for RFC for this proposal:
https://wiki.openstreetmap.org/wiki/Proposal:Extended_traffic_signs_tagging

Please also see previous discussion on the Community Forum:
https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508/99

Thanks,

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

Re: [Tagging] How do you map traffic signals where right or left turns are allowed or not allowed on a red light?

[yo paseopor]

Here in Europe that situation starts to be assumed by big cities who love
bicycles. It is a new regulation you can find in Paris or Barcelona.
Now we can ride our bikes in oneways streets as oneway:bicycle=no and also
this possibility of turn in red traffic lights. Also these days we start to
find some crossings where we can go straight in bicycle (as the right case)
Red turn is from English and I suspect is from someone who is not English
native like me. I understand "Giro rojo" de Giro en rojo" (turn right at
red?). I think it is not bad for a osm tag.

https://www.elperiodico.cat/ca/societat/20150719/els-ciclistes-proposen-imitar-paris-i-permetre-a-les-bicis-saltar-se-el-vermell-4369313

Ara més que mai salut i mapes
More than ever Health and maps
yopaseopor




Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Oct 11, 2020 at 6:15 PM Joseph Eisenberg 
wrote:

> In North America (since we hate pedestrians) usually it is legal to turn
> right at a red light (we drive on the right side of the road, so a right
> turn only involves crossing into one lane).
>
> At some intersections where there are many pedestrians, there are signs
> that say "no turn on red", or sometimes "no turn on red except bicycles".
>
> Should this be mapped as a Relation:restriction? For example, a relation
> with "restriction=no_turn_on_red" + "except=bicycle"?
>
> Alternatively, I see there is a tag used in Europe in the form
> "red_turn:right:bicycle=yes" + "red_turn:right=no" - this would mean that
> bicycles may turn red at a traffic signal but other vehicles may not turn.
> This is documented at https://wiki.openstreetmap.org/wiki/Red_turn
>
> That tag is also used when right turns are allowed, e.g.
> "red_turn:left=yes", when this would not always be expected. It's most
> often used in Dresden.
>
> Oddly, it is proposed on the page that you could also use
> "red_turn:straight:bicycle=yes" to say that "bicycles are allowed to go
> straight at this traffic light when it is red", but this sounds very
> strange to me.
>
> I wonder if "red turn" is a translation from German or another language?
>
> -- Joseph Eisenberg
> ___
> 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] site relations for city walls?

[yo paseopor]

Big sense, nerver forget.
What about that?


https://www.openstreetmap.org/relation/6651797#map=11/52.5183/13.2976

Health (more now than never) and maps
yopaseopor

On Sun, Jul 12, 2020 at 8:44 PM Martin Koppenhoefer 
wrote:

> Someone has made a site relation for the Aurelian citywalls in Rome.
> Does this make sense to you?
> We‘re speaking of a generally linear object of many kilometers length, in
> parts fragmented / interrupted.
>
> 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

Re: [Tagging] [Talk-us] Trunk VS primary,

[yo paseopor]

Hi!
You lost my point of view:(WHICH)  the best (or worst) conditions for a
road you can find in a country. In some countries will be seem like a
motorway, in other countries or zones will be a sand track. And the other
focus: WHO can know these conditions (local communitters, people who lived
in the country, etc.) .This is an issue OSM will have to front some day.
And some day we will have an agreement about it.

Health and maps (Salut i mapes)
yopaseopor

On Thu, Dec 26, 2019 at 7:51 PM Erkin Alp Güney 
wrote:

> No, that is highway=road. highway=unclassified is one grade above that.
>
> 26.12.2019 21:39 tarihinde yo paseopor yazdı:
>
> >
> > In a country like Zambia or Congo unclassified would be the worst
> > condition road you can find in that country (but not track), so only
> > local community people (or people who live in that country) would know
> > what are the worst conditions you can find in their country.
>
> ___
> 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] [Talk-us] Trunk VS primary,

[yo paseopor]

First problem for classifications is the reason of the classification. What
is this reason: administrative laws (with their political facts to keep in
mind) or physical conditions (the best for the performance of the vehicles
you would have in this road)?

Second problem is the reality of the country: If you are in the country
with the biggest budget in motorways you will be sure some secondary will
have two lane roads and bridges without crossings. If you are in a country
major part of your population will not have assured every day's meal main
road would be an asphalted road or sand track.

But the number of grade classifications are the same wherever you go: four
to six grades
(1-trunk,2-primary,3-secondary,4-tertiary,5-unclassified,6-track) .
My option would be a physical classification based on the state of the
country. Only motorway would be apart of this classification because a
motorway is the same here than in other countries.

Here in Europe you can find the administrative grades at the reference of
the road (N- ,Regional- , Province- in Spain; N-, D- in France; B , L in
Austria; ...).

In a country like Spain trunk would be a road with 100 km/h medium speed
and no crossings at the same level with restriction for cycles .
In a country like Zambia or Congo trunk would be the best conditions road
you can find in that country , so only local community people (or people
who live in that country) would know what are the best conditions you can
find in their country.
In a country like Spain unclassified would be the municipality asphalted
tracks, with no more than 3 meters width (for one car).
In a country like Zambia or Congo unclassified would be the worst condition
road you can find in that country (but not track), so only local community
people (or people who live in that country) would know what are the worst
conditions you can find in their country.

I know Spain because I am Spaniard and I travel through Europe , so I think
in the European Union things would be similar. Local communitters can
explain in this list what are the best and the worst conditions for the
roads in their countries and their opinion about the other grades. I don't
have any knowledge about Zambia or Congo so I think other people would have
more knowledge than I can have about their countries.

What are your opinions? What do you think?
Salut i mapes (Health and Maps)
yopaseopor

On Mon, Dec 23, 2019 at 11:41 AM Fernando Trebien <
fernando.treb...@gmail.com> wrote:

> On Fri, 20 Dec 2019, 19:05 Graeme Fitzpatrick, 
> wrote:
>
>>
>> On Fri, 20 Dec 2019 at 19:18, Martin Koppenhoefer 
>> wrote:
>>
>>> lanes=2
>>> surface=unpaved
>>>
>>
>> But would they still count as either =trunk or =primary?
>>
>> While they're of high local importance, they're definitely not
>> high-performance & they don't link major population centres either?
>>
>
> That's exactly the problem we had in Brazil while trying to prescribe
> classification from physical characteristics from roads.
>
> It may be worth checking what are popular commercial (paper or digital)
> maps doing regarding the classification of highways and streets.
> ___
> 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] Strange tags

[yo paseopor]

With maps like https://osm-catalan.github.io/osmcatmap/ with code forked
from Bicycle tags maps like this https://github.com/yopaseopor/customosmapp
you can do the map you want about any tag=value with no dedicated server
(only account of github). So if you are interested in all this stuff you
can do your map.

OSM is open, that's the richness of the project
Health and maps (Salut i mapes)
yopaseopor

On Sun, Sep 29, 2019 at 4:52 PM Valor Naram via Tagging <
tagging@openstreetmap.org> wrote:

> Be sure that almost no data user will evaluate these tags
>
> ~ Sören Reinecke alias Valor Naram
>
>
>  Original Message 
> Subject: Re: [Tagging] Strange tags
> From: ael
> To: tagging@openstreetmap.org
> CC:
>
>
> On Sun, Sep 29, 2019 at 09:09:16PM +0700, Dave Swarthout wrote:
> > donald=yes
> > ele=821
> > graham=no
> > man_made=cairn
> > munro=no
> > name=White Coomb
> > natural=peak
> > note=cairn yes
> > source=local_knowledge
> > wikidata=Q7994603
> > wikipedia=en:White Coomb
>
> These are well known terms in the UK, so I would think they are valid
> and useful tags.
>
> ael
>
>
> ___
> 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] Default values for surface by road category and country

[yo paseopor]

In Europe I think.
In other countries of other continents there's no pavement on all the main
highways.

OSM is "universal" so the scheme should not have values by default asking
only one part of the World

Salut i mapes (Health and Maps)
yopaseopor

On Sat, Sep 21, 2019 at 1:53 PM Joseph Eisenberg 
wrote:

> I believe all highway= values are assumed to be paved by default (in most
> places) except for highway=track. But it’s best to always add a tag, even
> for paved roads, if you know.
>
> (In some rural and wilderness areas it’s likely that most minor roads,
> footways and paths are unpaved, but explicit tags are still needed. I
> always try to add at least surface=paved or =unpaved when mapping from
> aerial imagery here in Indonesia)
>
> Joseph
>
> On Sat, Sep 21, 2019 at 6:43 PM Jez Nicholson 
> wrote:
>
>> Do you mean the default values in a particular piece of software, e.g. iD?
>>
>> On Sat, 21 Sep 2019, 11:06 Volker Schmidt,  wrote:
>>
>>> I am trying to figure out where the surface default values by road
>>> category and country are defined.
>>> Anyone who knows more about the subject?
>>>
>>>
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> <#m_620798944707518482_m_-5640715623807028892_m_123805171941743012_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> ___
>>> 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] Mapping specifically every traffic signal

[yo paseopor]

Hi!

Mapping Barcelona in a more specific way (we have the authorization to use
Townhall's Barcelona OpenData, we have one project to import Spain Cadastre
buildings and portals, etc.) we have realized we need a more accurate way
to map the traffic signals.

Now we have three kinds of these artifacts:

-Car/Truck traffic signals. With two or more traffic signals (normally we
have one at the side and one above the road).
-Bicycle traffic signals. As a city with more than one hundred kilometers
of cycleways Barcelona is well-know for the tries of the Townhall to be
bike-friendly.
-Pedestrian traffic signals. With a position perpendicular to car traffic
signal is important because of accessibility data (it can buzz, it can
flash, it can count...)

I think the best way to do this is using well-know vehicle access tags, and
also the most advanced scheme to tag directions and sides.
The position of the nodes will be the same as now, on the way it affects
little before the crossing.
For these reasons I propose new way to tag all these kinds of traffic
signals as it follows in every way you have affected by one of these.

car,truck... traffic signal:

highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=motor_vehicle
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above side=right or left (it depends of the location of the pole
relative to the way it is )

bike traffic signal:
highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=bicycle
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above ,right or left (it depends of the location of the pole relative
to the way it is )

pedestrian traffic signal:
highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=foot
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above ,right or left (it depends of the location of the pole relative
to the way it is )

horse traffic signal:
highway=traffic_signals (we can avoid this)
traffic_signal:forward/backward=horse
traffic_signal:direction=forward (only if the above option is not accepted,
using iD proposal)
side=above ,right or left (it depends of the location of the pole relative
to the way it is )

then you will complement all of this with another node being the crossing
with every road, in the place we do now.

Traffic signals are so important we need a good  specific scheme to do a
good and specific mapping

What do you think about that?

Salut i mapes (Health and maps)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Using destination_sign relations for pedestrian navigation

[yo paseopor]

Using established is the best way, but look at this, it could be useful
https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging#Destination_signs

It covers all kind of traffic signs, also destination traffic signs, so it
would be useful for a pedestrian destination traffic sign description and
your routing subject.

Salut i mapes (Health and maps)
yopaseopor


On Thu, Sep 5, 2019 at 9:31 AM Antoine Riche via Tagging <
tagging@openstreetmap.org> wrote:

> Hello.
>
> We are working with SNCF, the french railway company, to provide
> pedestrian navigation inside and around railway stations in the Greater
> Paris area. A dedicated routing engine, which provides indoor/outdoor
> navigation and supports area routing, has been developed – this will be
> presented during SOTM in Heidelberg.
>
> In order to improve the user experience, we want to provide walking
> instructions such as "take the exit 'Rue de Londres'" or "Walk through the
> gate labelled 'Northern lines'" rather than "Walk 75 metres then turn
> left". Our problem is that such waypoints may have a different name
> depending on the direction you cross them. The solution we used is to
> create, when there is such an ambiguity, two destination_sign relations
> pointing to the same 'intersection' member, one for each direction with the
> 'from' and 'to' members swapped. Here is an example at Juvisy station : the
> entrance named 'Accès Danton' when walking in (
> https://www.osm.org/relation/9471596) is named 'Quartier Seine' when
> walking out (https://www.osm.org/relation/9471597).
>
> I wish to amend the Wiki to explain that destination_sign relations can
> also be used for pedestrian and indoor routing, not just at "crossroads".
> Does that require opening a discussion in the discussion page, or may I
> just go ahead ?
>
> Now since the routing engine supports area routing, we need to loosen some
> constraints on the members, that are documented on the wiki and enforced by
> the JOSM validator :
> 1/ allow areas for the 'from' and 'to' members, as in this example :
> https://www.osm.org/relation/9722912
> 2/ allow multiple 'intersection' members, so that multiple doors can be
> referenced by a single relation – example in Gare Montparnasse :
> https://www.osm.org/relation/9823029
> 3/ allow multiple 'to' members, so that the same relation can point to
> both a line and an area, and cover linear and area routing (no example but
> I could create one).
>
> Are there objections to this proposal ? Do you recommend to open this
> subject on the Discussion page or is it best discussing it on this list ?
>
> Regards,
> Antoine.
> ___
> 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] Multiple tags for one purpose

[yo paseopor]

This not always works.

See traffic_sign:direction=* and traffic_signal:direction=* or
crossing=marked  in iD or all the "missions" you will not see implemented
in StreetComplete and the impossibility of make it more scalable and
customizable.

One person said here to a question about a reasonible good proposal of new
tagging for schools and other educative centers:

"Ask any two people on this list their opinion on any matter and you will
get THREE opinions."

Good luck with it.
yopaseopor


On Sat, Aug 24, 2019 at 9:05 PM Valor Naram  wrote:

> > Editors won't (in general) implement tags in presets unless they're
> widely used.  Unless editors and carto support tags, they won't get widely
> used, so editors and carto won't support them.  Chicken and egg.
>
> Yes, you're right. But I was the author of "changing_table" and the guy
> who lead it throw the proposal process and also Moderator of the discussion
> and votes. And contacting all the editors was no problem and they
> implemented "changing_table" and deleted "diaper" presets. See JSOM,
> OSMand, Vespucci and also iD. My effort shows that working together with
> different groups works.
>
> I would highly appreciate it when you give me a chance. In real life
> people are revelling their secrets to me because they trust me and I give
> them the feeling of being accepted as they are. It includes my talks with
> people from different worlds. More-Than-One-World Secrets. This connection
> I can try to create also among OSM folks (societies).
>
> Best regards
>
> Sören Reinecke alias Valor Naram
>
>
>  Original Message 
> Subject: Re: [Tagging] Multiple tags for one purpose
> From: Paul Allen
> To: "Tag discussion, strategy and related tools"
> CC:
>
>
>
>
> On Sat, 24 Aug 2019 at 17:06, Valor Naram  wrote:
>
>>
>> In my opinion this is a topic we should consider working on and creating
>> a wikipage to describe the "defragemtation" process in general.
>>
>
> Doing so is probably not going to achieve much.  First we need to
> defragment OSM itself.
> It doesn't matter what wonderful tags we come up with here, if carto
> refuses to render them
> then they won't get used.  It doesn't matter what wonderful tags we come
> up with here, if editors
> don't implement them as presets they won't get used.
>
> Carto won't (in general) render a tag unless it's widely used.  Editors
> won't (in general)
> implement tags in presets unless they're widely used.  Unless editors and
> carto support
> tags, they won't get widely used, so editors and carto won't support
> them.  Chicken and egg.
>
> There are complications (of course).  Carto (in general) refuses to
> implement aliases, so
> whatever the merits of deprecating landuse=grass in favour of
> landcover=grass, carto will
> refuse to render landcover=grass.  Editors don't (in general) like
> implementing aliases
> either.  So however much we wish to try to fix bad tags, which are
> frequently misused
> because the name or value was a bad choice, it probably won't happen.
> Some editors
> occasionally decide they'll ignore the list, the wiki, and carto, and go
> their own way
> (sometimes they get their way and sometimes they get a slap on the wrist).
>
> So what we need at this stage is not a defragmentation process but
> joined-up thinking
> between the various groups.  I'm not holding my breath on that one.
>
> --
> Paul
>
> ___
> 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] Parking spaces for car charging

[yo paseopor]

Here in Spain chargers like this are used by motor_vehicles but forget
about it, because before they have to be clients. I think this would be
best definition for access. But also I will use other key to specify they
have to be charging. You can find other places where charging would be not
compulsory so it is better to prepare the map for this. My option would be
for the parking spot (charger would be mapped separately):

amenity=parking_spaces
capacity=1 or 2 or 3
access=customers
charging=only

Assume there will not be any hgv trying to charge in a supermarket parking
as they don't park there with or without traffic sign which says that.


Salut i mapes
yopaseopor

On Sun, Aug 25, 2019 at 3:53 PM Paul Allen  wrote:

> My local supermarket recently added two car charging stations.  Each
> charging station took over three existing parking spaces.  This is
> apparently a nation-wide roll-out by the supermarket chain, so this
> is going to apply to many places in the UK.  It's also a likely
> arrangement of other charging stations.  See
> https://pod-point.com/electric-car-news/tesco-volkswagen-pod-point
>
> The charging station itself is at the end of a former parking space,
> and that space now has cross-hatch lines indicating there is no
> parking there.  Actually, you could fit a "half car" like a Smart in there,
> but people around here are stupid or selfish enough that without
> the restriction they'd park a full-size car there blocking half of the
> parking aisle (and some would manage to drive into the charging
> station and wreck it).
>
> The two parking spaces adjacent to the charging station are now
> signed as being for charging only and not for ordinary parking.
> The signage is in Welsh, not in English.  So I'll be charitable and
> assume that the non-electric vehicles parked in the spaces for
> electric vehicles were owned by people who don't speak Welsh
> (it's tourist season, so that is very possible).  More likely they're
> stupid and/or selfish local people of the kind who happily park
> in the spaces for disabled people despite not being disabled and
> were not transporting disabled passengers.
>
> Anyway, it would be nice to be able to mark these two types of spaces
> in some way: the "you can no longer park here because there's a
> charging station at the end of it" and the "park here to charge your
> car" spaces.  One way (perhaps the best, although it takes
> slightly more effort to map it) of dealing with the "you can no longer
> park here" would be with a multipolygon to cut a hole in the car park.
> Which just leaves the charging bays themselves.  The wiki page
> for amenity=parking_space doesn't actually document how to do
> this, even for disabled parking, but refers to the proposal
> https://wiki.openstreetmap.org/wiki/Proposed_features/parking
>
> So it looks like, for the charging spaces, amenity=parking_space +
> access:= is the way
> to go.  So what is a suitable role?  In the particular case I'm
> mapping, they are parking spaces for cars; longer vehicles won't
> fit, but it's entirely possible charging facilities that accommodate
> longer vehicles will appear in the future.  So access:car_charging,
> with access:truck_charging, access:hgv_charging being added
> as possibilities later, if required?  Or access:vehicle_charging
> and let people eyeball the map to figure out if their vehicle will
> fit?  Or access:vehicle_charging with either of the inadequately-
> documented vehicle=* or service:vehicle=*?  Or something else?
>
> Any thoughts?
>
> --
> Paul
>
> ___
> 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] Classifying roads from Trunk to Tertiary and Unclassified

[yo paseopor]

Sorry for this missunderstanding.
In Spain we have motorways (autopistas) and also we have motorways
(autovías). The problem goes with some roads (in some little moments can
have two lanes per direction) that does not fit the standards of an
"autovía or autopista" (bicycles, crossings at the same level -with no
bridges with roundabouts to avoid the direct crossing) with unpaved tracks,
no physical separation between directions... I assure you trunks are not
motorways here in Spain.
Our problems are first with same administrative classification (Nacional N-
roads) but with some of them there is little maintance and horrible
smoothness instead of newer constructions versus new roads done by
Country's government . Or with very good roads (infrastructures are good
pub for the government zone's so they publicate detailed projects with
these kind of information and previsions

Our physical classification would not be subjective:

-Is average speed statistics (here you can access and use this data for
free) subjective?
-Is Average Daily Traffic (ADT) data subjective?
-Is maximum speed subjective?
-Is the existence of bridges to avoid track crossings subjective?
-Is the restriction for some kinds of traffic (bikes) subjective?

No, they don't.

The signage will be ALWAYS represented by the first letter of the reference.

Also I want to attach some pics of these questions

https://imgur.com/R1xTsXu
C-37 in this section should be trunk: 100/80, interlevel (with bridges)
crossing with tracks, restricted access to bikes and agricultural
vehicles...
But it is not of Fomento (Country): it is from Generalitat de Catalunya
(State). So...it would not be the best level fro a road. Some people in
Spain thinks this should be primary for this last reason I have said. Some
trucks uses this to go to France by Pyrenees instead of paying AP-7 toll.

https://imgur.com/vXeELEN
CG 2.2 in this section also should be trunk: same case before. It is from
Xunta de Galicia (State), not Fomento (Country)

<http://goog_279443696>
https://imgur.com/FyRh0Je
N-260 in this section should be...secondary o tertiary: -of 50 maximum
speed, all traffic allowed, road marks are orientatives of the middle of
the road, two big cars does not fit at the same time ... But it is of
Fomento (Country) so some people thinks this should be trunk. No big trucks
use this section to travel around  Pyrenees. It is better to use whatever
other solution.

https://imgur.com/ejM93LR
N-340 in this section should be primary:50/60 maximum speed, all traffic
allowed but it is near the second city in population of Spain, Barcelona
and this is the alternative of AP-7. Also two cars fit in. It is of Fomento
(Country) so some people thinks this should be trunk.

https://imgur.com/3AaQzpS
T-340 in this section should be primary: 80/60 average speed, all traffic
allowed, crossings with tracks at the same level without no bridges. But it
is from Diputació de Tarragona (Province) so for some people this should be
secondary or tertiary. It is the main road to access to Delta de l'Ebre one
of the most important Natural Parks in Catalonia.

<http://goog_279443702>
https://imgur.com/y35kjmm
A-14 in this section should be motorway (autovía) . In Spain to be
"Autopista" you should to have these three things:
-No same-level crossings (without bridges and exits), no traffic signals
and roundabouts
-Minimum speed of 60 km/h
-Have two or more lanes per direction
-Strict criteria for access the way, from motorway junctions and not
directly.
When you don't cover one only of this criteria you are not Autopista , you
are Autovía (motorway also). Fomento decides in the majority of situations
convert their roads in motorways.

And yes Spain is different. I remember this https://imgur.com/mgfNbLs
between Liverpool and Manchester is a "trunk"... Here in Spain we don't
have this in a trunk for about...20 years.
Also other problem comes when you have a "Nacional" (administrative trunk)
and a parallel autovía (motorway). General traffic goes by motorway, so the
trunk has A.D.T. data more little than other secondary or primary roads of
the same zone (for this reason this section of the "Nacional" should be
tertiary. Well, in Catalonia we try it officially. Here it ICGC Catalan
Government (State) map:http://www.icc.cat/vissir3/index.html?DsebH9VpR
Fomento it is not agree with that: https://imgur.com/YH0GiWY
In this section there are not one but TWO motorways to avoid and pass the
city of Tarragona so tertiary is the most accurate category for this
section of "Nacional".

Openstreetmap should represent the reality of the place: you cannot avoid
the importance of some ways because they are from a little government. Or
in a reverse way: you cannot send the trucks via a sloped-curve-way because
it is "National"

Salut i carreteres (Health and roads)
yopaseopor























On Mon, Aug 12, 2019 at 12:35 PM Paul Allen

Re: [Tagging] Classifying roads from Trunk to Tertiary and Unclassified

[yo paseopor]

In Spain we have big problems, discussions and arguments with that
question. Last month, a French user complained about the state of a
"Nacional" (Country Main Road) classified in OSM as trunk.
These problems have one main reason. Here in Spain, in some places, there
are six degrees of public administration: European Union, Estado (Country),
Comunidades Autónomas (state), Provincia (province), Comarca (like county),
Municipio (like town)...and fourth of them have competences and decisions
about that.
Also some Comunidades Autónomas make better investments and spend more
money in some zones than Country government (because Country government
prefers to do only motorways all over Spain) . But as for more people
Country government is the most important (or the only important government
for the country) the majority of roads that depends of that government are
"defacto" the most important: trunk.
This is a mess and a disaster because you have some trunk roads
(nacionales) that don't deserve this category: roads with less width than
normal for two lanes,level crossings for all kind of tracks, passing-by
little villages,  horrible smoothness and with the same track as they were
created sixty or seventy years ago. Also you have good new 21st century
ways with only interlevel crossing, average speed of 80/100, big widths per
lane, but as they are from the government of the province ("Diputaciones")
or from the government of the "state" they are automatically primary ,
secondary or tertiary roads. This is not fair. Think about it: a government
will not spend its money in a road that is not really important.
Barcelona's Province Government manages about one thousand million euros
budget. So I assure you if  Barcelona's Province Government wants to build
a new road in a well-populated area this road would be as good as primary
or trunk.
Some people in OSM Spain want other classification criteria (not
administrative but physical) to make more objective the road classification:

trunk: 4,3,2-lane new roads (newer than twenty years, with new track), with
only interlevel crossings and exits, average speed of 80/100, and wide
lanes. It is possible bikes or agricultural vehicles would be prohibited in
these kind of ways.
primary: 3,2-lane main roads, with crossings at the same level, average
speed of 60/80, and wide lanes. All traffic should be allowed.
secondary: 3,2-lane roads, connecting small territories, crossings at the
same level, always with road marks , average speed of 50/60, acceptable
width per lane.
tertiary : 2-1-lane roads, with reference, it is not necessary to have road
marks, average speed of minus than 50, it is not necessary to have the
width of 2cars.
We want also to use governments data like average speed and average daily
traffic (ADT) . Objective data should be consulted to take these decisions.
We want to take consideration of all "Country government roads" that have
big motorways near to make lower they category. In the reference we will
always have the administrative classification like N- Country C- State
L-Local and others like CV-V for the town. One road can be trunk at first
kilometers with good track, etc. and then when sharing track with the free
motorway can be tertiary.
We also aware Spain is not the same as Australia or Africa , we know
classification criteria cannot be the same due to physical conditions in
other countries. But some of them we want a real and objective ,
non-repetitive classification criteria (using letters of the reference and
the same classification in OSM is the same, talking administratively) for
tagging Spanish Roads in Openstreetmap.

Salut i carreteres (Health and roads)
yopaseopor


On Sun, Aug 11, 2019 at 11:37 PM Paul Allen  wrote:

> On Sun, 11 Aug 2019 at 22:10, Graeme Fitzpatrick 
> wrote:
>
>>
>> In Australia, it's not uncommon for a Primary (& in some cases, Trunk!)
>> road to be a single lane dirt road!, & it would be nice to be able to show
>> them with the importance that they are to local residents of that area.
>>
>
> There appear to be two schools of thought on this.  One is that if it is
> the only road between A
> and B then it is a primary road, even if it's a single-lane dirt track.
> The other is to adopt
> a consistent country (or state, or region) wide classification, preferably
> adhering to official
> classification if there is any, which might mean that the only road
> between A and B is a
> secondary, tertiary or even quaternary road.
>
> I favour the latter approach.  If there is only one single-lane track
> between A and B then
> it is obviously of importance to those in the area without it needing to
> be emphasised by
> a different colour.  Whereas rendering it as a primary road will mislead
> some people
> planning a cross-country trip into think it's paved highway all the way,
> including the
> final part of their trip from A to B.
>
> I suggest that before you decide which approach best suits your country
> you first check
> if 

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[yo paseopor]

On Sat, Aug 3, 2019 at 9:24 PM Markus  wrote:

> Hi!
>
> On Sat, 3 Aug 2019 at 20:38, yo paseopor  wrote:
> >
> > We need a new way of following the scheme. I think all the features are
> needed: stop positions, platforms and stop area. [...]
>
> Could you please give me an example where stop positions are needed?
>

Trains stops in a specific point. Here in Spain they have some sign that
says=Cabeza de tren (Head's line) . It is important because when you do a
map that can be used by the public transport user, but also the
public_transport driver you should have the two positions. OSM data can be
infinite and can be professional. Also you have people saying in this
thread for manage in a semiautomatic way the transport lines data is
necessary these thow kind of points

> In my experience, mapping stop positions and stop areas is only very
> time-consuming (without a benefit), but also makes maintaining the
> routes harder. (Of course, stop areas are helpful at stations,
> especially at subway stations, in order connect the entrances to the
> station.)
>
> > We should deprecate all kind of stuff for public transport who does not
> not have the public transport tag itself. Because a platform has no sense
> if is not for public_transport. No more highway=platform, railway=platform,
> seaway=platform, river=platform.
>
> Apart from the fact that seaway=platform and river=platform don't
> exist,

Sure? Is not there public_transport by sea, by river, by lake? Will be not
ever?
Public transport scheme is a good scheme for present but also for the
future. When you will have Uber flying cabs which scheme will you will have
we invent in a few years? With this proposal only one: flying_cab=yes



> highway=platform and/or railway=platform are needed, because
> public_transport=platform doesn't mean a platform, but a waiting area.
> And a waiting areas doesn't need to be a platform: some waiting areas
> are just poles or signs beside the road [1], others are located on the
> sidewalk [2]. Besides, there are platforms that aren't operated
> (anymore) and therefore aren't waiting areas, that is
> public_transport=platform's, anymore.
>

Well this is an error. For mi public_transport=platform should be a real
platform. It has no sense to have an irreal tag.
In the stop_position tag you can assure this with platform=yes or
platform=no.

>
> [1]: https://www.mapillary.com/map/im/WzQODhqrCxxBLTYj2YJ-8g
> [2]: https://www.mapillary.com/map/im/9HJR2HmtsEPsPVDV682kZQ
>
> Regards
>
> Markus
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


Salut i transport públic (health and public transport)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[yo paseopor]

We need a new way of following the scheme. I think all the features are
needed: stop positions, platforms and stop area.Well , at first sight would
seem complicated...but if you want to map a big station you have to use a
complicated system. And this system when you know how it works it is fast
and easy to follow. Because all kind of public transport would be mapped in
the same way. If it is bus? bus=yes. If it is also tram? tram=yes

We should deprecate all kind of stuff for public transport who does not not
have the public transport tag itself. Because a platform has no sense if is
not for public_transport. No more highway=platform, railway=platform,
seaway=platform, river=platform. Forget about the environment: it is a
platform for public transport. And that's it.
Also we should deprecate all the highway=bus_stop (because you have
public_transport=stop_position ), al the halts in a railway, etc...And all
these kind of things would be only public_transport=stop_position.

With this system you can catch an airport and make it a
public_transport=stop_position, for the planes. It is a powerful scheme,
and you only have to know one key and four or five values. You will never
ever misspelled the writing of bus stop? bus_stop? stop_for_bus? for what?
highway?railway?aerialway?seaway?riverway?

We should use scalable and easy of tagging schemes, should we?

Salut i transport public (health and public transport)
yopaseopor

On Sat, Aug 3, 2019 at 11:53 AM Jo  wrote:

> For a few years now, I've been considering to make a proposal for mapping
> PT in a simpler way. I haven't done it because it's a lot of work and there
> will always be quite a few mappers who prefer the status quo.
>
> Anyway, I think we need 1 object which has all the properties of a stop as
> tags and which is used in the route relations. A single object per stop,
> preferably not 2 for each stop.
>
> That part I've been pushing it slowly all along.
>
> Regarding the itineraries, I think we should also start looking into how
> we can simplify that in such a way that maintenance becomes easier for the
> mappers.
>
> So what if a route relation would consist of an ordered set of stops and a
> link to another relation for the itinerary. This other relation contains
> only relations. Those relations contain the ways for a 'segment' or an
> 'edge'. It's these small relations that get broken occasionally when
> mappers split or combine ways. When this happens only those relations need
> to be fixed and the effect will be that all the itineraries that use them
> are fixed in one go.
>
> There is more 'indirection', which may seem more complex at first sight,
> but we can create tools to visualise the effect of the combined set of
> relations in JOSM and I guess it can be done in iD as well.
>
> As far as maintenance goes, this would simplify matters a lot.
>
> Let me know if you think it makes sense to start a proposal for this. The
> student who works on PT_Assistant this summer is laying the groundwork for
> going into this direction.
>
> Polyglot
>
>
> On Sat, Aug 3, 2019 at 11:33 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Re: > The relation needs both stops and ways
>>
>> Sure, it's nice for rendering the have the ways, but it's not always
>> necessary.
>>
>> There are 2 cases where you can only do one or the other
>>
>> 1) Stops only: The buses don't always take the same route between
>> stops, but just take whatever way is fastest. This is common for
>> long-distance buses between towns, and in non-Western countries for
>> all sorts of buses. In this case, just the stops are needed.
>>
>> 2) Ways only: the bus follows the same streets, but will stop
>> anywhere. This is the standard for all minibuses in Indonesia, and in
>> many other countries. In this case there are no bus stops, except at
>> the start and end of the route.
>>
>> It's great to include both when possible, but I think it we should let
>> new mappers know that they can just start with stops or just start
>> with the ways, if that's all they know.
>>
>> On 8/3/19, Warin <61sundow...@gmail.com> wrote:
>> > On 03/08/19 11:19, Joseph Eisenberg wrote:
>> >> Yes, the only thing that needs to be changed is the documentation, in
>> >> my opinion. We don't need more tags, and it's not even necessary to
>> >> officially "deprecate" anything.
>> >>
>> >> Right now some pages suggest that a bus stop needs to be tagged
>> >> highway=bus_stop + public_transport=platform + bus=yes at the location
>> >> passengers wait, and that you also need a
>> >> public_transport=stop_position + bus=yes next to this point (on the
>> >> highway), and a type=public_transport relation with *=stop_area, which
>> >> includes the 2 features, and maybe they all need a name or ref? Oh,
>> >> and you need to make a type=route relation which includes at least one
>> >> of these features, or maybe all of them, in addition to highway ways?
>> >>
>> >> That's 3 features with at least 10 tags, to 

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[yo paseopor]

Yes, one ring (one key=one value) for all kind of public transports because
it is easier to say this key and then what kind of transport do you have in.

It's better:

public_transport=stop_position or
public_transport=platform
and then bus,tram,train,subway,ferry,helicopter,UFO, future's
vehicles...=yes

than

highway=bus_stop
railway=platform
railway=tram_stop
bus_bay=yes
ferry=station
whatever we have to invent in the future=*
...

Also I think if you want to map some complex situations you cannot use only
one node for all of them, as we don't use it in banks and atm's.
Stop_area and stop_area_group are working well with big interchange
stations.
There are 223000+ stop_area relations. And there are 4400+ stop_area_group
relations, should we deprecate them? If you think there is no use about
these tags. Please visit taginfo.
We have a small Mediterranean town called ... Barcelona that uses this
transport scheme and we don't have any problem. You can see it at Osmand,
Maps.me or OPVNkarte.

The only negative point for public transport v2 scheme was the
no-deprecation of the old scheme to avoid duplicities (surely was done this
to don't uncomfort people)
Salut i transport públic (Health and public_transport)
yopaseopor


On Thu, Aug 1, 2019 at 2:39 AM Warin <61sundow...@gmail.com> wrote:

> Ferries also seam to be forgotten...
>
> public_transport=platform??? Covers ferry, bus, train, trams ... ??
>
> (One ring to rule them all etc)
>
> With regard to ref. I have bus stops that have 'Stand A' etc near train
> stations. these also carry a reference number that is used by the transport
> company - they are handy if you knowthem as you can type that in as your
> destination or start for there website on finding a trip scheduled/fee.
> Discussion on the Australian list resulted in this
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Bus_Stop_names_and_references
>
>
>
> On 31/07/19 22:43, Jo wrote:
>
> bus_bay = right | left | both (
> https://www.openstreetmap.org/way/485293336  )
>
> For me the object that represents the bus stop, is always a simple node. I
> don't see a problem for doing that in bus stations as well.
>
> If there are actual platforms, whether in a bus station or somewhere along
> a way, it can be tagged:
>
> highway=platform (https://www.openstreetmap.org/way/304753571)
>
> or
>
> or railway=platform (https://www.openstreetmap.org/way/255344359)
>
> for trams.
>
> on a way.
>
> These ways don't get the ref, name, route_ref, zone, local_ref, operator,
> network, and so on, those go on the node that represents the bus stop. Only
> that node needs to be added to the route relations. It doesn't get any
> simpler than that.
>
>
> Good. I can see no benefit to adding additional information to the route.
> Things like shelters, toilets etc all become evident when the map is
> viewed. The routeing information does not need it.
>
>
> https://www.openstreetmap.org/node/576656712  (example of a bus stop
> served by 3 different operators near Brussels, I only put
> public_transport=platform, bus=yes because for a few years that seemed like
> the right thing to do. Today I wouldn't mind removing those 2 tags once
> again.)
>
> Those platform ways could get:
>
> tactile_paving=yes
> wheelchair=yes
> height=
>
> So there is no real conflict between highway=bus_stop or railway=tram_stop
> on a node
>
> and
>
> highway=platform or railway=platform on a way or an area.
>
> Polyglot
>
> On Wed, Jul 31, 2019 at 2:13 PM Paul Allen  wrote:
>
>> On Wed, 31 Jul 2019 at 12:52, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Agreed, there are enough tags for public transport already. I don't
>>> think anything new is needed.
>>>
>>
>> There's something I haven't found a way of mapping.  That's a bus stop
>> where there's a bay
>> inlet into the pavement (aka sidewalk, aka causeway).  If it served a
>> different purpose and
>> had different road markings, it could be a lay-by (aka rest area) or a
>> parking bay.  But it's a
>> bus stop where the bus does not obstruct the flow of traffic.  There are
>> four of those in
>> my town, that I can think of (there may be others I've missed).
>>
>> Yes, I could use area:highway or add area=yes to a closed way, but those
>> don't seem to render
>> on a popular, well-known carto intended for mappers to check their work
>> for anything but
>> pedestrian ways.
>>
>> Is there a way of doing it that I've missed?  If not, could we have one?
>>
>> Example: https://www.openstreetmap.org/edit#map=20/52.08760/-4.65318
>>
>> --
>> Paul
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> 

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[yo paseopor]

please: NO MORE TAGS
Either... can we mix all the tags of all the versions of Public transport
into a UNIQUE scheme for ALL kinds of transports, tagging it at the same
way with the same name: from electric autonomous buses to new Uber's
helicopters?
A scheme has to be scalable. Can we define that? Can we design that?
-Basic parts
-Basic tags
-Basic values

And then... some kind of automated conversion of tags done by local
communities, with specific instructions at the wiki. Also tag as deprecated
all the old mixed stuff.

What do you think?
Salut i mapes (health and maps)
yopaseopor


On Wed, Jul 31, 2019 at 10:37 AM Markus  wrote:

> Hi Joseph
>
> On Tue, 30 Jul 2019 at 15:59, Joseph Eisenberg
>  wrote:
> >
> > I still haven't seen any benefit in adding public_transport=platform
> > to highway=bus_stop or highway=platform or railway=platform features,
> > and it doesn't look like the =stop_position tag is needed for routers
> > either, so all 3 of the main public_transport tags (except perhaps the
> > stop_area relation?) are rarely helpful.
>
> I agree, and it seems that most people that took part in this long
> discussion [1] i initiated in April about improving public transport
> mapping agreed too.
>
> [1]:
> https://lists.openstreetmap.org/pipermail/talk-transit/2019-April/002052.html
>
> While highway=bus_stop works in most simpler cases, it doesn't work
> very well for bus stations. For example, consider this simplified map
> of the postbus station in Bern. [2]
>
> [2]: https://wiki.openstreetmap.org/wiki/File:Postautostation_Bern.svg
>
> It consists of seven platforms, numbered 1–7, and a mere pole on the
> sidewalk with the number 8. As highway=bus_stop and highway=platform
> both use the the highway=* key and thus can't be combined, for every
> platform i would need to map a highway=platform and a highway=bus_stop
> object. But which one should get the ref=*? Both? And which one should
> be added to the route relation? Usually highway=bus_stop is added to
> the route relation, but for trains, it is the platform.
>
> A possible solution of this problem were to invent a new tag for
> stops, which doesn't use the highway=* or railway=* key and thus can
> be combined with highway/railway=platform (e.g. public_transport=stop;
> or, alternatively, a new tag for platforms). However, i haven't got
> any feedback on that idea, so i don't know whether the community would
> accept such a change in tagging.
>
> Regards
>
> Markus
>
> ___
> 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] lanes = 0

[yo paseopor]

 Also when they are a passable, two way road?
BOE-020_Codigo_de_Trafico_y_Seguridad_Vial
Page 50
 Carril. Banda longitudinal en que puede estar subdividida la calzada,
delimitada o no por marcas viales longitudinales, siempre que tenga una
anchura suficiente para permitir la circulación de una fila de automóviles
que no sean motocicletas.

 It is the place of the road , limited or not by marks , that has
sufficient width to fit a row of motor vehicles (not motorcycles).
In a road, if you can fit a row of motor vehicles, then , in Spain,  it is
a lane.

So...
lane=1
oneway=no
could be possible

Also if you have the width to fit a motor vehicle it is a lane so...

In a road lane=0 is not possible in Spain

Salut i carrils (Health and lanes)
yopaseopor

On Mon, Jun 24, 2019 at 1:41 PM Allroads  wrote:

> So there are lanes and virtual lanes.
>
> We must make a good distinction, I must be able to see immediately,
> whether I am dealing with a marked lane or a virtual lane, that has no
> marking.
>
> Do not expect from a mapper, at a marked lane, also to set  marked = yes.
> (or else) to make the distinction.
> See wikipedia and else, there all marked.
>
> A two-way road without a marking in our country, does not have lanes!
> (law). Although, you can pass each other. There, we could have also a new
> tagcombination! But not lanes=* , these are marked! (law)
> To make a good distinction, it must be immediately clear.
>
> What do you think of:
>
>
>
> lanes: virtual = (number),   lanes that have no markings. Not a second tag
> needed.
>
> The same method as there is used highway: virtual = pedestrian, to make a
> route line over a pedestrian area. Or over a field, a beach.
>
> You could say, lanes are created in the UK, lanes are created in OSM,
> these lanes where written down as marked lanes, to use lanes=* for virtual
> lanes was a abuse of the tag lanes=* , if you do use it, you make the
> definition unclear and that should be avoided, there is a new tag needed.
> Problem solved.
>
>
>
>
>
> Quote: yo_paseopor
> In Spain is easy: when there is no marks =  lanes=1
>
> Also when they are a passable, two way road?
>
> When there are no marking there are no lanes.
> lanes=1, like on a highway link, is indicating one way, one direction.
>
> A lot of lanes=1 are deleted in our country, because they are not a lane
> (rijstrook)(law).
>
>
> Allroads.
>
> ___
> 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] lanes = 0

[yo paseopor]

In Spain is easy: when there is no marks =  lanes=1
The lack of the mark lanes is the reason why when a Spaniard drives by Rome
thinks Italian people are crazy, because they overtake you in the same big
lane, but ONLY one lane (lane without marks). One lane= one car.
lane with no marks is =1 (driver's school book says that) so lane=0 would
be impossible and ununderstable for a Spaniard wherever in the World.

Cheers
Yopaseopor



On Sat, Jun 15, 2019 at 6:59 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 15. Jun 2019, at 01:10, Joseph Eisenberg 
> wrote:
> >
> > This requirement is fine for Europe, but the presence of lane markings
> > is not reliable in all of the world.
> >
> > In developing countries, such as here in Indonesia, the presence of
> > painted lane markings is inconsistent. Often cheap pain is used
> > instead of more durable thermoplastic, so the markings only last a
> > year. After that the road still functions the same, even though the
> > markings are no longer visible.
> >
> > There are also sections of primary or trunk road that are at least 6
> > or 7 meters wide and freshly painted, but have not yet been marked and
> > may not be for a number of years. I tag these as lanes=2 because the
> > road is clearly wide enough for two lanes.
> >
> > And here in town the main road was recently marked with 2 lanes in
> > each direction, but before it already functioned as 4 lanes because
> > the width was sufficient.
> >
> > While tagging the width is useful, I believe tagging the presence of
> > "de facto" lanes is reasonable in developing countries and places
> > where painted lane markings are not frequently used.
>
>
>
> This description is a perfect fit for the situation in central Italy as
> well, not having marked lanes can happen on 2+2 roads for years and for
> many kilometers. Often there are lane markings for some part of the road
> while they are missing on others. Generally they are aiming at having
> lanes, but it isn’t pursued with high priority ;-)
> I can understand the argument that lanes have to be painted in order to be
> there, but it isn’t the reality I am observing.
>
> We shouldn’t dismiss lane_markings=no as it can solve both cases: no lanes
> marked but lanes=n is set, and no lanes tag set (confirmation the tag
> wasn’t forgotten).
>
> 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

[Tagging] New way to use tagging: simple questions with no prep_discussion: tag for a IT School ?

[yo paseopor]

Hi!
Whats is the tag for a IT school like this?
http://www.mecabit.com/

Thanks
yopaseopor

PD: education scheme has to be improved. A non-schoolar education scheme
would be interesting.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

No, don't be innocent

If you search traffic light you will see the same thing, not any strange
light in relation with traffic itself.
https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
https://en.wikipedia.org/wiki/Traffic_light.
If you make a specific micromapping you will not have problems. Otherwise
you can't ask for detailed information if the mapping is not as detailed.

If you see a traffic light in a footway is for the footway, not the highway.
If you see a traffic light in a cycleway is for the cycleway, not the
highway.

There is no ambiguosity: point is where is the feature, where the feature
acts.

Why you suppose marked is better than uncontrolled? Do you suppose that new
mapper doesn't know for which kind of marks are you talk about? Marked
with? Traffic sign? Traffic light? other lights in the traffic?

Crossing tag scheme is based ...on the marks and other items you will have:
traffic_signals, supervised=yes, uncontrolled (but marked), unmarked, no
(prohibited). If you put a crossing=marked...what do you mean? , which of
them do will you substitute?

Uncontrolled means NO CONTROL. A mark is not a control. A sign is not a
control (when yes, when no). Supervised means with supervision, traffic
signals with traffic light. Unmarked...what do you expect about control if
there is not any mark.

You had said " As someone who has personally mapped thousands of crossings,
the current schema is absolute garbage for reliably collecting accurate
data that can be reliably interpreted by data consumers that aren't solely
focused on car routing."
No, if the crossing is in a footway  you will have info about the footway,
not only for cars. In Openstreetmap there is a lot of tagging schemes who
thinks far away from cars only: kerbs, sidewalks, wheelchair...Use it also,
not only crossings.

> The iD editor never uses crossing=uncontrolled. It actually uses
crossing=marked now.
Well, I think it is a big error, because there is no marked values at the
wiki and you have the same thing with the value uncontrolled in the wiki.

>I anticipate that many US-based communities would be open to converting
crossing=uncontrolled and crossing=zebra to crossing=marked, at a minimum,
given how frequently they've been edited with iD.
I don't why US-based communities would not be open to converting
crossing=zebra (which does not exists, is crossing_ref= if you read the
wiki) to crossing=uncontrolled that is the value you can read in the wiki
instead of mix values and tags to create a new scheme.

>A controlled crossing can have or lack ground markings, and an
uncontrolled can have or lack ground markings.
Yes, but it has no-sense . Why control one thing that you don't indicate by
any way. First make it visible, then control it.

> In your country, how do you map a crossing that has traffic controls but
does not have markings on the ground?
It does not exists and I have to say I don't remember see this in the rest
of Europe I have visited.

Tagging schemes with yes/no binary values makes more complex the
scheme...yes there is only two possible values...but then you have to have
three different tags for the same thing.Yes, the scheme you are proposing
here will have more descriptional tags...but also have three more time tags
than the existing one with the same information.

> Map a crossing that is unmarked and has pedestrian signals ("walk"/"do
not walk").
That is a traffic light for pedestrian. Why do you want any mark if you
have a traffic light to control it? In my country...that situation does not
exist.

> Map a crossing that is marked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
That is crossing=uncontrolled, because there is no control about the
footway crossing.

> Map a crossing that is unmarked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
Well , it is crossing=unmarked because there is no marks on the corssing. A
stop sign is about the highway cross with other way, nothing to have
relation with a pedestrian crossing, otherwise you will have other kind of
traffic sign, not Stop.

> Map a crossing that is unmarked and is protected by its own,
non-street-intersection traffic light, then say how you would interpret
this as a data consumer.
Well, it will be a crossing=unmarked, because there is no mark on the
ground, also I say in my country you have avoided to cross by there except
in residential streets (the one's with the same level on sidewalk and the
road itself )

> Map a crossing that is unmarked, has pedestrian-specific signals
("walk"/"do not walk"), but no traffic signals at all nearby.
WTF? For what do you need walk/don't walk parameter if there is no traffic
light with???

> Map a crossing that has markings and is protected by a traffic light, but
that traffic light is part of the overall highway=traffic_signals

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

should be separate questions a
> mapper can easily answer: does the crossing have markings? Does the
> crossing have a pedestrian signal? Does the crossing have a "controlled"
> status (or, perhaps better, this can be inferred from other properties like
> crossing_ref, because nobody has any idea what "controlled" means,
> apparently)?
>
> > If there is a traffic island in the crossing you can tag
> traffic_calming=island (you can read in the wiki crossing=island is a  broken
> tagging scheme .
>
> Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag.
> The two proposals I've announced are related to breaking out these
> non-orthogonal crossings tags, similar to crossing=island. However,
> traffic_calming=island describes the island itself. For a pedestrian way,
> use crossing:island=yes.
>
> > And then there are the crossing_ref
>
> This is outside the scope of this proposal, aside from the fact that if
> crossing=marked is used, it creates an opportunity to use a straightforward
> subtag for different marking types that are currently tagged as
> crossing_ref. Try explaining to virtually anyone why the crossing type is
> called, "crossing_ref". What's a ref? What does it mean to apply a ref to a
> crossing? With that said, this proposal does not hinge on this, it's just
> an opportunity for a different proposal down the line.
>
> > But there is no crossing=zebra or crossing=marked.
>
> I mean, they are in current use, but putting that aside, that is the point
> of this proposal: we should be using a specific tag for markings.
>
> > I know some editor software and renders are very important for OSM, but
> doing whatever you want avoiding community consensus can generate these
> problems.
>
> I'm attempting to build community consensus by writing a proposal and then
> explaining it on this mailing list.
>
> > Are you sure we need a new tagging scheme for crossings?
>
> I am absolutely positive.
>
> > Are you sure there is not other existing way to map whatever you want
> with the present tagging scheme?
>
> Yes, and I've tried many, many times.
>
> Best,
>
> Nick
>
> On Wed, May 8, 2019 at 10:38 AM yo paseopor  wrote:
>
>> I don't know why we need a new tag scheme.
>>
>> I remember my explanation of the question and the adaptation of the
>> possibilities. I repeat them here:
>>
>> crossing=no (prohibited)
>> crossing=yes (most generic)
>>
>> crossing=traffic_light is with traffic lights. So implies
>> crossing=controlled.
>> crossing=controlled is with traffic signs or with police people or
>> similar (it does not matter the marks because of the laws. Traffic signs
>> are more important than road marks, and, in conflict you have to obey the
>> traffic sign not the road mark.)
>> crossing=uncontrolled but with marks. So one of them implies
>> crossing=uncontrolled
>> crossing=unmarked with no marks, with no control, but crossing
>>
>> If there is a traffic island in the crossing you can tag
>> traffic_calming=island (you can read in the wiki crossing=island is a  broken
>> tagging scheme .
>>
>> And then there are the crossing_ref
>>
>> zebra is marked but uncontrolled (if it is controlled you can use other
>> value)
>> pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
>> pelican and panda is only with traffic lights .Pelican is the evolution
>> of panda
>> tigger means bicycle=designated and toucan means bicycle=yes.
>> pegasus means horse=designated
>>  (all of these are from U.K.)
>>
>> But there is no crossing=zebra or crossing=marked.
>> I know some editor software and renders are very important for OSM, but
>> doing whatever you want avoiding community consensus can generate these
>> problems.
>> Are you sure we need a new tagging scheme for crossings? Are you sure
>> there is not other existing way to map whatever you want with the present
>> tagging scheme?
>>
>> I don't think so
>> Health and maps (Salut i mapes)
>> yopaseopor
>>
>>
>> On Wed, May 8, 2019 at 10:51 AM marc marc 
>> wrote:
>>
>>> Le 07.05.19 à 22:57, Nick Bolten a écrit :
>>> > - crossing=* values are not truly orthogonal and this needs to be
>>> > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
>>> > not truly orthogonal descriptors.
>>>
>>> I suggest that you read the discussion I started in December about
>>> crossing=zebra because it is the main cause of the curre

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the
possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies
crossing=controlled.
crossing=controlled is with traffic signs or with police people or similar
(it does not matter the marks because of the laws. Traffic signs are more
important than road marks, and, in conflict you have to obey the traffic
sign not the road mark.)
crossing=uncontrolled but with marks. So one of them implies
crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag
traffic_calming=island (you can read in the wiki crossing=island is a  broken
tagging scheme .

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other
value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of
panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but
doing whatever you want avoiding community consensus can generate these
problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there
is not other existing way to map whatever you want with the present tagging
scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc  wrote:

> Le 07.05.19 à 22:57, Nick Bolten a écrit :
> > - crossing=* values are not truly orthogonal and this needs to be
> > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> > not truly orthogonal descriptors.
>
> I suggest that you read the discussion I started in December about
> crossing=zebra because it is the main cause of the current situation.
> Bryan replaced crossing=zebra with crossing=marked in iD but as the
> crossing=zebra problems were not understood, the alternative has exactly
> the same problems as the replaced solution.
> the crossing key is however simple to use except for badly chosen values
> does the passage have a fire? crossing=traffic_signals
> otherwise, does the passage have a marking on the ground?
> crossing=uncontrolled (the work is not perfect because a marking a kind
> of controll)
> otherwise crossing=unmarked
>
> >- There is fragmentation in tag usage for marked crossings between
> > "zebra" and "uncontrolled".
>
> Last year, I have review ~1k crossing=zebra,
> the fragmentation is mainly due to iD
>
> >- crossing=marked is direct and clear about its meaning and use cases.
>
> for now, the "new" iD preset destroys perfectly valid data
> at a frightening rate!
> if someone modifies a pedestrian crossing with a light, iD replaces it
> with crossing=marked, which disrupts the information of the presence of
> the light.
> There is already a tag for the reference of a crossing.
> if the reference is not known, it would be easy to use crossing_ref=yes
> as it is done with many keys.
>
> > - crossing=marked is already in use and supported by various editors,
> > including being the default in iD
>
> a bad preset is not a good usage
>
> Regards,
> Marc
> ___
> 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] Possibility to draw parking properties as an area

[yo paseopor]

Ok , ok, if it is fine I will tag parking zones at the streets with amenity
parking and the properties of parking lanes

Thank you for your attention
yopaseopor

PD: When I have said "parking lane is not a parking" I mean a parking lot,
a big parking zone not in the middle of a street. Sorry for my bad English
;)

On Wed, Mar 6, 2019 at 7:52 PM Mateusz Konieczny 
wrote:

> What is the reason for not tagging it as an area?
>
> This seems to mix drawbacks of tagging as area and as a tag on road:
> - geometry is not mapped
> - it is complicated to match it to a road
> - not handled by most of data consumers
> - highly unusual tagging
>
> Mar 6, 2019, 7:14 PM by pla16...@gmail.com:
>
> On Wed, 6 Mar 2019 at 17:49, yo paseopor  wrote:
>
> I mean something like https://www.openstreetmap.org/way/675000355
> or https://www.openstreetmap.org/way/675000354
> or https://www.openstreetmap.org/way/67500085
> <https://www.openstreetmap.org/way/675000856>
>
>
> Which look, in the editor, exactly like the examples I gave links to.  So
> what's wrong with the
> solution I used?  I can't remember where I got the idea from, but I
> probably found it somewhere
> in the wiki or suggested in one of the forums.  It handles the situation
> well.  It's a parking area
> which has one side contiguous with the road.  Big advantages: it renders
> and it shows a P
> symbol.  What more do you want?
>
> --
> Paul
>
>
> ___
> 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] Possibility to draw parking properties as an area

[yo paseopor]

I think it is not correct. Parking zones in a street are not
amenity=parking , are they? It would be very interesting solution...but
parking zone in a street is not a parking (an specific place for park).
Parking spaces would fit correctly, but as you can see not all the parkings
zones have drawn all the parking spaces.
I wish to use standard parking:lane properties...but not with
amenity=parking tag...or is it a correct use?

Salut i mapes
yopaseopor

On Wed, Mar 6, 2019 at 7:15 PM Paul Allen  wrote:

> On Wed, 6 Mar 2019 at 17:49, yo paseopor  wrote:
>
>> I mean something like https://www.openstreetmap.org/way/675000355
>> or https://www.openstreetmap.org/way/675000354
>> or https://www.openstreetmap.org/way/67500085
>> <https://www.openstreetmap.org/way/675000856>
>>
>
> Which look, in the editor, exactly like the examples I gave links to.  So
> what's wrong with the
> solution I used?  I can't remember where I got the idea from, but I
> probably found it somewhere
> in the wiki or suggested in one of the forums.  It handles the situation
> well.  It's a parking area
> which has one side contiguous with the road.  Big advantages: it renders
> and it shows a P
> symbol.  What more do you want?
>
> --
> Paul
>
> ___
> 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] Possibility to draw parking properties as an area

[yo paseopor]

Sorry...but parking space is not a lane, lanes are for driving. You cannot
drive by a "parking lane". Lane has differents meanings. You can see the
difference in Spanish: Carril para circular, Zona de aparcamiento. It does
not exist Carril de aparcamiento.
Also adding parkign properties to the kerbs...does not help anything (it
would be the same problem we have now. I need these items separated from
the way, from the kerb, with its own id, to draw exactly what space is
occuping.

Salut i mapes
yopaseopor


On Wed, Mar 6, 2019 at 7:01 PM Jmapb  wrote:

> On 3/6/2019 12:04 PM, yo paseopor wrote:
> > Not only parking_space but all the parking you can find in a street,
> > not a parking lot or a parking place (amenity=parking). I say I need
> > to separate and zoom the info about parking spaces (but not delimited
> > every place) in each street.
> > Parking is not a lane of the street so I want to draw it separately as
> > an area or as a way.This also would be useful for draw disabled
> > parking spaces.
> >
> > All would be inside a relation with all the other pieces of the
> > street: kerb,the road itself, sidewalks...
>
> Some definitely do consider street parking to be a "lane", see
> https://wiki.openstreetmap.org/wiki/Key:parking:lane for elaborate
> tagging examples.
>
> With all the talk about drawing road kerbs as ways, I imagine a proposal
> to encode street parking info as properties of the kerb (rather than of
> the street) will be forthcoming.
>
> J
>
>
> ___
> 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] Possibility to draw parking properties as an area

[yo paseopor]

I mean something like https://www.openstreetmap.org/way/675000355
or https://www.openstreetmap.org/way/675000354
or https://www.openstreetmap.org/way/675000856

Salut i mapes
yopaseopor

On Wed, Mar 6, 2019 at 6:26 PM Paul Allen  wrote:

> On Wed, 6 Mar 2019 at 17:06, yo paseopor  wrote:
>
>> Not only parking_space but all the parking you can find in a street, not
>> a parking lot or a parking place (amenity=parking). I say I need to
>> separate and zoom the info about parking spaces (but not delimited every
>> place) in each street.
>> Parking is not a lane of the street so I want to draw it separately as an
>> area or as a way.This also would be useful for draw disabled parking spaces.
>>
>
> Do you mean something like this
> https://www.openstreetmap.org/way/664700547 or this
> https://www.openstreetmap.org/way/525946296
>
> --
> Paul
>
>
>> All would be inside a relation with all the other pieces of the street:
>> kerb,the road itself, sidewalks...
>>
>> Salut i mapes
>> yopaseopor
>>
>>
>> On Wed, Mar 6, 2019 at 7:17 AM OSMDoudou <
>> 19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>
>>> Parking spaces, you mean ?
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space
>>> ___
>>> 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] Possibility to draw parking properties as an area

[yo paseopor]

Not only parking_space but all the parking you can find in a street, not a
parking lot or a parking place (amenity=parking). I say I need to separate
and zoom the info about parking spaces (but not delimited every place) in
each street.
Parking is not a lane of the street so I want to draw it separately as an
area or as a way.This also would be useful for draw disabled parking spaces.

All would be inside a relation with all the other pieces of the street:
kerb,the road itself, sidewalks...

Salut i mapes
yopaseopor


On Wed, Mar 6, 2019 at 7:17 AM OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

> Parking spaces, you mean ?
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space
> ___
> 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] Possibility to draw parking properties as an area

[yo paseopor]

Moment has arrived.
I need the use of the tagging scheme into a separated items (not only the
highway itself) to make possible the draw of specific parking areas (or
spaces if it is specified) in the streets with their properties exactly
drawn as areas or ways.
I assume also the position about the use of some relation called
associatedStreet to "join" the different items we talk last days: the road
itself,the parking area (if it is) the cycleway it is associated, the kerb,
the sidewalk, the traffic signs...and so on.

What do you think?
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

[yo paseopor]

It is the same story again and again.

-First was the node and ways. And some classification . It was not enough
-Second arrived relations. but when you want to specify more..it is not
enough
-Then it was other tags like classification, lanes, sidewalks...  it is not
enough if you want to make all the details.
-Then arrived the area mapping to make it more realistic. But only for some
items as sidewalks.
Congrats , now we need the detail of a kerb drawed as an area.

I think best way at first is using the same tagging we have for kerb
https://wiki.openstreetmap.org/wiki/Key:kerb
https://taginfo.openstreetmap.org/search?q=kerb#keys

Then...you know you will need more tags...cuz it is not enough ;)
PD: don't map for the render (instead it would be OSM official's one). All
real info is welcomed

Salut i mapes
yopaseopor

On Sun, Mar 3, 2019 at 8:13 PM Nick Bolten  wrote:

> A recent post on the Mapillary blog (
> https://blog.mapillary.com/update/2019/02/12/potential-for-openstreetmap-to-seize-the-curb.html)
> reminded me of my long-running wish to have more curb lines mapped, so I
> wanted to get a discussion started to see what people think of mapping
> curbs as ways.
>
> The short version is this: if we put kerb=* on a line and call it its own
> feature, what's the best tagging schema to use and what kind of additional
> information is appropriate? Personally, I'd like to use (and recommend) the
> existing kerb=* tags around blocks and potentially add parking information.
>
> Potential mapping and data use cases:
>
> - Public parking data: curbs are already marked with parking / stopping
> information, and when motor vehicles stop at a curb they are meant to
> follow the local regulations regarding access. Curbs seem like a natural
> place to store this information: you can split the way whenever the parking
> situation differs or where there are dedicated parking slots. It is
> attractive to associate streets with parking information, but if one were
> to split street ways whenever parking information changed, every city block
> would become an incomprehensible, split-up mess.
>
> - Streets as areas: there are a few schemas out there about mapping
> streets and related features as areas, primarily for rendering purposes.
> Mapping the curb is fully compatible with, and part of, these proposals,
> and could provide a means of building up to fully mapping contiguous areas.
>
> - Pedestrian crossings. I would be very excited to map out kerb=* ways
> around every block I see, because it makes QA (and even safe,
> semi-automated edits) for pedestrian accessibility so easy. All a validator
> has to do is check that a highway=footway crosses a kerb=* way and lacks
> its own kerb=* node. This is similar to the validators already used in JOSM
> and iD that check for things like a footway or street intersecting a
> building, reminding users to use covered=* or tunnel=*.
>
> - Pedestrian islands. These are often just an assembly of raised curbs
> intended to protect pedestrians that are doing a multi-part crossing of a
> street or streets.
>
> - Opportunity to merge with + simplify micromapped stairs: what are stairs
> but a series of carefully-raised "curbs"? I've seen various proposals
> regarding how one might map large, beautiful, public stairways. This is a
> whole can of worms, but the information in describing a physical curb is
> essentially the same as describing any 'stuff on the right is higher than
> stuff on the left' interface.
>
> 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

[Tagging] crossing=cycleway as a node

[yo paseopor]

Hi!

Now I'm tagging with the more detail I can some cycleways in Catalonia. I
do al the ways, and I cut and mark all the crossings. I do this with the
formula
highway=cycleway
cycleway=crossing
as a way (like I do other times with
highway=footway
footway=crossing
for mark all the pedestrian crossing. But I have a dilemma. When I want to
tag the exact point in the cycleway crossing with the road I would use
highway=crossing
crossing=uncontrolled
...but it is not so detailed enough so I think about a
crossing=cycleway
to mark this exact point...but crossing=cycleway does not exist. And if I
use the formula
highway=cycleway
cycleway=crossing
as a node is repetitive (517 cases says taginfo) .
Also I think about using
crossing_ref=tiger
(1542 cases says taginfo) but as I'm not in Great Britain and I think
animals crossing references are not useful in global tagging and should be
changed by the physical characteristics I think
highway=crossing
crossing=cycleway
would be a good formula.
What do you think?
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tag an information panel

[yo paseopor]

Hi
Spanish calling
Here at Spanish community of OSM we are asking about the information poles
and panels we have in our cities. we are talking about 3 types:

-Information about the capacity of a parking
-Information about the pollution level in a city
-Information about public transport ETA, and so on.

Is there any kind of tagging? Should we create new one?

A possibility is to make something like
highway=information_panel
and then extend the information key to values like
parking_capacity,pollution,public_transport...

How do you tag these items?
Thanks
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reversible Road tagging

[yo paseopor]

One little point

Untill now GPS navigation is orientative, not compulsory, obligatory or
have-to-do. So instead your Osmand says you go in opposite direction, you
drive, you decide. No kamikaze please.

yopaseopor
PD: conditional lanes tagging situation would be interesting with a new tag
(forward/backward/reversible), for example...

lanes:forward=1
lanes:backward=1
lanes:reversible=1
reversible:forward=Mo-Su 07:00-09:00,15:30-17:30
reversible:backward=Mo-Su 9:00-15:30
reversible:closed=Mo-Su 17:30-07:00

On Thu, Nov 8, 2018 at 11:12 PM Richard  wrote:

> On Thu, Nov 08, 2018 at 04:05:49PM -0500, Jack Burke wrote:
>
> > Following the KISS principle, barrier node tagging might be the way to
> go,
> > at least initially.
> >
> > Barrier tagging Pros:
> > * Easy to implement in routing (e.g., OsmAnd's routing.xml can process a
> > node as barrier=1 or barrier=-1 based on the opening_hours times).
>
>
> note that OsmAnd doesn't do any time dependent routing, or at it least it
> didn't do it for a very long time.
>
> > Barrier tagging Cons:
> > * Having a hard time thinking of any.
>
> might work to some extent but I see it as important deficit that the
> directionality
> of the road isn't modelled.. sooner or later it will cause disaster.
> Imagine routers
> to issue commands like "turn around and follow the road in opposite
> direction" when the
> diver missed an exit for example.
> Also, just one single entry point that someone has forgotten to tag with a
> barrier
> or has the wrong time information and the router will send kamikaze
> drivers in the wrong
> direction into the expressway.
>
> My thought would be to have a variable time dependent number of lanes in
> each
> direction.
>
> Or "oneway" with conditional restrictions
>  https://wiki.openstreetmap.org/wiki/Conditional_restrictions
>
> Richard
>
> ___
> 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] highway=crossing used on ways

[yo paseopor]

I would use side=left/right/both as I use for mark the position of a
traffic sign. This position is relative to the direction the way was drawn
in OSM (like rivers)

yopaseopor

On Fri, Oct 26, 2018 at 4:17 PM André Pirard 
wrote:

> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] unmarked crossing, tactile paving, lowered kerbs / was: 2 meaning for crossing=zebra

[yo paseopor]

For me it is an unmarked cross . I think it is very common in the USA. May
we have to ask ourselves in every land how the local administration deal
with putting crossings in our streets. I think the way it is done in Europe
and in the USA is different.

yopaseopor


On Sat, Oct 27, 2018 at 2:05 AM Graeme Fitzpatrick 
wrote:

>
>
> On Sat, 27 Oct 2018 at 08:44, Peter Elderson  wrote:
>
>> I would not tag that as a crossing for pedestrians at all.
>>
>
> Why not, Peter?
>
> It is designed for wheelchairs, people with prams etc to easily get from
> one footpath across to the next footpath, without having to get over a kerb.
>
> 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] 2 meaning for crossing=zebra

[yo paseopor]

Hi
Here is my opinion about that

If your query crossing in taginfo you may find 10 main values [1]:

uncontrolled > 668.448 but with marks (generic). I think they might be
zebra crossings.
zebra > 541.412
traffic_signals > 520.238 with traffic lights
unmarked > 146.241 without marks of any kind but it is not forbidden to pass
island > 52.437 big crosswalk with a traffic island at the middle
no >9.942 forbidden to cross (generic)
marked > 8.930
yes > 4.006 (most generic)
toucan > 2.058
pelican > 1964
puffin > 116

Let's reorder

no

yes
controlled...with traffic signals?
uncontrolled but
marked
unmarked

island

animal stuff (ref)
zebra
pelican
toucan
puffin
tigger
panda
pegasus
...

All the animal stuff is British. They called the crossing like with some
characteristic thing of some animals.

[2] Zebra: with black and white poles called Belisha Beacons. In the UK
they are uncontrolled but marked.
[3] Pelican:(previously pelicon crossing, which stood for "pedestrian light
controlled crossing"). Crossing with traffic lights and a button to cross.
Controlled traffic sign crossing.
[4] Panda:As pelican but with a "light traffic light" with two lights for
drivers and only the word cross for the pedestrian people
[5] Tigger: iniatially was yellow and black. Now are the crossing for
bicycles. Attached to the zebras
[6] Toucan: "Since two-can, both pedestrians and cyclists, cross together,
the name "toucan" was chosen." Big sense of humour. If you take a Tigger
and a pelican then you will have a Toucan crossing. Controlled with traffic
lights and a button. If the button and the pedestrian/cyclist traffic light
is at the same place when you start to crossing and not in the opposite it
is called puffin crossing [7]
[8] Pegasus: for horses

So... what about OSM might be in all the countries

I think OSM can describe the crossing with one key, and then can explain
how it is called the crossing with other key so

crossing=no
crossing=yes (most generic)
crossing=controlled is with traffic signals or with police people or similar
crossing=traffic_light is with traffic lights. So implies
crossing=controlled
crossing=uncontrolled can be crossing=marked or crossing=unmarked . So one
of them implies crossing=uncontrolled

If there is a traffic island in the crossing you can tag crossing=island

and then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other
value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of
panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated

crossing_ref is a good key for describe better the crossing

I would change all the crossing=animal stuff to crossing_ref and then
crossing=technical description.

Salut i passos de vianants (Health and crossings)
yopaseopor

[1] https://taginfo.openstreetmap.org/keys/crossing#values
[2] https://en.wikipedia.org/wiki/Zebra_crossing
[3] https://en.wikipedia.org/wiki/Pelican_crossing#Details
[4] https://en.wikipedia.org/wiki/Panda_crossing
[5] https://en.wikipedia.org/wiki/Zebra_crossing#Tiger_crossing
[6] https://en.wikipedia.org/wiki/Toucan_crossing
[7] https://en.wikipedia.org/wiki/Puffin_crossing
[8] https://en.wikipedia.org/wiki/Pegasus_crossing
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Wed, Oct 10, 2018 at 1:30 AM Martin Koppenhoefer 
wrote:

>
>
>
> to me there is no point in mapping traffic signs on ways. Traffic signs
> are punctual items, their supposed effect (our interpretation what they
> imply for which way) is already mapped with established tags on the way. It
> is more accurate and more useful (for finding problems and inconsistencies)
> to have the signs mapped as nodes.
>
> Let me give you an example: I do find it helpful to map maxspeed signs on
> nodes (doing it at the side of the highway because this implies the
> direction), because it helps to verify and maintain the speed limit data on
> the highway. If these were replaced by tags on the highway it would be less
> useful, because they would merely repeat the information that maxspeed
> already gives, and you won’t have neither the confirmation of repeated max
> speed signs nor would you know until where a later discovered sign with a
> different maxspeed is “at most” valid. Every time you discover a new sign,
> with the tag on the way method you start again “from scratch”.
>
-Sorry for my bad English when I was writting about putting signs ON the
way I wanted to say put NODES ON the way (with tag side and tag direction
you can locate the place and the direction is affecting the traffic sign. I
think traffic sign specific tags (traffic_sign, traffic_sign:direction (or
backward/forward subkeys) , traffic_sign:side (or side:) would never be
used as a tags for the ways.
-I'm agree with you in that.


> Adding traffic sign ids to ways makes only sense if you mistrust the osm
> tags, e.g. because there aren’t the exact tags you would need to describe
> the effect of a sign. My suggestion would be to improve/amend the system of
> human readable tags in this case, so that they fulfill your local
> requirements.
>
-Improving everything with the help and participation of all the community
would make better the system because then the system will be usefull and
complete for the maximum number of people. It is not a thing of me, it is a
thing of and for OSM. I am not an strange person, I'm only an OSM mapper.

>
> I do recognize there can be some usefulness in both information (actual
> signs and their position=nodes, and the actual signs that led to certain
> tags being applied on an object (=ways)). I am not sure it is a good idea
> to use the same tags for it.
>
-I think using the same keys would help the people to understand better the
scheme and to don't duplicate work (if I have lanes: on a way...why can
have ALSO lanes: of a node on the way?) Do I have to "invent
traffic_sign:lanes" ?

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

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Wed, Oct 10, 2018 at 1:05 AM Colin Smale  wrote:

> I am not saying these cases are impossible, only that they have to be
> accommodated, preferably as uniformly as possible. It is not intended as
> criticism, but as a critical test of fitness for purpose. If the tagging
> scheme can't handle these real-world situations, it's not ready for go-live
> yet.
>
-I think the scheme is ready. If I think about the Spanish law situations I
think with little modifications it is for all the countries around the
World.

> This is of course a fairly easy one. What European regulations are you
> referring to here by the way?
>
-Well, I have to say the first time I heard this european recommendation
was at 2006 in TV news when in Catalonia there was a new plan to put new
destination signs along all Catalonia. It is difficult to find the exact
law it says that.
The first book you can find is the *Manual SENIOR de la senyalització
interurbana de Catalunya de la Generalitat de Catalunya*
It is a PDF . It says basic concepts:
All traffic signs should have Conspicuite ,have to be legible and
recognisable,comprehensible and credible.
Also in Catalonia we have RACC which makes some surveys inside EUROTEST
about traffic signs. Some examples

(estudio señales tráfico RACC)

http://mig.racc.es/pub/ficheros/actualidad/actualidad_dp_ix_encuesta_racc_jzq_5feb3758.pdf
http://imagenes.racc.es/pub/ficheros/adjuntos/adjuntos_dp_senales_de_trafico_2008_jzq_dba4c612.pdf

(Other EURO TEST traffic signs studies)

https://www.yumpu.com/en/document/view/19587284/international-road-signs-eurotest
https://www.theaa.com/public_affairs/reports/EuroTest_Roadworks_2006.pdf
https://www.ttsitalia.it/file/Libreria/Europe/EuroTest05_Mway_Roadworks.pdf

little article in the Spanish DGT magazine
http://www.dgt.es/revista/archivo/pdf/num175-2005-Seniales.pdf

(Other organizations and documents)

UNITED NATIONS ECONOMIC COMMISSION FOR EUROPE

Convenio CEPE de las Naciones Unidas sobre señalización vial
https://www.unece.org/fileadmin/DAM/trans/conventn/Conv_road_traffic_SP.pdf

https://www.unece.org/fileadmin/DAM/trans/roadsafe/publications/docs/Consolidated_Resolution_on_Road_Traffic_RE2_e.pdf

In the 1.3 you can read the conditions United Nations recommends for the
traffic signs of confirmatory direction signs (our destination signs)

"The confirmatory direction signs should possess the following
characteristics:
  (a)
Shape of the sign - As the confirmatory sign falls within the category of
informative
signs, it is rectangular in shape.
  (b)
Colour  of  the  sign  -  The  colours  adopted  are  those  used  for
place  and  route
identification signs.
  (c)
Dimensions of the sign - The dimensions depend on the amount of information
to  be  given  and  on  the  dimensions  adopted  for  place  signs  on
the  route  in
question. If, in addition to the name of the next main town, intermediate
localities
are  also  indicated,  it  is  recommended  that  not  more  than  two
such  localities
should be mentioned, and that their names, and the distances at which they
are
situated, may be indicated in smaller letters and figures (preferably in
the ratio
of 2 to 3) than those relating to the main town."

Fundación Abertis (UNESCOMEDCENTER)
http://www.unescomedcenter.org/es/noticias/20/los-expertos-apuestan-por-mejorar-la-senalizacion-y-sancionar-para-que-el-conductor-tome-conciencia-del-riesgo

ERF Position
https://issuu.com/erf9/docs/erf_position_paper_on_vertical_sign

-Directive 98/34/EC of the European Parliament and of the Council of 22
June 1998
-Regulation (EU) No 1025/2012 of the European Parliament and of the Council
of 25 October 2012 on European standardisation, amending
-Council Directives 89/686/EEC and 93/15/EEC and Directives 94/9/EC,
94/25/EC, 95/16/EC, 97/23/EC, 98/34/EC, 2004/22/EC, 2007/23/EC, 2009/23/EC
and 2009/105/EC of the European Parliament and of the Council

>
> How do you make the link between the qualifier and the main sign it
> applies to? Does it only apply to the one sign immediately above? Or to all
> signs above? Or the sign(s) below? How would these links work for multiple
> qualifier signs, like "except for buses" / "except with permit"?
>
-Complimentary traffic signs are also traffic signs, with other position
but with all its identity. Here in Spain traffic signs law say second sign
says the condition the first traffic sign is applied.
Also you have some keys to mark or explain the meaning of the complementary
traffic sign. You can translate the information you read into OSM keys and
values

except buses? bus=yes
except with permit? access=designated?

> How does anyone or anything (a data consumer) connect the
> "traffic_sign:forward=ES:S235a" to the way that it applies to? Not all
> junctions are nice 4-way 90-degree junctions. What have you "tested"
> exactly? Where do you place the node for this sign in relation to the way?
> Maybe if you could give a link or an exact 

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

>
> Tagging is for discussing the development and meaning of tags.
>
So this list is about the meaning but has no power or decision about how to
apply the decisions about we write here?
Is it correct?

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

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

?

Well. I want to publish the messages people says to me on the changesets:

Mknight "Wäre es nicht irgendwie sinnvoller, ein issue für iD zu schreiben,
statt etabliertes Tagging zu ändern?"
Mueschel "Please stop this undiscussed mechanical edit until further
discussion.It breaks many cases of traffic sign tagging."
Mueschel "The discussion ended with your question about the change, not a
single answer approving it. Mass edits should be announced and agreed on in
a broader community, and not in the depth of a thread without anybody
noticing. You also edited ways with traffic_sign:* tags, where this scheme
will not work at all."
Peilscheibe "I reverted this changeset because diligent tagging (e.g. about
different traffic signs per direction) was removed and replaced by wrong
information. This is not acceptable at all."
Peilscheibe "Just a few examples:
http://osmlab.github.io/osm-deep-history/#/way/25717685
http://osmlab.github.io/osm-deep-history/#/way/629964077
http://osmlab.github.io/osm-deep-history/#/way/629964082
On this ways (and a lot of others) there was a different traffic sign
tagging per direction.
Why? Because in reality the ways are differently signposted per direction
which has de facto and de jure implications on traffic members.
Your edit removed this diligent tagging and wrong values were contributed.
This is a blatant information loss and it is wrong."
geri-oc "Du hast hier Änderungen vor genommen die nicht zutreffend sin. Die
Richtung in Sinne des Weges ist backwart oder forwart. direction gibt eine
Richtung in Grad oder Himmelsrichtung an.

Ich erwarte eine Revert in angemessener Zeit von dir - zu mindest für
diesen Änderungssatz. Über andere unberechtigte Änderungen kannst du gern
im Forum weiter diskutieren, wo ein Revert deiner Änderungssätze ebenfalls
diskutiert wird:
https://forum.openstreetmap.org/viewtopic.php?id=64028

Gruß Gerd - geri-oc"
geri-oc "direction ist ein verkehrter Schlüssel in Bezug auf die
Wegrichtung von Verkehrszeichen. Die Änderungen sind alle falsch, da
direction in Grad oder Himmelsrichtung angegeben wird."
geri-oc "Also, the specification direction is correct only with degrees or
compass. forward or backward is related to the direction of the path in
OSM.I am for a revert of these changes (worldwide)."
geri-oc "57,7274424, 16,5246249 ist nach den richtigen Angaben laut WIKI
und JOSM-Plugin gemappt:
57,7273945, 16,5241181 hast du geändert.
Es existieren zwei verschieden Schlüssel in unmittelbarer Nachbarschaft und
nach der alten Auswertung erscheint der zweite Node nicht mehr. Ich werden
den CS reverten, falls du es nicht selbst machst. Deine Quelle Mapillary
kann auch nicht stimmen, da einige Schilder gar nicht in Mapillary sind,
sondern vor Ort erfasst wurden."

geow "I asked the data working group to revert all changesets of user
https://www.openstreetmap.org/user/yopaseopor/history where the cS comment
is: "#fastag #traffic_signs Apply traffic_sign:direction tag to avoid
problems with new iD editor as an agreement on tagging list“
Thanks
geow"

and then Streckenkundler "It sucks to adjust the data to the Editor. I have
chosen this worde deliberately. This is the best way to scare mappers from
OSM. In my opinion, all your changes must be reset immediately and
promptly. Stinky Greetings..."

Hey! I can be wrong but don't insult me!

Streckenkundler "Whether iD is bad or not, I can't say. Your way of pushing
your ideas was Bad. First a huge proposal, where hardly any one looks
through and it is not yet Decided. Then quickly change data to match the
programming of iD to create Facts.
That's not how it works. Thanks to woodpeck for the Revert."

Well, it was a disaster for me, people claiming "my head", etc.but...
Crisis also means opportunity. So first of all: what is the people wants
about traffic signs? It is the moment to have a big consensus and avoid
these kind of episodes. So I send this message to the tag list. And I hope
some day before or later we have a complete traffic sign scheme.

But I have to say I'm sorry for the misunderstanding of what a consensus is
in a tagging list... but What is a consensus in this list?

yopaseopor

On Tue, Oct 9, 2018 at 10:28 PM Frederik Ramm  wrote:

> Hi,
>
> On 10/09/2018 05:42 PM, yo paseopor wrote:
> > It is not the first attempt to do that. Last days, with iD
> > implementation and my message I have think it was the solution. Also I
> > have waited some days and communicate to this list my intentions to
> > adopt the proposed iD scheme. But when I start to do the
> > modifications... People complains about it (I am sorry if there was some
> > errors "translating" to the new scheme).
>
> Yes, DWG has also received complaints about these edits, and I am in the
> process of reverting them.
>
> At the

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Tue, Oct 9, 2018 at 8:16 PM Colin Smale  wrote:

> I can think of a couple of non-trivial cases which will need to be handled:
>
> 1) multiple signs on a single post
>
  As Finnish people do we can add subkey :2 :3 :4... (European regulations
does nit recommend more than 3 traffic_signs together to make better their
readibility.

>
> 2) signs with a dependent (qualifier) sign, such as "except for buses"
>
 Complementary signs are also traffic signs (in second, in third position)
with its own code, so they need their information (the same osm tags we
have for ways?)  and position. A few weeks ago in this list I talk about
the possible changes for "designation" value to make a key with this more
specific information

> 3) one or more signs on a larger panel - too large to represent as a node
>
Sorry but I don't agree with you... because I test it...and it works.
Example for a complete destination traffic sign

colour:arrow black
colour:arrow:lower_panel white
colour:back white
colour:back:lower_panel blue
colour:ref red
colour:ref:lower_panel blue
colour:text white
colour:text:lower_panel white
destination:lower Coma-ruga
destination:lower_panel Barcelona
destination:lower_panel:lower Aeroport
destination:lower_panel:upper Vilanova i la Geltrú
destination:symbol:lower_panel:lower airport
destination:upper El Vendrell
length  500
ref  N-340
ref:lower_panel C-32
side up
time:1 00:05
time:3 00:05
time:b 01:00
time:b:1 00:20
time:b:3 00:45
traffic_sign:2:forward ES:S235a
traffic_sign:forward ES:S235a
turn:destination under
turn:destination:lower_panel under
type 
destination_sign


> 4) signs applying only to certain lanes
>
you can specify the lanes and the exact information with all these tags
(lanes scheme already exists)

> 5) signs on a gantry above (half of) the road
>
The example above is like the granty sign (with the same tags)

> I can understand the argument for mapping the signs as objects in their
> own right. This would be limited to being a database of street furniture,
> unless and until the effect of the signs can be linked to the effect they
> have on traffic (in the broadest sense), which is the starting point for
> the present discussion. This is of course a serious exercise to ensure the
> link from the sign to the effect is represented unambiguously.
>
Barrier nodes acts in routing, why not the prohibition in overtaking? or
the city limit? or the warnings?


> We already have turn restrictions, maxspeed, maxheight etc on the ways
> themselves (without needing to have any link to a sign). This model works
> reasonably well for routing applications, albeit not without some
> discussion about the types of "weight" and so on.
>
Signs are a next level for routing, for GPS software. Why Street View cars
and software wants to recognize traffic signs? Why don't you have the
possibility to have the traffic signs recreated in your own screen, with
only OSM data in a node?



> The point I am trying to make, is that there might not be much of a
> "business case" for linking the signs/posts to their effects, and that
> mapping them as "street furniture" might be going far enough...
>
More than 30 countries, more than 24000 different traffic signs. In each
country with their own traffic signs...why not? Are street lamps important?
Are recycle bins important? Are Benchs important?

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

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

for this reason the solution of tag the traffic signs ON the way it's the
best way to do it. Traffic signs are relative to their ways (because if the
way does not exist the existance of traffic sign is non-sense). Ways have
direction, also their nodes can have this reference.

Relations are complex and also are an item not all the mappers can do. Why
don't accept the easiest way to get this information?
(Now it works without relations)

yopaseopor

On Tue, Oct 9, 2018 at 7:53 PM Paul Johnson  wrote:

> Why not map traffic signs the way enforcement devices are currently mapped
> in relations?  That's more foolproof than relying on nodes having nonextant
> direction, especially when most traffic signs aren't even members of ways.
>
> On Tue, Oct 9, 2018, 10:46 yo paseopor  wrote:
>
>>
>> I want to start the mother of all discussions about traffic signs
>>
>> It is not the first attempt to do that. Last days, with iD implementation
>> and my message I have think it was the solution. Also I have waited some
>> days and communicate to this list my intentions to adopt the proposed iD
>> scheme. But when I start to do the modifications... People complains about
>> it (I am sorry if there was some errors "translating" to the new scheme).
>>
>> So Please , let's talk about it. What will be the correct way to tag a
>> traffic sign?
>>
>> I start with my option. Traffic sign as a NODE on the way x direction.
>> Because traffic sign is relative to the way, the road, not the building or
>> the street itselfs, it is located above, as a road mark, on the right of
>> the road or on the left of the road (or both of them).
>>
>> I'm interested in all countries so a good way to do it is with the
>> country code for every traffic sign you can find in every traffic law in
>> every country.
>> It would be interesting also to develope a generic scheme for tagging it
>> (not only the country/code)
>>
>> traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific
>> of each country traffic signs law)
>>
>> Also it is facing to the direction of the way (forward and backward). In
>> OSM ways have the direction you have drawn it. So the info is relative to
>> this direction.
>>
>> As an issue detected in iD with it to make possible the edition of
>> traffic signs good way was the traffic_signals solution: an specific key.
>>
>> traffic_sign:direction=forward/backward/both
>>
>> Also accepts other facing directions like 90/270...
>>
>> Also we need the info relative to the way of its location , the side
>> where it is: Is it on the right? Is it on the left?
>>
>> side=right/left/both
>>
>> And also position, because you can have more than one traffic sign.
>> Finnish people give the solution :2
>>
>> traffic_sign:2=*
>>
>> To tag this we have some informations sources (of course first of all
>> local knowledge) like Mapillary or OpenStreetCam.
>>
>> Tools we have now:
>>
>> JOSM preset
>> JOSM style
>> JOSM Kendzi3D's configuration files and models
>> Leaflet traffic signs map
>> Taginfo stats
>>
>> More info about it :
>>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>>
>> Main characteristics of the scheme:
>>
>> -Scalable (you can locate every traffic sign in every place)
>> -Exportable (you can locate every traffic sign of every country in the
>> World, with or without JOSM wizards)
>> -1 key / 1 value (for making the renders easy to adopt it)
>>
>> yopaseopor
>> ___
>> 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] Traffic_sign discussion

[yo paseopor]

I want to start the mother of all discussions about traffic signs

It is not the first attempt to do that. Last days, with iD implementation
and my message I have think it was the solution. Also I have waited some
days and communicate to this list my intentions to adopt the proposed iD
scheme. But when I start to do the modifications... People complains about
it (I am sorry if there was some errors "translating" to the new scheme).

So Please , let's talk about it. What will be the correct way to tag a
traffic sign?

I start with my option. Traffic sign as a NODE on the way x direction.
Because traffic sign is relative to the way, the road, not the building or
the street itselfs, it is located above, as a road mark, on the right of
the road or on the left of the road (or both of them).

I'm interested in all countries so a good way to do it is with the country
code for every traffic sign you can find in every traffic law in every
country.
It would be interesting also to develope a generic scheme for tagging it
(not only the country/code)

traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of
each country traffic signs law)

Also it is facing to the direction of the way (forward and backward). In
OSM ways have the direction you have drawn it. So the info is relative to
this direction.

As an issue detected in iD with it to make possible the edition of traffic
signs good way was the traffic_signals solution: an specific key.

traffic_sign:direction=forward/backward/both

Also accepts other facing directions like 90/270...

Also we need the info relative to the way of its location , the side where
it is: Is it on the right? Is it on the left?

side=right/left/both

And also position, because you can have more than one traffic sign. Finnish
people give the solution :2

traffic_sign:2=*

To tag this we have some informations sources (of course first of all local
knowledge) like Mapillary or OpenStreetCam.

Tools we have now:

JOSM preset
JOSM style
JOSM Kendzi3D's configuration files and models
Leaflet traffic signs map
Taginfo stats

More info about it :

https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

Main characteristics of the scheme:

-Scalable (you can locate every traffic sign in every place)
-Exportable (you can locate every traffic sign of every country in the
World, with or without JOSM wizards)
-1 key / 1 value (for making the renders easy to adopt it)

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

Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

>
> There's no reason to reinvent the wheel here. Plus, as far as I can tell,
> the suffix (:2) solution doesn't  work when there's more than one "main"
> traffic sign.
>

I dont reinvent anything. Multivalues are hard to manage but also you don't
have more than one "main" traffic signs. European conventions recommends no
more than three values at the same pole, and no more than three
destinations in a sign so a multivalue does not the best solution. Every
sign has its meaning and the combination of the second position for a
traffic sign says you the limit of the first traffic sign, so it is
important to remark the position of the traffic sign. As Finnish people
demonstrate traffic sign second position can be managed without problems.
For example, in the style or the recreation of Kendzi3Ds plugin of JOSM you
can have two or three positions of every traffic sign without problem.

yopaseopor

On Tue, Oct 2, 2018 at 5:55 PM Tobias Knerr  wrote:

> On 02.10.2018 16:44, yo paseopor wrote:
> > Also it is not the best call "undersigns" . There are signs too, with
> > their code, and you can put in on second place or third place , like
> > traffic_sign:2 as Finnish people does.
>
> Or put them in a comma-separated list, which is the international
> standard tagging that's documented on
> https://wiki.osm.org/Key:traffic_sign
>
> There's no reason to reinvent the wheel here. Plus, as far as I can
> tell, the suffix (:2) solution doesn't  work when there's more than one
> "main" traffic sign.
>
> ___
> 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] Traffic sign direction tagging..

[yo paseopor]

It is not the better thing to say " we can't control the tagging of an item
so we can map it".  Why we can't control them? Can we control the trees you
have on the map? Can we control the street lamps of the map?...so we can
control EVERYTHING on the map and its orientation (of course with the
correct technology now we have, like Mapillary's and others). Traffic signs
informs you about something specific of the way, example, the end of the
cycle way, so you can see where the traffic sign is correct to put on.

Also it is not the best call "undersigns" . There are signs too, with their
code, and you can put in on second place or third place , like
traffic_sign:2 as Finnish people does. And as you say second position
traffic sign will be so important as the first position is.

It is difficult to have two traffic signs in both directions with the same
meaning so you don't need traffic_sign:2:direction. If you need so you can
put a node next to or above or beside to the other with all that other
directions' info

Also don't forget the tag side=  and all of their values

yopaseopor

On Tue, Oct 2, 2018 at 4:03 PM Allroads  wrote:

> Traffic_sign is on a node beside of above a road. There where, it is.
> This is the basis, the derivative is tagged on the road, as ...
>
> The direction=* says, the facing direction of the sign/shield. Important:
> indicates the direction in which the law applies. This could be various.
> Depends on sign and undersign.
> A combination of trafficsign and undersign is important, it indicates a
> combined rule, summarized in a value.
> But there could be more trafficsigns on a node even a highway=street_lamp,
> the direction=* can not be used.
> traffic_sign:1:direction=*  facing direction is used.
> traffic_sign:2:direction=*
> street_lamp:direction=*
>
> Then the derivated on the way.
>
> This could be the whole way.
> motor_vehicle:forward=no
>
> But also on a node of a way ( not the first and last node) like give_way.
> The most directly derived tagging is tagging the traffic sign itself.
> First
> degree derived tagging.
> Second degree tagging are the access tags.
> If you have first degree tagging, the second degree could be controlled,
> if
> it is correct.
> In the Netherlands we started to tag the traffic_sign on a cycleway, then
> knowing which vehicle key/value is needed
> Now with overpass we can control if tagging is correct on the cycleway G11
> (mofa designated), G12a (mofa mofa designated), G13.
> This way we get more qualitative data.
>
> http://mijndev.openstreetmap.nl/~peewee32/traffic_sign/traffic_sign.htm?map=cycleways=16=52.13023=5.41893=B000FFTFTFFF
>
> Then on a waynode. like give_way.
> C6 traffic_sign.
>
> https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
> The working-out of the law, says, that goes into effect when you pass the
> shield at the front. And must be repeated after each crossing.
> This traffic sign can stand on one side of the road.
> If you come from the other side, there is no shield, drive in and you
> visit
> a house, a plot, or you decide to turn around, this is allowed by law.
> This you could do, for example 10 meters from the back of the shield, turn
> around.
>
> This place is a like a give-way construction on a node., with access
> traffic_sign:forward=NL:C6  (first derivated tagging, could used to
> control
> the other tags)
> motor_vehicle:forward=no
> motorcycle:forward=yes
> moped:forward=yes
> mofa:forward=yes
>
> some use a 10 meters way to set the tags.
>
> forward, indicates the direction of operation of the law in relation to
> the
> Openstreetmap drawing direction.
>
> >> `traffic_sign:direction=forward/backward`
> Here direction is facing direction on the sign.
> And can not be used a working-out direction of the law.
> traffic: forward= and traffic_sign:backward is correct.
>
> I do not agree!
>
> In combination with traffic_sign, direction can only be used  on separated
> node besides the road (or above), given the facing direction, there are
> signs with undersign with a left or right arrow, indicating in which
> direction the sign works,
> then the facing direction must be correct, often this is 90 degrees on the
> driving direction, or on other side of a T junction.
>
> If the traffic_sign (first degree derivated) is not tagged it is almost
> impossible to control tagging. With all combinations and undersigns.
>
> Regards.
> Allroads
>
>
>
> -Oorspronkelijk bericht-
> From: Marc Gemis
> Sent: Tuesday, October 2, 2018 2:04 PM
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Traffic sign direction tagging..
>
> >>
> >> >  To keep things simple, we'll do the same thing for traffic signs:
> >> `traffic_sign:direction=forward/backward`
> >
> >
> > Please , for doing traffic_sign:direction is better to put direction=*
> > tag.
> >
> >> > I still highway=give_way and highway=stop with
> >> direction=forward/backward (which 

Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

Ok

Are you agree with the tag traffic_sign:direction=forward/backward?

If you are agree please change "automatically" all the
traffic_signs:forward/backward to the new
traffic_sign:direction)=forward/backward
If you do that I would change all the presets, the styles and the kendzi3D
instructions for JOSM, Taginfo projects info and all the maps done with
these codes.

salut i senyals de trànsit (health and traffic signs)
yopaseopor




On Tue, Oct 2, 2018 at 12:45 AM Bryan Housel  wrote:

> On Oct 1, 2018, at 5:23 PM, yo paseopor  wrote:
>
>  > ^ This is the problem.  The wiki says we are supposed to do something
>> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
>> needs to be based on a "toplevel" tag like `traffic_sign=*` not
>> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
>> many of their tags have this issue too, where they put a value in the key
>> part, and so we can’t turn it into a preset).
>>
>
>  JOSM can do this change (when you change a way) as you can see on
> https://i.imgur.com/NnLpKWR.jpg
>
>
> iD will also do this change when reversing a way.  That’s not what my
> email is about.
>
>
>  If you read taginfo you can find for forward subtags
> https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
> nodes. If you read taginfo for backward
> https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
> than 80 nodes. Are you saying iD doesn't recognise all these tags with
> forward and backward subtags?
>
>
> Nope, not saying that at all.
>
>
>  I give you a solution: make two presets: one for traffic_sign:backward
> and other with the same values for traffic_sign:forward.
>
>
> That’s a bad solution, so instead we’re going to solve the problem of
> indicating traffic sign direction the same way it’s already solved for
> traffic signals.  `traffic_sign:direction=forward/backward` - simple.  I
> will even convert all the existing traffic signs tagged with
> `traffic_sign:forward` or `traffic_sign:backward` to work this way if you
> want.  It’s an unambiguous tag change.
>
> I wouldn't know how to explain to mappers when to use a “Traffic Sign” vs
> a “Forward Facing Traffic Sign” vs a “Backward Facing Traffic Sign” much
> less translating these concepts to dozens of different languages.
>
>
> Thanks, Bryan
>
> ___
> 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] Traffic sign direction tagging..

[yo paseopor]

>
>  > ^ This is the problem.  The wiki says we are supposed to do something
> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
> needs to be based on a "toplevel" tag like `traffic_sign=*` not
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
> many of their tags have this issue too, where they put a value in the key
> part, and so we can’t turn it into a preset).
>

 JOSM can do this change (when you change a way) as you can see on
https://i.imgur.com/NnLpKWR.jpg
 If you read taginfo you can find for forward subtags
https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
nodes. If you read taginfo for backward
https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
than 80 nodes. Are you saying iD doesn't recognise all these tags with
forward and backward subtags?
 I give you a solution: make two presets: one for traffic_sign:backward and
other with the same values for traffic_sign:forward.


> >  To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
>

Please , for doing traffic_sign:direction is better to put direction=* tag.

> I still highway=give_way and highway=stop with
> direction=forward/backward (which is used by OsmAnd AFAIK).
>

And what about the other traffic signs. Are they not important? Why don't
erase it...from the World if they are not important?
I think OsmAnd can decide what data from OSM they want to use, so if they
decide to support traffic signs they will support it. If they don't want to
they won't support it.
Also remember the don't map for the render think (instead is a "render" so
important like OsmAnd).

> Describing what a driver might see when approaching a turn would be an
> effective use of traffic_sign, but 'node near the way' is pretty useless
> for routing. For maximal detail you'd need both, but if you're only going
> to add one, the highway=stop is far more useful.
>

Best approach is to have the traffic sign "inside" the way because the
traffic sign is relative to the way. If the way doesn't exist, traffic sign
is useless, so it is better to map it as a node on the way. Also then you
have the direction of the way to make relative the traffic sign to the
direction of driving.

> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

OsmAnd can show some traffic signs in certain moments or resolutions or
guiding, as they do with maxspeed info.

> Not all give ways have a sign, some are just give way markings painted on
> the road.
>

Technically markings painted on the road are...traffic signs itself (in
some countries there are specific codes to this items) and also they have
their importance , you cannot ignore them

> I'm still against using forward/backward on nodes, it really feels like a
> hacky way to avoid using a relation (up there with using ref=* on ways to
> describe routes), which would disambiguate things without being so brittle
> just because a way reversed, and handle more complex situations like "right
> turn permitted without stopping" sign below a "stop" sign, or allow a data
> consumer to be able to display a diagram indicating which ways a stop
> applies to (handy if you encounter, say, a six way intersection with a four
> way stop).
>

It is not necessary to make a relation if you put on the way the traffic
signs nodes. JOSM reverse them if you reverse the way and things
complicated like "right turn permitted without stopping" are relative to
the direction you are driving (JOSM only shows you a north orientation and
doesn't allow to "rotate" background and data like GMaps style. So forget
the problem of the side inside a instruction because these instructions
will always be relatives to the traffic sign itself, nor the way you see it
in JOSM or iD (iD also doesn't accept rotate background and data.

> Do you have an example of a pedestrian crossing that OSMand warns you of,
> as I don't see (or maybe just don't notice?) crossing warnings, so I'm
> wondering if they may be tagged somehow differently?
>

OpenMapSurfer shows traffic sign for pedestrian crossings so it is about
the render.

That is what I think about this topic
Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Designated value as a key

[yo paseopor]

Hi!

When I tag the access to a way reading the meaning of the traffic sign I
miss some specific conditions. I know I can do it at general times with key
access, but in specific cases access is so "small for me". There are also
conditional tags but with these two keys I don't arrive to cover local
meanings and situations of restriction to some vehicles (example, you have
a living street, which is only allowed for the LOCAL bus line, nor the
other buses. So you can't tag it with bus=yes or bus=designated within the
complete meaning of the restriction given you by the traffic sign.

For these situations I propose to "flip" designated value and convert it to
a subkey. In that way you would have an escalable subkey that you can
complete with the specific information of that tag. This key will be
together with the combination access=designated so you can complete the
information of the specific designation

access=designated
designated=local_bus

designated=bicycle
designated=motor_vehicle
designated=pedestrian
designated=Mo-Fr 9:00-9:30
designated:en=schoolars only
designated:ca=Només escoles
designated:es=Solo escuelas

This also applies for other uses like some restrictions done by "marks"
(Example: in a industrial zone you have some private ways...but private of
who? In the reality you will have a traffic sign it says you who can pass
or who cannot)
With normal access scheme you would say...repsol_workers=yes but Would it
better if I can specify the "specific designation" ?

access=designated
designated=Repsol workers


hey! but you have access tags yes/no to do that! ...And the software has to
guess which of the 32 keys with yes=no is for access . For general purposes
it's ok. But for an specific case the software can read this designated
value.

What do you think?
Salut i accessos designats (Health and designated access)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] About traffic islands

[yo paseopor]

Hi!
Here in Spain we have some doubts about mapping traffic islands.
As you can read in the wiki a traffic island is "A structure separating at
least two lanes of a highway from each other for a short distance. The
width of the calming island is usually under a few meters and should be
less than 5m."
But in the abstract you can read: "An island is a small area that
temporarily separates two different directions of traffic. " .
Here it is the doubt.
Can I map a traffic island if there is only painted on the road? Spanish
traffic regulations are clear: you cannot stop, park or drive in (the
regulation assumes it doesn't matter if it is only painted or with bollards
or with kerb ).
But some Spanish mappers considers as the wiki says in one sentence the
word STRUCTURE a only-painted-on-the-road is not a traffic island and
should not be mapped.

What do you think? If all are traffic islands instead with structure or not
and should be mapped, Can anyone modify0 from the wiki the word "structure"
or specify "only painted also" ?
Thanks

Salut i illetes de trànsit
yopaseopor

Osm wiki: https://wiki.openstreetmap.org/wiki/Tag:traffic_calming%3Disland
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is a VTC car in OSM ?

[yo paseopor]

>
> i.e. they are similar to traditional rental vehicles with drivers, while
> other concepts were more aiming at circumventing regulation (which seems
> was ultimately not succesful, in the EU there was a decision to regard them
> as transport company and not as IT service company, as they had argued, and
> many countries have banned their business either as a whole, or significant
> parts of it).


Ok but that is not the object of that discussion . I have some official
spots for them in the Barcelona's Harbour (and I'm sure if I search in
other transportation important places I will find more. How can I map it?
Should I have to make a subtag like .e.g. :

prsv (private service vehicle) =designated ?

Thanks
yopaseopor




On Tue, Aug 21, 2018 at 3:55 PM, Martin Koppenhoefer  wrote:

>
>
> 2018-08-21 14:29 GMT+02:00 Warin <61sundow...@gmail.com>:
>
>> If there are specific parking or resting areas for vehicles that provide
>> a kind of service like these, we should craft the definitions carefully and
>> see what we need to require in order to be able to identify and distinguish
>> the different classes that we want.
>>
>>
>> Rather than "what we want" it should be "what exists".
>>
>> What is being mapped?
>> Places where these vehicles are parked? For what reason are they parked?
>> Is it restricted to only these kind of vehicles?
>> Or an office where these vehicles are managed?
>>
>
>
>
> question was for a place with reserved parking, my question was about the
> "these vehicles" part: _which_ vehicles, because as I tried to explain in
> my mail, not all vehicle rental with drivers are the same class (what we
> want vs. "what exists": classes do not exist without someone creating it,
> it is us who decide what kind of class according to what kind of criteria
> we create - for mapping in osm). Example: it could be sufficient to have
> just one tag (or "class") for all kinds of vehicles (likely not for most of
> the OSM mappers though).
>
> Already looking at Uber alone, it is clear they have quite different
> divisions which offer different services which will likely fall into
> different classes, e.g. Uberpop, UberBlack, Uber-Lux, Uber-SUV, Uber-X,
> Uber-XL, UberSelect and Uber-Van. AFAIK Uber-X and UberBlack drivers are
> required to hold a transportation license, i.e. they are similar to
> traditional rental vehicles with drivers, while other concepts were more
> aiming at circumventing regulation (which seems was ultimately not
> succesful, in the EU there was a decision to reagrd them as transport
> company and not as IT service company, as they had argued, and many
> countries have banned their business either as a whole, or significant
> parts of it).
>
> 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] What is a VTC car in OSM ?

[yo paseopor]

Yes , it is restricted to these vehicles. In the ground and in the traffic
signs you can read VTC (Uber, Cabify). I said I don't want discussion about
what is a VTC really and if should they exist. I only want to know how to
map it, because in the Barcelona's harbour there are spots specifically
tagged with VTC road marks, and I think they are not PSV vehicles so...
what is it? How to map it? Also, in Madrid there is a lot of shared cars.
How to map it? OSM's Wiki is so weak in these two terms.

Thanks
Salut i places d'aparcament
yopaseopor

On Tue, Aug 21, 2018 at 2:29 PM, Warin <61sundow...@gmail.com> wrote:

> On 21/08/18 20:26, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 21. Aug 2018, at 10:55, José G Moya Y.  wrote:
>
> VTC is how rental cars with professional driver are called in Spain. I
> think the rest of the thread clarifies this: It is the Spanish name for
> Uber, Cabify and other companies that provide private transport services
> but are not taxis (their cars are not equipped with taxi meter).
>
>
>
> rental with a driver is a regulated category different to taxis in some
> jurisdictions, e.g. in Germany and Italy (and probably many more, e.g.
> France [1]). AFAIK neither in Italy nor in Germany Uber qualifies. In Italy
> they are called NCC and you need a license, are not allowed to pick up
> customers nor to park your vehicle on public space. The Italian WP says
> they are a kind of public transport without routes, the German WP says they
> aren’t (in Germany). Uber (and others) don’t qualify because they don’t
> meet the requirements (their drivers don’t generally have a P-license in
> Germany, needed for the transport of people, they don’t typically have the
> NCC license in Italy, and they don’t adhere to other rules and regulations
> for this kind of transport). They are operating in a grey area, pretending
> the service is assimilable to picking up hitchhikers (commercialization of
> the sharing economy).
>
> If there are specific parking or resting areas for vehicles that provide a
> kind of service like these, we should craft the definitions carefully and
> see what we need to require in order to be able to identify and distinguish
> the different classes that we want.
>
>
> Rather than "what we want" it should be "what exists".
>
> What is being mapped?
> Places where these vehicles are parked? For what reason are they parked?
> Is it restricted to only these kind of vehicles?
> Or an office where these vehicles are managed?
>
>
> --
> In at least some parts of the UK the driver needs a "private hire
> licence" for Uber.
>
>  Humm they have taxis ... but also hire cars umm what do they call them?
> Arrr minicabs.
> The UK regards both Uber and minicabs as "private hire". How does the UK
> map minicabs?
> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dtaxi#Taxi_shops.3F
> https://forum.openstreetmap.org/viewtopic.php?id=3184
>
> It is a can of worms.
>
> .
>
> ___
> 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] Put the name in sidewalks and cycleways

[yo paseopor]

Oks I will show you:

http://bit.ly/2M2Ff6J > Cycle way with name , you can see the name of the
street when you are riding by it.
http://bit.ly/2M8VRK6 > sidewalk without name, you can see the order
without any indication of name (openroute use then the nearest, I think)

The question is with a standard tagging scheme there is a way with these
tags:

highway=residential
name= x name
oneway=no
sidewalk=both
lanes:forward=2
lanes:backward=2
cycleway=track
surface=asphalt
maxspeed=50
lit=yes

In this scheme you will find all the things: the road, the sidewalks, the
cycleway, the lit...

But If I want to be more specific (accesibility? cycleway propierties?)
then I have to divide it in other items and "group it" but Can I repeat
some tags? (yes I can, but with name ?  Why I have to group it in this way
and not other?

for the road:

highway=residential
lanes:forward=2
lanes:backward=2
width=8
name= x name
oneway=no
surface=asphalt
maxspeed=50
lit=yes

for the sidewalk:

highway=footway
footway=sidewalk
(name= x name) << yes or not?
surface=cobblestone
lit=yes
width=3

for the cycleway:

highway=cycleway
(name= x name) << yes or not?
lanes:forward=1
lanes:backward=1
oneway=no
sidewalk=both
cycleway=track
surface=asphalt
maxspeed=10
lit=yes
width=2.5

Why the road is the only item I don't have any doubt to tag it with name= ?
Why the road is more important than the sidewalk or the cycleway? What is
more important : person, car or bike?

Thanks
Salut i voreres
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Put the name in sidewalks and cycleways

[yo paseopor]

Here it is a doubt we have in Spanish Community. Some people are making
micromapping so we start to map the sidewalks and cycleways not as value
but as an independent way.

I know when you map a street wen can put most of the items as keys and
values.But when the items are mapped separately should I put the name in
the items as sidewalks and cycleways? Now they are with their own tags and
values. Also it is useful in pedestrian or cyclist routers to specify the
way it uses for do the track.

So what is the correct way to map it: with name? or without name?

Thanks
Salut i voreres
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Use of namespace as a Lifecycle

[yo paseopor]

Thank you for guide me to a project that...doesn't work at some times. You
know now why my option is the one I have made.

In addition to that. As the future does not exist these items with proposed
also does not exist, doesn't? So these (~20.000) items: out of OSM please.

The explanation also for disused is ok, but what about was: (~10.000) or
abandoned: (~180.000) ? Are you telling me are these items now exists yet
in OSM? Also this https://www.openstreetmap.org/way/41779143 ?

I don't map anything that does not exists, the works to do the conservation
of the sand has almost done. The parking is transformed.It is not a parking
no more but is the same zone.It is not the first example you can find of
that in OSM.

Also I know in background OSM database does not erase anything!! (I have
read it marks with non-visible tags or something like that) so there is no
reason for losing the information we have now. It is present, it is real,
and I invite you to visit this beautiful zone ;)

Salut i mapes
yopaseopor

PD: This issue is about a parking of the zone, it is not about an imported
item.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Use of namespace as a Lifecycle

[yo paseopor]

Hi!

As I have received some notes for Mueschel and other user in a authorized
import of the Spanish Cadastre I want to explain some variations I use in
tagging of erased items. The rationale is simple: If I can use the prefix
"was:" and also exists https://wiki.openstreetmap.org/wiki/Namespace and
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix why I can't use it
with exact information: nor "was" but the year or the exact date of the
information (I know it because I am from the zone of that item).

Yes, I see there is with some suffixes, specially name  . But if I do that
I will lose some information I have had with the other tags. Also I would
might use it a suffix (one user told me query it aat taginfo : about ~100
uses) . And then I think: What if I do the same but with the prefix (as the
lifecycle prefix) . In that way the tags will be ordered by year, making
easy the possibility to make a map with a specific year, for example. Also
I don't lose any information and as the prefix (not new tags, sorry) is
numeric when you order the tags to edit in software like JOSM these are
together without bug disturbances or influences on the present of the
information. Also these kind of tags would be able to be ignored to
standard systems as iD, for example. It is better to make that in prefix
than the suffix.

Salut i mapes
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Street exits

[yo paseopor]

In Spain when we have this kind of exit applies the traffic sign and the
rules of living street, as you can see in
https://www.google.nl/maps/@41.2187293,1.7332079,3a,44.9y,155.43h,88.86t/data=!3m9!1e1!3m7!1swoQsNOW-rj_haPcAnawoYw!2e0!7i13312!8i6656!9m2!1b1!2i40
, a normal street becomes living at the end and the exit to another "normal
street". In OSM is https://www.openstreetmap.org/#map=19/41.21845/1.73337
I'm wondering if instead of not having the same traffic sign it would be
the same thing...


Salut i mapes
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Street exits

[yo paseopor]

In Spain this would be a living_street, the sidewalk is at the same level
and the structure of the street does not allow speed faster than 20. Also I
have to say the start of the bigger is street is a 30 Zone .
https://www.google.nl/maps/@51.9637944,4.6107321,3a,40.3y,302.01h,81.29t/data=!3m6!1e1!3m4!1sC_F6n_roU1i10R-RCah1eA!2e0!7i13312!8i6656

Also in Spain we have this traffic sign
http://www.autoescuela.tv/ver_senyal-180-S-dosocho-Calle_residencial and
you can see it at the start of every street of this kind.

Salut i mapes
yopaseopor




On Fri, Jun 15, 2018 at 8:05 AM Peter Elderson  wrote:

> In Nederland we have a growing number of  "exit constructions", where
> traffic has to cross a section of sidewalk to join the larger road. There
> is no traffic sign for this, it is indicated by the construction and lining
> of the join section. "If it looks like a driveway exit, treat it like a
> driveway exit" is the idea. Don't bother with signs, just use more sidewalk
> pavement.
>
>
> https://www.google.nl/maps/@51.9663779,4.6074315,3a,75y,14.43h,78.48t/data=!3m6!1e1!3m4!1s8uG7mHF9cw2n65XprKze0w!2e0!7i13312!8i6656
>
>
> This has (legal and practical) implications for speed and right of way:
> traffic coming from an exit construction has to give way to all sides, to
> all traffic including pedestrians, and maxspeed = 15 Kmph.
>
> Some mappers want to tag this so it could be rendered and routed taking
> speed limit and right of way into account.
>
> The easiest solution is to tag the end of the joining road (where traffic
> crosses the sidewalk) with an exiting or new highway tag, defining it as a
> section which can be crossed (and routed) but has to give way to all, and
> limits speed.
>
> Any thoughts on this?
>
> --
> Vr gr Peter Elderson
> ___
> 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] Sample tagging for highways with no lane markings

[yo paseopor]

Also I add

oneway=no

Salut i marques vials
yopaseopor

On Wed, May 23, 2018 at 5:34 PM, Tod Fitch  wrote:

>
> On May 22, 2018, at 12:48 PM, Paul Johnson  wrote:
>
> In the case of your typical bog standard American residential street, I'm
> strongly disinclined to agree that this is a two lane situation.  I'd be
> inclined to mark unpainted lanes in the cases where channelization
> regularly occurs without the pavement markings anyway.  This isn't the case
> on residential streets, as people will tend to drive right up the middle of
> such streets, only movingly right to meet oncoming traffic and maybe when
> approaching a stop sign.
>
>>
>
> Hmmm. I guess driving culture may vary from place to place in the US. I
> always keep to the right regardless of the existence of a lane markings. I
> will admit, however, that traffic studies indicate that the average driver
> will be a bit more to the center of the pavement if there are no lane
> markings. Similarly, at least in residential areas, it has been found that
> drivers will generally go slower if there is no center marking. At least
> that is the rational my local government is using to remove the center
> divider marking for traffic calming purposes.
>
> I know that road design varies over the world and even, to a certain
> extent, within different states in the United States. So this discussion is
> showing different regional points of view. A typical, or to borrow the UK
> slang  “bog standard”, American suburban residential street is wide enough
> for parallel parking on each side and space for trucks/lorries to get past
> one another [1]. Typical parking lanes are about 8 feet (2.4 meters) and a
> typical traffic lane is 12 feet (3.7 meters). So a total pavement width is
> typically around 40 feet (12.2 meters). In some parts of the world, even in
> older crowded US cities, a road of that width might be striped for four
> lanes of traffic. But a typical US residential street has no lane markings.
>
> I can see the logic of only using the lanes tag if there is paint on the
> pavement. But that leads to another issue: It is pretty easy from
> experience to glance at a photo of a road and say it is wide enough for two
> lanes of traffic. But it is much harder for me to determine a width
> accurate to a couple of feet. I don’t see a way to show a measurement error
> estimate [2] and listing something as width=40'0" implies much more
> accuracy than a guess based on a quick visual survey or imagery actually
> provides.
>
> I am rambling. To the point, if I were to add my photo [1] to the urban
> highway tagging examples page of the wiki [3] what tags should it have. My
> current guess is:
>
> highway=residential
> parking:lane:both=parallel
> sidewalk=right
> surface=asphalt
> width=40'
>
> For the specific example given by the photo, what tags would you suggest.
>
> Thanks!
>
> [1] https://www.dropbox.com/s/1g3vt0egw4ntg7q/2018_0523_
> 072821_908_173.jpg?dl=0
> [2] https://wiki.openstreetmap.org/wiki/Map_Features/Units
> [3] https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban
>
> ___
> 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] Sample tagging for highways with no lane markings

[yo paseopor]

https://www.mapillary.com/map/im/6QXgHLK26FTMlmovwuaxfg
-For these reasons it is important the local knowledge . Instead you can
see in some parts of this street some road markings at the both sides I
assure you only one car fits in the unique lane it has along the street.
Try to pass two cars. It is not the unique street with this problem at that
town (Sant Pere de Ribes).
It is a very clear case of lanes=1 / and oneway=no

For the other answer I make a petition to the non-spanish speakers as I
cannot make a correct translation of this. Please use an automatic
translator for this sentence to understand the meaning:
"No hay webos de adelantar a la Guardia Civil en su propio carril por ancho
que este sea mientras ellos estén circulando y no hagan ninguna indicación
dejando paso, no los hay."

I insist .The number of lanes based in the road marks is an exact value of
an objective tag. An estimated lanes number without markings will be the
result of a big amount of subjective errors as the first you said with my
example.

I am agree with a new extra tag called divider or road_marks to ensure
there are or not road marks.

Salut i marques vials
yopaseopor


On Wed, May 23, 2018 at 7:15 AM, <osm.tagg...@thorsten.engler.id.au> wrote:

>
>
>
>
> *From:* yo paseopor <yopaseo...@gmail.com>
> *Sent:* Wednesday, 23 May 2018 04:11
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] Sample tagging for highways with no lane markings
>
>
>
> oneway=no
>
> lanes=1
>
> https://www.mapillary.com/map/im/jYQQwOGMPC6imwyGhMHMCg
>
>
>
>
>
> I would consider that wrong.
>
>
>
> lanes=1
>
> oneway=no
>
>
>
> is a road that is so narrow that opposing traffic can only pass by slowing
> down and making use of shoulder/verge to pass each other. Or maybe even has
> the need to look for a https://wiki.openstreetmap.
> org/wiki/Tag:highway=passing_place to be able to pass each other (like
> the example image shown on that page).
>
>
>
> What your image above shows is pretty clearly a lanes=2, which you can see
> very well by just following the street a few meters:
>
>
>
> https://www.mapillary.com/map/im/6QXgHLK26FTMlmovwuaxfg
>
>
>
> as you can see, there are clear road markings establishing two lanes.
>
>
>
>
>
> Here is an example of the roads I mean that should be tagged with
>
>
>
> lanes=2
>
> divider=no
>
> (oneway=no is normally implicit, so no need to tag it when there is no
> reason to wrongly assume a road should be oneway)
>
>
>
> https://www.mapillary.com/map/im/KQjnvNHHcOLKZj2P4pB2WQ
>
>
>
> You can see that the roads generally have no marked lanes, but at the
> T-intersection there are markings that make it clear the road is intended
> to be a two lane road.
>
>
>
> Cheers,
>
> Thorsten
>
> ___
> 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] Sample tagging for highways with no lane markings

[yo paseopor]

Case B: some pics before
https://www.mapillary.com/app/?lat=41.46210902249982=12.874923250143638=17=ygjsHztch9KkrIILOPA3Jg=photo=0.4957587433175=0.4652742508751958=0.3348214285714282

lanes=1, impossible to be estimated:lanes=2 , instead of some itallian
driver would try to overtake you for the right. There is no invitation at
all, please be clever, be serious, think about all the vehicles that may
use some osm app with these values. And also map for the safety of the
different kind of drivers.

Salut i marques vials
yopaseopor


On Wed, May 23, 2018 at 10:35 AM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

>
>
> 2018-05-23 8:07 GMT+02:00 José G Moya Y. :
>
>> @Martin:I don't want to be a troll, but I feel there is some
>> inconsistence between answers in this thread and answers in cycle:lanes
>> last week.
>>
>
>
> Here are mapillary images for the 2 examples I gave,
> Case A, for me lanes=2, unmarked: https://www.mapillary.com/app/
> ?lat=42.19987521996=12.37958488039=17.080616229522438=
> dxeGLQKJpAKONnVjOyHCuQ=photo=0.5039420595168772=
> 0.5520701196885281=0
>
> Case B which is larger than case A, with 1 lane marked (but effectively 2
> lanes traffic), for which I agree to tag lanes=1
> https://www.mapillary.com/app/?lat=41.45943826996552=12.
> 876404262878054=17=r-semo9mp70dR08qELPgYw=photo
> https://www.mapillary.com/app/?lat=41.43346094747278=12.
> 935902815838062=15.827449025905015=3xxozoDy6nVpc8bd3-d-Fw=
> photo
> (there's no imagery for the exact spot I mentioned before, the images
> demonstrate the way it is built is inviting to use the shoulder)
>
> 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] Sample tagging for highways with no lane markings

[yo paseopor]

Javier, I don't know if it has enough sense to use a new tag to tag
something we have already tagged or not. But try it in Spain, overtake a
Guardia Civil de tráfico car or motorbike in a oneway one-wide-lane and
expect it ;)

Salut i marques viales
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Sample tagging for highways with no lane markings

[yo paseopor]

You have other tags to mark there is more than one direction:
oneway=no

I think it is important to  keep the sense of the wiki, why?
Because , with data you can "imagine" (or render) some kind of reality. It
is not the same:

1
oneway=no
lanes=1
https://www.mapillary.com/map/im/jYQQwOGMPC6imwyGhMHMCg

2
oneway=no
lanes=2
https://www.mapillary.com/map/im/xg8szNBm0vd2ESAkjds1DA

3
oneway=yes
lanes=1
https://www.mapillary.com/map/im/OxpRJfW_9qy_Z8QL4NoWXw

4
oneway=yes
lanes=2
https://www.mapillary.com/map/im/oENxpXhruhvcFszNlkudtg

Think about it : with more than one lane you can overtake legally. With
only one lane you cannot overtake in your same direction because you don't
have any lane to pass by. If the streetof only one lane is wide enough you
can pass a stopped car, but you cannot overtake it if they are moving also.
Ask it to the police. I think is interesting to keep the meaning of the
tagging scheme.

May we have to retag all the oneway=no without lanes all over the world?
May we have to add a new tag called divider (or similar?) . For me if
divider=yes lanes > 1 , if divider=no lanes = 1 so I don't need a new tag
to remark it.

Salut i marques vials (Health and road marks)
yopaseopor

On Tue, May 22, 2018 at 7:45 PM,  wrote:

> Personally, I tend to tag roads that are wide enough for 2 lanes (two cars
> can pass each other without noticeably slowing down) and which are clearly
> meant to be two lane (one lane each direction) roads with:
>
> lanes=2
> divider=no
>
> Yes, I know that is in violation of the strict reading of the wiki, but I
> feel it makes sense, and as far as I can determine, tagging roads that are
> meant to have two lanes with lanes=2 even in the absence of such road
> markings seems to be pretty widespread practice. (The use of the divider
> tag isn't very widespread, but again, I feel it makes sense in this
> context.)
>
> Cheers,
> Thorsten
>
> > -Original Message-
> > From: Tod Fitch 
> > Sent: Wednesday, 23 May 2018 01:18
> > To: Tag discussion, strategy and related tools
> > 
> > Subject: [Tagging] Sample tagging for highways with no lane
> > markings
> >
> > In reviewing the wiki in preparation to fixing some of my older
> > mapping, it seems there is an inconsistency in how to tag a road
> > that is wide enough to two lanes of traffic but is lacking lane
> > striping.
> >
> > In the lanes description [1] it says "the lanes=* key should be
> > used to specify the total number of marked lanes of a road." But in
> > the out of town highway tagging sample page [2] with a photo
> > described as "smaller road, maybe tertiary with appropriate
> > administrative status" it shows a lane count on a road with no
> > markings.
> >
> > Am I correct in believing that the example photo should have its
> > tagging changed, dropping the lanes=2 and adding a width tag (if
> > the width is known or can be reasonably estimated)?
> >
> > My current interest is in fixing the tagging for residential roads
> > that are wide enough for bi-directional traffic with legal parallel
> > parking but have no markings on the pavement. I don't see a exact
> > match to that in either the urban [3] or rural highway [2] tagging
> > example pages.
> >
> > To use the street I live on as an example, am I correct that a
> > residential road with bidirectional traffic and parallel parking
> > with no markings should be tagged as:
> >
> > highway=residential
> > surface=asphalt
> > parking:lane:both=parallel
> > width=40’0"
> > maxspeed=25 mph
> >
> > If, and only if, a center strip is added then lanes=2 should be
> > added. (I actually measured the width in this case but for hope to
> > be able to use the measurement tool on aerial imagery in JOSM for
> > most cases).
> >
> > Is my current understanding correct? If so, I will update the wiki
> > pages for both the urban and rural highway tagging examples to
> > reflect that and will take some photos of the roads in my area to
> > make additional examples.
> >
> >
> > [1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
> > [2]
> > https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_
> > town
> > [3]
> > https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban
> > ___
> > 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] Sample tagging for highways with no lane markings

[yo paseopor]

I'm not agree with that , Martin
Road markings are real, touchable, checkable, objective...estimated width
and estimated lanes not. OSM data serves to a lot of apps with lane
indications, if we drop this then the apps will show erroneous information
or less exact information.

 One of the problems of driving in Rome is that people overtakes you in a
one-lane-street for every side they can turn it. If police would punished
them this problem will not exist as not exists in the other countries of
Europe.
Tagging in OSM has to be clear, scalable, objective...as road marks should
be.

Salut i marques vials
yopaseopor


On Tue, May 22, 2018 at 5:18 PM, Tod Fitch  wrote:

> In reviewing the wiki in preparation to fixing some of my older mapping,
> it seems there is an inconsistency in how to tag a road that is wide enough
> to two lanes of traffic but is lacking lane striping.
>
> In the lanes description [1] it says "the lanes=* key should be used to
> specify the total number of marked lanes of a road." But in the out of town
> highway tagging sample page [2] with a photo described as "smaller road,
> maybe tertiary with appropriate administrative status" it shows a lane
> count on a road with no markings.
>
> Am I correct in believing that the example photo should have its tagging
> changed, dropping the lanes=2 and adding a width tag (if the width is known
> or can be reasonably estimated)?
>
> My current interest is in fixing the tagging for residential roads that
> are wide enough for bi-directional traffic with legal parallel parking but
> have no markings on the pavement. I don't see a exact match to that in
> either the urban [3] or rural highway [2] tagging example pages.
>
> To use the street I live on as an example, am I correct that a residential
> road with bidirectional traffic and parallel parking with no markings
> should be tagged as:
>
> highway=residential
> surface=asphalt
> parking:lane:both=parallel
> width=40’0"
> maxspeed=25 mph
>
> If, and only if, a center strip is added then lanes=2 should be added. (I
> actually measured the width in this case but for hope to be able to use the
> measurement tool on aerial imagery in JOSM for most cases).
>
> Is my current understanding correct? If so, I will update the wiki pages
> for both the urban and rural highway tagging examples to reflect that and
> will take some photos of the roads in my area to make additional examples.
>
>
> [1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
> [2] https://wiki.openstreetmap.org/wiki/Highway_tagging_
> samples/out_of_town
> [3] https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban
> ___
> 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] Is it possible to have highway=unclassified with ref tag?

[yo paseopor]

The topic is the classification of OSM is not the same as countries have,
and this make troubles. An UNCLASSIFIED road as its name says it is
unclassified...but when you need some road classification with a step more
than tertiary then you use unclassified, and if the road has ref...you put
in then. Why don't you reorder the tertiary roads? They also catch your
less thant tertiary roads in your country. Also it is the same problem with
trunk or primary: whatis the difference between trunk of one lane per
direction and a primary road? Also you have the issue if you consider the
administrative classification as we do some countries: a trunk may be a
trunk because being managed by one specific administration? WTF? Is it good
for the map? All the roads by a local administration should be
unclassified? It is a complicated problem. I suggest to reclassify the
other roads in their grades to make unclassified roads unclassified as the
name says it.

Salut i carreteres sense classificar (Health and unclassified roads)
yopaseopor

On Mon, May 7, 2018 at 5:11 PM, Richard Welty 
wrote:

> On 5/7/18 10:35 AM, Rory McCann wrote:
> > On 06/05/18 09:41, Mateusz Konieczny wrote:
> >> I am pretty sure that it is entirely possible to have
> >> highway=unclassified
> >> with officially assigned and posted ref number, but I wanted to check
> >> whatever my edit on
> >> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
> >> was correct.
> >
> > Yes it is! AFAIR the "highway=unclassified" comes from British usage,
> > where "unclassified" was a road classification. Yes it sound silly. I
> > think the refs in the UK aren't signposted, but roads with the
> > unclassified classification (!) have "U" refs (e.g. "U123", instead of
> > "A123" etc).
> by convention if a ref is unposted, many folks use unsigned_ref instead
> of ref
> for example, pretty much all the rural paved roads in North Carolina
> have state
> assigned refs, but the ordinary town roads are unposted.
>
> i can imagine a jurisdiction which uses signed refs on generic
> "unclassified" roads,
> but i've never seen one. i would be reluctant to explicitly rule out the
> possibility.
>
> richard
>
> --
> rwe...@averillpark.net
>  Averill Park Networking - GIS & IT Consulting
>  OpenStreetMap - PostgreSQL - Linux
>  Java - Web Applications - Search
>
>
> ___
> 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] highway=stop and highway=give_way to traffic_sign=stop and traffic_sign=give_way

[yo paseopor]

Hi!

I'm introducing myself. I'm yopaseopor . I'm from the Spanish and Catalan
Communities of OSM. Also I have a particular interest because of the map:
the traffic signs and their meaning.
Checking the map I have found a "glitch" on my mind: The situation of
highway=stop and highway=give_way.
I see traffic_sign=city_limit or traffic_sign=maxspeed but then I see
highway=stop or highway=give_way. I don't know why these two traffic signs
are under the tag highway and not the tag traffic_sign itself. Do you know
why? If you know it , please explain it to me. Thanks.

Also I wish to make a proposal to the community: "translate" all the
highway=stop and highway=give_way to traffic_sign=stop and
traffic_sign=give_way.
What do you think about it ? Let's start the discussion. Thanks for reading.

Salut i senyals de trànsit (Health and traffic_signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Mapping metro (subway) stations

[yo paseopor]

 Hello
 I have a problem. I was remapping subway stations in Barcelona (Spain),
following https://wiki.openstreetmap.org/wiki/Metro_Mapping . Also I was
connecting the stations with some indoor mapping, with corridors as ways
and tags with levels, basically, but they doesn't appear in OpenLevelUp for
example, instead of having the correct tags because they are not areas
(like station in https://www.openstreetmap.org/node/5307549252) . Then I
started to change the concept station combined with an indoor=room and make
it an area instead of a node (like
https://www.openstreetmap.org/way/555806662#map=19/41.38741/2.16943=D )
to looks reasonable and more realistic. In OpenLevelup looks acceptable (
https://openlevelup.net/?l=-1#19/41.38738/2.16900) but Mapsme subway
validator (http://osmz.ru/subways/spain.html) says no way. What is the
correct way to tagging it? I am not agree with the fact that one data is
not compatible with the other . I believe in "don't map for the render" but
I am not sure what is the correct way to map it. So Can you tell me your
opinion about that?

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

Re: [Tagging] tagging for decaying features

[yo paseopor]

No, In my opinion is not a good idea to delete an existing thing in OSM.
History is also part of OSM. Why do we have to respect the historic thing
in a node or way not deleting them if then we then delete the whole thing.
Lifecycle prefix can achieve these items inside OSM. Also it is not a good
idea to expulse the information to other third or related projects...that
one day can be gone. Because if the info is in OSM one day other related
project can recover the map with that data (e.g. parking map). If the
information is in other related project, when the project dies (as Mapzen
for example) , information dies too. If the info disturb one good idea
would be change osm-carto, the render, but no the database as it is not a
good idea in other situations. We don't map for the render.

Salut i història (Health and History)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:lanes? (specific signal types for certain lanes)

[yo paseopor]

I will not discuss here if continuous_green would be a realistic value with
full possibilities in a future. But according to taginfo [1] there are only
6 nodes around the world.
Also I am asking myself: if continuous_green is continuous green
really...is it usefull for the map? (because there is no action here, it
would be a traffic light, a painting, or some big commercial ad pannel in
the middle of the highway).

In this case I think it would be more useful and accurate to separate the
left lane a couple of meters before it really does and put a traffic signal
for this new way with one lane that turns left. I think it would be
unusefull to put a traffic signal on the other way with continuous green.

That's my opinion. What do you think?

Salut i semàfors (Health and traffic signals)
yopaseopor

[1] https://taginfo.openstreetmap.org/search?q=continuous-green#values
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Variable Message Signs on Highways

[yo paseopor]

I think it is an interesting question. I explain my opinion about that.
Instead of being about one kind of information, as their name its called
variable it is not possible to determine in all cases what exact
information you will have from them. But you can map about the types
because of the kind of panel you are mapping. In the PDF file  above you
can see a lot of variable signs with one kind of information only.

Here in Spain variable information big panels are ES:S800 / S810 as you can
see in https://www.boe.es/legislacion/codigos/abrir_pdf.
php?fich=020_Codigo_de_Trafico_y_Seguridad_Vial.pdf (Spanish traffic law).
As the Spanish government (Ministerio de Fomento) give us an inventory with
all the traffic signs in their roads Spanish government handle this as a
"normal trafic sign" with the only observation it is electrical or variable.

For panels with variable speed I would use

traffic:sign:forward=ES:R301
maxspeed:forward=variable
side=right

As you cannot define the exact information you will get through the panel I
think you can use the https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging to describe the panel itself and considers
it a traffic sign.

For big panels with unspecific target of the information:

traffic_sign:forward=ES:S800
side=up
Other info you want

I hope it will be useful this approach.

Salut i senyals de transit variable (Health and variable traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

[yo paseopor]

It is interesting your petition. My point of view is , even the meaning of
two traffic signs in differents places would be the same, it would be
different traffic signs. In some countries there are other codes for the
road marks (but with the same meaning) so they aren't the same traffic sign
so they can't stay at two positions (right and down or up side)

When there is two traffic signs in one pole you can tag it with subtag
numbers as the Finnish Commnity does. Example with traffic_sign:2:forward=
or traffic_sign:2:backward. It is important because when there is more than
a traffic sign one is active until the limitation or the situation that
informs you the second. Example: in https://www.mapillary.com/
map/im/7NffYKT31sYbbZSqQutpSw this specific maxspeed limit is only for the
crossing. Once you have passed the crossing you will have the implicit
maxspeed limit or other. For this reason it is important to tag the order
of the traffic sign.

People from Mapillary do that, they know how the OSM community does not
want automatted imports but they made available to tag some traffic signs
detected in their pics through the JOSM plug-in. I have also talk to them
and they are in contact for updates.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

[yo paseopor]

As the proposal is evolutioning in a ways I can't manage (for example
because I don't know how to build the models in Kendzi3D with relations or
at the style) I wish all of you could afford ways and help with specific
examples,models , scripts,code in the wiki proposal or the github, for
example.

Thanks
yopaseopor
https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

[yo paseopor]

On Sun, May 21, 2017 at 9:47 PM, Tobias Knerr  wrote:

> On 21.05.2017 14:05, Colin Smale wrote:
> > So, in simple language, WHY do we put traffic signs into
> > OSM?
>
> The use case I'm interested in is having the location of the physical
> object available, e.g. for 3D rendering. This is also why I'm in favour
> of placing signs in their actual on-the-ground location.
>

As you can see in http://imgur.com/gallery/SgE90 with Kendzi3D JOSM
plugin you can locate the traffic signs belonging to a way.

>
> I also find it useful to know the exact traffic sign combinations that
> the other tags are derived from, as ambiguities in tagging can cause
> that information to be muddled (e.g. the path/designated/official
> issue). If it's only about that use case, though, I tend to use the
> traffic_sign tag on ways, rather than separate nodes.
>

to get the direction for the node I put the node in the way. The way has a
direction. I specify the position of the node relative to the way
(forward/backward). Also I specify the side with this tag
side=right/left/both

Salut i senyals de trànsit (Good health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

[yo paseopor]

On Sun, May 21, 2017 at 8:46 PM, Mark Wagner  wrote:

> On Sun, 21 May 2017 22:23:12 +0900
> John Willis  wrote:
> >
> > Warning signs - not restriction signs - such as stop ahead, curve
> > ahead, falling rock, animals, etc do present a chance for the
> > presence of the sign's node to offer a notice to whatever is parsing
> > the way Data and present that to the driver/user when in proximity to
> > said warning.
> >
> > "Stop ahead" signs in Japan are really strong  in some places
> > because perpendicular roads meet in rice fields where people may be
> > used to being on the road with others stopping for them. Having the
> > mapped sign *could* be beneficial to a way because the warning is
> > usually for that spot.
> >
> > https://www.flickr.com/photos/javbw/11091338426/in/album-
> 72157638113676925/
> >
> > (To-ma-re, like putting S-T-O-P on 4 signs before the triangle-shaped
> > stop sign)
> >
> > But even that could be a property of the way rather than inferred by
> > the point proximity of the sign (because I assume the sign node  will
> > be placed with precision not where it is actually located, rather
> > than on road's way, because this is micromapping, after all)
>
> This use of warning signs runs into the problem that data consumers
> don't have a good way of figuring out which signs go with which
> directions of which roads.  Yes, the 90% solution is to say "the sign
> is associated with the road it is closest to, and the direction of
> travel corresponding to the side of the road it is on", but there are
> exceptions, both common and unusual.
>

Node could be in a way.
Way has a direction
We can use forward and backward keys, and also side=right/left/both to
orient the traffic_sign.

>
> Probably the most common exception in the United States is "no
> passing" signs (a common pattern is to have the sign on *both* sides of
> the road, so that someone in the process of passing a large truck will
> still see it), and the second-most-common is advisory speed limit signs
> placed on the outside of the corresponding curve.  Various
> clarification signs in close proximity to confusing intersections would
> have issues with "which road" rather than "which direction".
>

If the node is in a specific way this sign belongs to that way

>
> Warning signs are something that data consumers could certainly make
> use of, but we need some way of explicitly coding which direction of
> which road they apply to.
>

Is not enough to belong to a specific way or to have it closest?

Salut i senyals de trànsit (Good health and traffic signs
yopaseopor






Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Time is now: tag ALL traffic signs in OSM

[yo paseopor]

As you know Mapillary has released a layer with the results of their
recognition system of traffic signs to JOSM and iD (I wish OSC will do the
same soon) . This means now we have a reliable and open (CC) source to map
traffic signs in a easy and complete way inside OSM (instead of the
work-in-place,of course ). The thing is: Mapillary is ready...but is
OpenStreetMap ready? I think it would be.

How? With an advanced and extended traffic signs tagging scheme like
https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
or similar that enables the community to tag nor only the 9 main kinds
(stop, give_way, traffic_signal, maxspeed, minspeed, maxaxleload, maxweight
maxlenght maxheight, city_limit) but the others less famous (e.g. in Spain
we have more than 300 different traffic signs, with nowadays scheme you can
cover...only 10% without using country code).

The idea is simple: following the scheme like key=traffic_sign >
"subkey"=value (maxspeed would be a good example) we can afford almost the
totality of the traffic signs. We can use the classification you have in
every countries' traffic law.
To clarify also the meaning and the drawing of the traffic sign we can use
also the countries traffic sign unique code for every traffic sign.

Example:

traffic_sign=warning
warning=maxheight
maxheight=4.4
traffic_sign:forward=NP:B20
side=right

to have
https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Nepal_road_sign_B20.svg/100px-Nepal_road_sign_B20.svg.png

The system has to be scalable to be able to expand it for every country in
the world, for every traffic sign (now in taginfo you can find more than
1+ in 40 countries), so I think it will be possible. It would
interesting talk also with Mapillary's people (I have contact with traffic
sign recognition system team)  or OSC People.
What do you think?

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Link roads : the Michelin style

[yo paseopor]

If you are thinking in the real quality of the link you will see link
refers the most cases in the higher investment road, so in a real quality
aproach links are refered to the major road.

Salut i mapes
yopaseopor


Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging 'advance' turn restrictions

[yo paseopor]

Ok,
It is not the easiest way of the World...but it is not the most
complicated. First we think to start of the best aproximation: the REAL
aproximation so:
-If the marks are only marks and not physically separation...don't separate
in different ways...because is not REAL.
-If the way is double direction way you have to tag it with the appropiate
direction scheme. It is not difficult: forward and backward.
-If this road is in this way (with these traffic signs, with these
restrictions, with these road marks...is for a good reason as you say in
the first email)

So we have to tag it precisely.Then ...What we have in Openstreetmap to tag
it?

In OSM you have (without relations) :

-change:lanes= to "draw" the lines (and mark the properties these lines
have, remember there are traffic signs: horizontal traffic signs. In some
countries they have traffic sign code too)
-turn:lanes= to "draw" the arrows (and of course to add the value to each
lane you have
-destination:lanes= to "draw" the destination of each lane because in this
example every lane has its own destination.

Also you know (Hi I'm presenting myself  I'm the crazy traffic sign JOSM
guy - traffic_signs_XX [4] ) I am worried about vertical traffic signs so
with extended traffic sign proposal [5] you can "draw" all the traffic sign
you have in the pics. Sorry, there's no Mapillary or OSC pics (guys c'mon!
;)


Let's start what I would do in:

[1]
https://www.google.com/maps/@42.813784,-73.9338004,3a,75y,27.92h,66.85t/data=!3m6!1e1!3m4!1sBwJUpJjqy_IH5HP1SmzcFQ!2e0!7i13312!8i6656

lanes:forward=3
change:lanes:forward=no|no|no
turn:lanes:forward=through;left|through|trough;right
destination:lanes:forward=| Seward only|

With extended traffic sign proposal there would be two nodes, at the nearly
same position telling:

For one node before the cross:

traffic_signs:forward=US:R3-6
turn:destination=through;right
side=up

For another one node nearly before the cross:

traffic_signs:2:forward=US:R3-5a
destination=Seward Only
side=up

(Note for local traffic engineers. I would change these to traffic signs
with US:R3-8 or US:R-8b [6] , giving the information together I think is
easier to take a decision).

Ok we continue driving

[2]
https://www.google.com/maps/@42.8147778,-73.9331364,3a,75y,26.57h,57.2t/data=!3m6!1e1!3m4!1suJlScKIDzM8Gu0iu2GslFA!2e0!7i13312!8i6656

lanes:forward=3
change:lanes:forward=no|no|no
turn:lanes:forward=left|left|right

With extended traffic sign proposal there would be three nodes, at the
nearly same position telling:

For one node before the cross:

traffic_signs:forward=US:R3-5
side=up
turn:destination=right
destination=Union St Only

For another node nearly before the crossing:

traffic_signs:2:forward=US:R3-5
side=up
turn:destination=left
destination=Seward Place Only

For another node nearly before the other ones:

traffic_signs:3:forward=US:R3-5
side=up
turn:destination=left
destination=Union St Only

Ok, and then we will finish our drive with turning left and then...
[3]
https://www.google.com/maps/@42.8153897,-73.9341984,3a,75y,294.27h,81.64t/data=!3m6!1e1!3m4!1s7sxU233GvgJ9LBbSAC4_ng!2e0!7i13312!8i6656

lanes:forward=2
change:lanes:forward=no|no
turn:lanes:forward=through|right


Of course If I were a local engineer I would reforce the road marks and
traffic signs with

traffic_signs:forward=US:R3-5
turn:destination=right
destination=Seward Place Only
side=up

For another one node nearly before the cross:

traffic_signs:2:forward=US:R3-5a
side=up

This is How I would map these trips.
I hope it will help you
yopaseopor

PD:

[1]
https://www.google.com/maps/@42.813784,-73.9338004,3a,75y,27.92h,66.85t/data=!3m6!1e1!3m4!1sBwJUpJjqy_IH5HP1SmzcFQ!2e0!7i13312!8i6656
[2]
https://www.google.com/maps/@42.8147778,-73.9331364,3a,75y,26.57h,57.2t/data=!3m6!1e1!3m4!1suJlScKIDzM8Gu0iu2GslFA!2e0!7i13312!8i6656
[3]
https://www.google.com/maps/@42.8153897,-73.9341984,3a,75y,294.27h,81.64t/data=!3m6!1e1!3m4!1s7sxU233GvgJ9LBbSAC4_ng!2e0!7i13312!8i6656
[4] https://josm.openstreetmap.de/wiki/Presets
[5]
https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
[6] https://mutcd.fhwa.dot.gov/pdfs/2009r1r2/part2b.pdf (Page 16)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[yo paseopor]

I would start a "definitive thread" with all the options, all the
possibilities, all the points of view, all the information and then,
passing all to the wiki with a votting or aproved by list complete
proposal. Some people is watching us and in a near future will try to
collaboret with us so it would be interesting to be ready to this "big
thing"

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

On Thu, Mar 23, 2017 at 1:41 AM, Tod Fitch  wrote:

>
> “stop:forward=yes” & “stop:backward=yes” seem like they are putting a
> value in the key as the stuff to the right of the equals may never be
> anything other than “yes”. On the “lanes:forward” and “lanes:backward” keys
> at least the values carry variable values.
>

Sorry, but you are wrong if you are talking of "my idea" . I don't view any
future to a unique key for every traffic sign (would be interesting for
every group as a concatenation of pairs as: traffic_sign=warning
warning=bump), I see varied values. So as you can see with the example of
the proposal [1] , the result will not be stop:x = yes instead of

highway=stop >> kind of traffic sign in a unified scheme
traffic_sign:forward=ES:R2 >> Spanish code of the traffic sign (wil be good
for rendering the exact image)
side=right > side of the road it is.


>
> There is already a “traffic_signals:direction=forward | backward” usage.
> “stop:direction= forward | backward” and “give_way=forward | backward”
> would fit that schema too.
>

I think a scheme with the various values is more complete than create a key
for every traffic sign because then every traffic sign will fit in every
country with the same key, as you can see in Taginfo [2].

>  Will it become forbidden to split ways on nodes with stop sign or traffic
> signal tags, because it breaks the information tagged on those nodes?
>
> To split a way specific in that node would not be the best option but the
only problem will be if you connect other way to that node, if you split a
way but you have the same direction in the two segments of a way I don't
think there will be any problem with that.Also you can split the way next
pixel of the pixel of the traffic sign.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging#Traffic_signs_presets
[2] https://taginfo.openstreetmap.org/projects/traffic_signs#tags
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[yo paseopor]

On Thu, Mar 23, 2017 at 9:03 PM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> >
> > - highway=stop+direction=forward node on the incoming way... Only
> >  covers the simple case but covers it simply
>

I prefer the subkey :forward / :backward because then we save one pair of
key=value we can use to put the future unification of the meaning of
traffic signs groups.

while this might work often with stop signs it'll hardly work with maxspeed
> signs, because the changing maxspeed requires to split the highway, so that
> there would be 2 highways ending in the same node and forward would not be
> clear of which way.
>
For consistence , whit two ways with the same directions, which problem do
you have if the splitted way marks the direction...to the same direction so
is coherent between nodes and the two ways?

>
> When I map traffic signs it's mostly city limit,
> maxspeed/maxweight/maxheight and I do it generally for fellow mappers
> (including myself) because the effect of the sign I will map on the highway
> (typically linear, not just a point). Mapping on the side of the road has
> worked out perfectly for this scope.
>

Using the :forward/backward scheme and with Kendzi3D I get the situation
very similar to reality as you can see in these pics, [1] and [2]. I can
map any traffic sign you have in any traffic law which have a code. People
like Mapillary do some classification we can "copy" or use/propose similar
in a future unification of the keys with meaning for traffic signs , fa
away than only city limit,
maxspeed/maxweight/maxheight/stop,give_way,traffic signal.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor

[1] http://imgur.com/7FCO9ec
[2] http://imgur.com/WDUAWSa
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

>
> Anyone else with an opinion ? Two of us might be the very beginning of a
> consensus but we need a little more before even putting a proposal
> page up on the wiki...
>

I think to include direction inside the tag with a subkey :forward
:backward following the scheme for lanes and so one are the best option
instead of using a specific key as direction because we save one key, and
we follow a well-known scheme.
Other thing is the side of the road the traffic sign is , as it changes the
form and the style of it (motorway panel vs. little traffic sign on the
right side of a road)

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

Re: [Tagging] Adding directionality to stop signs

[yo paseopor]

On Wed, Mar 22, 2017 at 11:31 AM, Paul Johnson  wrote:

>
> Turn restrictions are extremely common and managed using relations, so we
> know relations don't have to be hard.  It's possible for the editors to
> adapt to make this easy.  There's no real reason enforcement and similar
> from/to/device/force type relations can't be made easy at the editor level.
>

I ask why we need a relation to put a traffic sign if it is in a way (not
at intersection), and with the information of the correspondence of the
direction of the way it is with a relation . Is duplicate work?

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

On Mon, Mar 20, 2017 at 6:47 PM, Kevin Kenny 
wrote:

>
> By contrast, traffic signs are inherently directional. Without a direction
> indication, we really have no way of conveying "traffic on the side
> street has to come to a stop/give way here; traffic on the main street
> can proceed relatively unhindered." There isn't quite a universal
> consensus on how to convey that information.
>
What appears to be most popular, as you have observed, is to place the stop
> or give_way
> near, not upon, the intersection, as a node on the way that it applies to,
> and apply a direction=* tag to indicate the direction of traffic flow
> that will be facing the sign.
>

The difficulties I have found doing as you say are two:

1-with :forward :backward scheme you are aproaching at others that affects
to the way: maxspeed,overtaking. Using good subkeys you are saving one
innecesary key (direction) thus forward and backward are...directions.
2-putting the node at the side visually is more realistic...but it is so
unuseful as be a independent node, so it is better to put it IN the way and
mark its position with subkeys or other tags as side relatives to this way
the node is in.


> I don't think with the present state of data consumers, that there is
> necessarily a "right way" to do this. Ultimately, it will be the data
> consumers that will decide what the "right way" is: tag your
> STOP and YIELD signs correctly, and the applications will warn
> drivers; tag them wrong, and they won't.
>

I know traffic signs were not an important thing in OSM. In 2013 when I
have started to think about it and move me to do something about that there
was only a plug-in for JOSM. And then, when you opened that plug-in you can
saw 4 country presets with about 30 traffic signs-per-country. Putting
inside the plug-in the +300 Spanish traffic signs was a curious thing.
Making a style that show all the traffic signs and not only Maxspeed was
"interesting".
Thinking about all the rest of the European Countries was logical (why
Spanish and not the other European traffic signs...or the world traffic
signs?)

We are not in 2013. Nowadays is 2017.
In this years we saw a project called Mapillary that had a traffic sign
editor and automated recognition for 40 countries. We saw other project
called OpenStreetCam with automated recognition and a editor for
destination signs (internally yet).
We know these projects are around other big names like Toyota, Telenav. We
know the strategy of the big one Google: Street View exists to give data to
their automated cars, Google Captchas now are from traffic signs
recognition.
In this scenario we start to have some governments give us the permission
and the data to put traffic signs into the map.
So, for a important thing in the "future maps" (traffic signs) we have
three different sources (Mapillary, OSC and Governments)
Presets, styles, all this stuff will reach the most populated countries of
the World soon or later. You will have some tools to do this job...for all
main countries. OSMAnd does not understand stops? no problem, there will be
an app that understand and warning you about ALL the traffic signs (this
will happen soon or later).
OSM is capable of have this data inside it. We have to propose a rich
scheme with all the possibilities and make it work. I have proposed one but
I hope there will be others and better or make better the one I have
proposed. Then other apps will join us because people and data are ready.
Are we ready? Is OSM ready? I think so.

Salut i estiguem preparats (Health and Get Ready)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[yo paseopor]

On Mon, Mar 20, 2017 at 9:57 AM, Martin Koppenhoefer  wrote:
>
> whether the node is independent or part of one or more ways depends on the
> situation and mapper. Even if the node is now part of just one way, in the
> future this might change and it can become member of more ways (e.g. if the
> way it is on is split at the node of the stop sign or if another way is
> connected to the stop sign).
>

No, nodes for traffic signs has to be of one way. When mappers need it
mappers duplicate the node...like ATMs and banks or the poop dog trash.
Traffic signs are also before the cross or the situation you have it (it
make no sense to warning you of a hazard...when the hazard is passed by.
All features of OSM has a good way or good practise to map it, we have to
decide which one is the most useful , simple, easy and complete.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[yo paseopor]

On Mon, Mar 20, 2017 at 9:46 AM, Topographe Fou 
wrote:

> Hi,
>
> I put stops, give ways and traffic light where the car has to stop/yield
> which can be far from the position of the sign (for instance in the US
> where the light is after the junction, thus may not be crossed if you
> turn). Also on narrow junction you may have the lights at the junction but
> the stop line some meters before to let buses make there turn.
>
> To match all use cases a new scheme has to consider the tagging of both
> stop/yield positions on the road and position of the sign/light (like for
> bus stops). One may think of relations as one explicit way of linking all
> those informations (like restricted turns). Any algorithm which try to
> deduce a position on a road from a position sign will be buggy at some
> points and greedy.
>

It is possible to tag lines. Road marks are also traffic signs (things we
call traffic signs are VERTICAL traffic signs, road marks are HORIZONTAL
traffic signs).

In a lot of countries road marks have their own traffic sign code so we can
use the down value of side key (to know in which side of the street is or
if it is like a vertical motorway panel) to map road marks.

e.g., As you can read on Norway traffic law [1]

traffic_sign:forward=NO:1036
side=down

will be the road mark for give way


> Then we have to consider that at some junctions the direction/orientation
> of 1. The way 2. The stop/yield line (if any) and 3. The sign/light may be
> three different values!
>


Exact position...is exact position, with aerial imagery you can know where
it is road marks. 1 is given by the subkey :forward :backward in relation
to the way.2 can be a node with the traffic sign 3 can be another node with
the road mark code.

Salut i marques vials (Health and road marks)
yopaseopor

[1]
http://www.vegvesen.no/trafikkinformasjon/Lover+og+regler/Trafikkskilt/_attachment/1089676?_ts=1511acde580_title=Skiltbrosjyre-2015.pdf
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[yo paseopor]

On Sun, Mar 19, 2017 at 8:30 PM, Tod Fitch  wrote:

> Unfortunately, I’ve not been able to make the Kendzi3D JOSM plug-in work
> for me. I’ll continue to poke at it from time to time as it looks
> intriguing.
>

I have told Kendzi now it is not working (with version 11425 it does) , but
as you can see in imgur [1] I have done some capture I can assure it works
with more than 9000 traffic signs kinds from 32 countries.


> I did not feel confident in tagging lanes, especially turn lanes, until I
> found the JOSM plug-in that allowed me to visualize and check the tagging
> before committing the changes. This looks like one that would allow me to
> start looking into 3D tagging at some point in the future.
>
> In the meantime, I notice that the direction on the sign in the image is
> not set with a “direction=*” tag but rather with a
> “traffic_sign:direction=*” tag.
>

When I had discover Roadsign plug-in I wanted a complete scheme for my
favourite subject. At first approach in 2013 [2] I know traffic signs need
somewhat to "localize exactly" and the option in Roadsign plug-in was a key
direction= ) .In parallel I have continued with a Style for JOSM. Also I
have found a way to show in "3D" in a plug-in of JOSM called Kendzi3D and
develope the possibility to show this traffic signs with the orientation
with direction= key.

But later, as Roadsign updated were so difficult and I have not control of
it, when I have finished all three legs, I have checked the wiki and
discovered Finnish approach [3] and Deutsch aproach [4] and decided to
start a preset for JOSM, and in the preset and with comments for some user
JOSM did not control direction tag I have changed all the scheme of the
preset to traffic_sign:forward/backward [5]. I have started with my
country: Spain. Last big changes version was in 2016. And one day I saw
someone localized to French some strings. I had checked Taginfo and
Overpass and watch some Spanish traffic signs were around the world (I saw
Spanish traffic signs...in Texas USA ) .So I have started to investigate
other countries. I have took information of other countries as Finland or
Belgium and start with Belgium because they have less traffic signs than
other european countries. But I was so late.

Preset was so huge and also I a bad programmer than it started to make many
problems to JOSM, and in a issue they say me "split the preset" [6] . Now
you have 32 preset from 9000 different traffic signs with forward and
backward.

It seems to me that this area could use some thought and, once
> “bikeshedded” enough, simplified and better documented.
>

I think it is a good opportunity to give traffic signs the importance they
have. The scheme of :forward/backward, the two-letter country code allows
to add any traffic sign of any country.


>
> I recall seeing places where a one way street has a stop sign where it
> connects with another street and a single pole has a stop sign on one side
> and a wrong way/do not enter sign on the other. That use case shouldn’t
> affect a router which should be obeying the one way tagging, but for
> micro-mapping there wouldn't be a straight forward way to tag it if we use
> “traffic_sign:direction = forward | backward” or “direction = forward |
> backward” as we can’t tell which sign the direction tag is for.
>

Thanks to Spanish preset I saw the necessity of make also a destination
tagging scheme, because multiple values does not work well with traffic
signs, also recognition systems from people like Mapillary or OSC use to
identify any traffic sign individually. Proposal is done [7], waiting for
people to watch it and make it yours and better, modify it , ammend it, cut
it, crop it,erase it... Precisely I am not the best programmer in the World
(I'm only a kindergarden teacher) . Make useful all this stuff. Make your
own stuff about that. It is only an idea.


>
> Maybe the “stop:direction = forward | backward” and “give_way:direction =
> forward | backward” would allow micro-mapping with multiple signs on one
> pole. They also follow the example set by the documented
> “traffic_signals:direction = forward | backward” tagging:
>
> “highway = stop”
> “stop:direction = forward”
>
> Follows the meme set by:
>
> “highway = traffic_signals"
> “traffic_signals:direction = forward”
>

I think use subkeys (traffic_sign:forward/backward is better than using
other key as traffic_sign:direction=forward
First option give you the country and the code in one pair of key=value
like this:

traffic_sign=maxspeed
maxspeed:forward=50
traffic_sign:forward=ES:R301
side=right

Also opens the opportunity to use traffic_sign with no subkeys to mark the
kind of traffic sign it is (warning,
complementary,regulatory,compulsory...) as a future scheme to unified
traffic sign international system like Mapillary's [8]

Next moths, next years you will hear about Mapillary, about OSC, about
recognition traffic signs system, about open data agreements with some

Re: [Tagging] The direction=* tag

[yo paseopor]

>
> yes, it is important to be able to understand to which way (and traveling
> direction) a sign applies, but nodes do not have a forward or backward
> direction


but the way the node is in yes it does. Node it is not independent. It is
in a way. with a specific direction (you can revert the direction if you
need it, rivers only flow forward-downward). Wiki says "(i.e., draw the way
in the direction that the river flows)."[1]


> , at most they can have an upwards or downwards direction. They also have
> a front side and a back side

, but generally I'd assume the tagging is about the front side, without
> specifying it.
>

In OSM mappers assume something until this thing has become more important
and then need to redefine the way the key is applied with subkeys and other
values.Think about bus stops for example [2] [3]...


> One way to map the direction in an easy way is to map the sign at the side
> of the road.(requires post processing to use the information in a graph
> model).


To avoid this complication I can assume the direction of the way the node
it is in. JOSM style recognise it, Kendzi3D plug-in also does with
direction key or :forward/:backward subkey. [4]


> For a stop sign you could also make a short way for the part from the stop
> line to the actual crossing node, and add stop sign information there
> (either with a relation similar to turn restrictions or with direction
> dependent tags on the _way_)
>

Why you accept a line and not a dot in the same place knowing the
information of the way the node it is [5]? Reading OSM wiki Why is possible
to do with traffic lights [6] (you have to put in a way - wiki says "Thus,
because traffic signals can affect routing decisions, it is important that
they are attached to the ways to which they apply, and not placed beside
the way" [5] , you have a specific subkey) or city_limit [7] but not with
the other traffic signs? Do we have to erase and delete all the traffic
signals (907 256) [8] because they are not correct? If we can do with a
traffic light I am sure we can do with other nodes with no lights there but
so important. If traffic signs were not so important governments did not
put in at the roads.

Mapillary and OSC will give us this information through their plug-ins.
Mapillary has a complete scheme of traffic signs recognition [9]. OSC has
an inside editor [10]. Spanish government open a file with more than
500,000 traffic signs relative to the way...and with a specific permission
to use it with OpenStreetMaps [11]. Are we telling other organizations can
give us this data, with this specific information but OSM can't accept it?
Taginfo says it is possible  [12][13]

Salut i senyals de trànsit (Health and traffic signs )
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver
[2] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
[3] https://wiki.openstreetmap.org/w/index.php?title=Tag:
highway%3Dbus_stop==500=history
[4] https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging#Renders
[5] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#How_to_map
[6] https://wiki.openstreetmap.org/wiki/Tag:highway%
3Dtraffic_signals#Traffic_signals_for_cars
[7] https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit
[8] https://taginfo.openstreetmap.org/tags/?key=highway;
value=traffic_signals
[9] https://www.mapillary.com/developer/api-documentation/#traffic-signs
[10]
http://blog.improve-osm.org/en/2016/11/a-glimpse-into-the-future-of-mapmaking-with-osm-2/
[11]
https://wiki.openstreetmap.org/wiki/File:Resoluci%C3%B3n_se%C3%B1ales_de_tr%C3%A1fico_verticales_RCE.pdf
[12] https://taginfo.openstreetmap.org/keys/traffic_sign%3Aforward
[13] https://taginfo.openstreetmap.org/keys/traffic_sign%3Abackward
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[yo paseopor]

>
>  But at present I am pretty sure that map rendering can’t use
> “direction=forward | backward”. It can (and my rendering does) use the
> compass points and/or degrees values for rotating icons in the point
> symbolizer.


As you can see Kendzi3D plug-in [1] and a style for JOSM [2] do it with
forward/backward keys.Others do too.


Salut i mapes (Health and maps)
yopaseopor

[1] http://imgur.com/RFVKLGZ
[2] http://imgur.com/9tCwVBT

On Fri, Mar 17, 2017 at 11:24 PM, Tod Fitch <t...@fitchdesign.com> wrote:

> If micro mapping, then the stop sign is usually not in the center of the
> traveled way (though I have occasionally seen some there). For micro
> mapping, place a node for the sign where it exists on the side of the road
> and then use the compass direction to indicate how it is facing. As it is
> detached from the highway way forward and backward can have no meaning.
>
> The “highway=stop | give_way” tag on a node on way might be used by map
> rendering, which probably doesn’t care if it has forward or backward
> tagging. I’ve been using Mapnik XML for rendering my maps and I don’t
> recall the ability to detect the direction of a way. Or even if something
> that is being rendered by the point symbolizer can tell if the point is on
> a way. I could be wrong on that. And even if wrong, maybe some rendering
> tool chain will support that in the future. But at present I am pretty sure
> that map rendering can’t use “direction=forward | backward”. It can (and my
> rendering does) use the compass points and/or degrees values for rotating
> icons in the point symbolizer.
>
> I strongly suspect that tagging the stop/give way sign in the middle of
> the way is for the use of routing and route guidance. It might still be of
> use by guidance (though I am not sure the “direction=forward | backward”
> matters much in that case) but what I am hearing is that as
> implemented/specified now it is not useful for routing. Thus my comment
> about noise.
>
> I have been following the tagging suggested on the wiki [1] and checking
> the direction of the way in order to determine the value to put on the
> direction tag is tedious. If it is not being used, I might well forgo the
> direction tag. Fortunately the same wiki page states direction is only
> needed if the signs are closely spaced and it is not obvious which
> intersection/direction the sign is for, so the direction tag in that case
> is almost always optional per my interpretation of the wiki.
>
> Cheers!
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#
> Tagging_minor_road_stops
>
> > On Mar 17, 2017, at 2:47 PM, yo paseopor <yopaseo...@gmail.com> wrote:
> >
> > I don't agree with this: marking the direction of the traffic sign is
> not noise, for a driver can be VITAL, also with the meaning of the traffic
> sign (the main purpose of a traffic sign).
> > Why? Because in a way with two directions we need to know to what
> direction traffic sign it is for. It is not the same a road cross with an
> STOP forward than backward (with micromapping it is not the same one lamp
> than two)
> > Put a key like direction is not the best option, because this
> information can be inside the key itself like traffic_sign:forward or
> traffic_sign:backward.
> > Also it is a good thing to say of what side of the way the traffic sign
> is.
> > In some countries traffic sign of a side is not the same as the other
> side specially in streets in a city.
> > e.g.
> >
> > traffic_sign:forward=ES:R2
> > highway=stop
> > side=right
> >
> > Ok, OSMR do not use that...but other tools uses this information so it
> is important to keep it at the data.
> > In a short-term, people like Mapillary or OSC will give us the
> opportunity (and the data) to map all the traffic signs in a way. Routers
> and navigation apps should be prepared for that. OSM is nowadays capable of
> show all this information. Don't make it disappear.
> >
> > Salut i mapes (Health and maps)
> > yopaseopor
>
>
>
>
> ___
> 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] The direction=* tag

[yo paseopor]

I don't agree with this: marking the direction of the traffic sign is not
noise, for a driver can be VITAL, also with the meaning of the traffic sign
(the main purpose of a traffic sign).
Why? Because in a way with two directions we need to know to what direction
traffic sign it is for. It is not the same a road cross with an STOP
forward than backward (with micromapping it is not the same one lamp than
two)
Put a key like direction is not the best option, because this information
can be inside the key itself like traffic_sign:forward or
traffic_sign:backward.
Also it is a good thing to say of what side of the way the traffic sign is.
In some countries traffic sign of a side is not the same as the other side
specially in streets in a city.
e.g.

traffic_sign:forward=ES:R2
highway=stop
side=right

Ok, OSMR do not use that...but other tools uses this information so it is
important to keep it at the data.
In a short-term, people like Mapillary or OSC will give us the opportunity
(and the data) to map all the traffic signs in a way. Routers and
navigation apps should be prepared for that. OSM is nowadays capable of
show all this information. Don't make it disappear.

Salut i mapes (Health and maps)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] how to care about different seasonal road close?

[yo paseopor]

Idea:

access:conditional=no @ (winter)
access:conditional=no @ (snow)
note=check availability access during first trimester
...

Salut i mapes
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Potential proposal for more detail in old_ref=*?

[yo paseopor]

>
> OHM was in a position where a new hosting arrangement needed to be worked
> out, when a major server crash occurred. so we were literally twisting
> in the wind
> until those issues were resolved. there is no real external support for
> the project
> so we couldn't just go out and rent a server or VM somewhere.
>
> the previous backup arrangements were inadequate, and files were truncated.
> so i think 6-9 months worth of data (maybe 12 months) was lost. i'm in the
> process of assessing what work i need to personally redo, but it doesn't
> look
> all that bad. i am working with Rob Warren on setting up a stronger backup
> plan - but even if we'd had a stronger backup plan, the need to rehost OHM
> would still have been an issue.
>

Ok, good point ...but the result of these unafortunate facts is...lost
information and the worst : lost collaborative work. And it is a reality:
the information about parking would be lost if "unafortunate things"
happened and the information was saved as OHM was.
I think all the information is important, and the best way to keep it
secure, updated and completed is the same database.


>
> there are some advantages to a separate OHM.
>
> a large part of the community thinks OSM should only be about current
> data. if we started seriously doing the things we want to do in OSM, it
> would
> be pretty controversial with a potential risk of an edit war.
>
> OHM can be a playpen for experimentation. i wish to work on a schema for
> relations so that i can describe the movements of troop units in campaigns
> and battles. again, if i started doing this in OSM, i imagine that the
> unhappiness
> would be extensive, and given the other goals of OSM, it's not really a
> good
> place to play.
>
> there is a need for need for tagging extensions for historical mapping.
> this is
> a tricky one. historical mapping needs some temporal language for which
> current OSM tagging is completely inadequate. and given how the tagging
> discussion goes some times, i think the tagging list is the completely
> wrong
> place for such discussions - but if we are trying to keep historic data
> in OSM,
> this is where we would have to have it.
>

OK, with new tags, with new values, with new behaviour, but not outside OSM
data because if there would be another "accident" or unafortunate facts the
information will be inside OSM and other can start another render with
these information.

Think about Wikipedia: is wikipedia divided in kinds of information? All
are at the same system, You have some portals but all the information is at
the same place (for this reason an image in wikipedia is uploaded to
commons).
Historic information is so important...that I think all has to be at the
same place (data). Renders is other thing, you can make whatever you want,
featuring the information you want to.

>
> so from my point of view, keeping the historic data in its own place is
> part of
> trying to keep OSM peace. did we have some problems? yes. are they
> correctable?
> yes. i think some lessons have been learned, but our takeaway is very
> different
> from yours.


I don't know what is your takeaway. I'm a user, I'm a mapper, I'm a man who
loves the history and I want that all my possible future work and the
others won't be lost, and will be accessible...forever. Because that is
about history. So more information, more historical information about refs
would be interesting in OSM with the correct keys and values.

Salut i història (Health and History)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Potential proposal for more detail in old_ref=*?

[yo paseopor]

Humanity is so curious. We make a mistake, we "receive" the consequences
and we don't learn anything, and promote the same mistake.

OHM was a good project...but had a bad choice: data outside OSM. Then the
project had slept...and the information is , nowadays...lost? Well, the
project woke up...but now...where is the "old" information of the same
project?
Compare it with http://histosm.org . Why this map is more complete than the
other? Because all the info is IN OSM.

Ok , it would be one situation, is not the normality...
Think about http://parking.openstreetmap.de ...oh, isn't working? Oh, Did
we lose the information? Well, you can use http://bit.ly/parkingosm because
the data was inside OSM so you can make another render to show the
information.

So I think the right place for information is OSM's database. Then who
wants can use data to make a render of that data.
History is real and specific in a lot of things. So these things that one
day existed or had that property should be in OSM. How...I don't know the
best way, but it is important to make the information accesible to
everyone, and in a easy way without the risk of losing information.

Salut i història (Health and History)
yopaseopor
PD: I support this proposal or similars
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Destination:street

[yo paseopor]

+1 to all.
The preset of traffic signs, the style and the signs for Kendzi3D plug-in
works well with subtags. I can do it with semicolons però some signs will
not work then. How can I make work the others?

Leadership is...doing things.
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] destination:street

[yo paseopor]

I need help. How to tag a roundabout destination traffic sign
https://www.mapillary.com/map/im/6bMYhgICHVBL_H70ZnyPAg ? With
correspondence it is easy (for me), but I don't know how to do it with
multiple values.

Also I hope OSM people will advise strongly Finnish people as they are
using suffixed tags..

And at last but not least Mapbox Streets will need help to process
correctly all the information of OSM without cropping some information.

Cheers (Salut i senyals)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] destination:street

[yo paseopor]

>
> Following this, you could try to find semantic weight for the different
> destinations and discuss/use them. But when there is none (what I
> assume),

Spanish ministery responsible of the roads did not think that

http://www.fomento.es/NR/rdonlyres/FC57DE0A-72BF-408F-
810E-467894BA8E38/110896/1110853.pdf

As you can see order is not random. In Catalonia is the same. How do you
make correspondence with the order. How you "extract" one unic value from
"multiple value" value?

Cheers (Salut i Senyals)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] destination:street

[yo paseopor]

> I would expect that each value for destination only occurs a small
> number of times, especially when there are multiple destinations.  Why
> would a certain combination of destinations occurs more than a handful
> of times ? Hence, you will not find them in the top values on taginfo.
>

So you say each value...(are we talking about multiple values or values
with semicolon?). What are the most used values: unique or multiple? Why
don't we use multiple values more often?


> I also wonder whether any key with "_1" or ":1" is better  for
> beginners than semi colons.
>

Because it follows one tag-one value policy I supose. But I don't know why
in the wiki I read "avoid semicolons"...if it is the best way to manage
multiple values. https://wiki.openstreetmap.org/wiki/Multiple_values
 .Change the wiki to
encourage people to use multiple values.

"

*When (not) to use multiple valuesFor better or worse, a mapper's first
reaction to MV tags should be to avoid them. This is largely because many
data consumers do not handle MV tags well, either because they didn't
expect them or because handling them is complicated. As the OSM data model
doesn't directly support multiple values, they have been tacked-on with
various degrees of akwardness.*"


> Did you do an experiment with a large number of beginners ?
>
No. Did you do it about semicolons? What are the results?

>
> I also wonder which Overpass query is easier to compose, one that has
> to take the semi-colons into account or one that has to query for "_X"
> (or :X). Again a large experiment has never been conducted AFAIK, so
> no-one really knows.
>
Also I did not any scientific experiment. Did you do it with semicolons?
What are the results? It will be interesting to know it.

Cheers (Salut i senyals)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] destination:street

[yo paseopor]

It's true, but OSM wiki, the tool people like me who tries to learn how to
do something uses says that:
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#When_NOT_to_use
.
Change the wiki please if it is not.

Wiki explains

"In general *avoid ';' separated values whenever possible*. Don't use them
in your mapping, and don't propose them on the wiki if there are better
ways of representing things. This is because use of semi-colons as value
separators is contrary to the aim of *keeping it simple* both for data
*contributors* (mappers) and data *users*. For the sake of new contributors
and anyone trying to *use* the data (people building software for
rendering, searching, "find my nearest cafe" mobile apps, etc) we should
minimise use of values with special characters.

It is particularly important to (wherever reasonably possible) avoid ';'
separated values in more important "top-level" tags. That is, tags which
define what an element is." Is not Destination value also so important?


Also there's some software who...does not support semicolon:


"Mapbox Streets

 replaces ; with a spaced em dash ( — ) in any name
=* or name:*
=* tag. For primary keys such
as amenity =* or shop
=*, it considers only the
portion up to the first semicolon and drops the rest."

 I think dropping data is not a good way of working with OSM :(


Taginfo says also there's some destination:x in Germany. For example
http://taginfo.openstreetmap.org/keys/destination%3A1

http://taginfo.openstreetmap.org/keys/destination%3A2

http://taginfo.openstreetmap.org/keys/destination%3A3

and so on...

Also if you see the list in taginfo about destination values you will see
only two in top20 list (well ,one is with comma so also there's some
problems of standarization)  from the most tagged values:
http://taginfo.openstreetmap.org/keys/destination#values

And if you search top100 list there are only 12 values with semicolon , 2
with comma . All these values together are only 1792 tagged values...from
71665 total values.


I think one tag one value it is the best standard for traffic signs also to
make it easier for the begginners and newbies.


Cheers (Salut i senyals)

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

Re: [Tagging] Exit list signs?

[yo paseopor]

But you put these nodes for a way. A road traffic sign without a way is
also meaningless. So I have to mark in which direction will be showed of
the way the traffic sign is owned by. If you put a stop sign in a road with
oneway=no ...will stop the two directions at the same time at the same
place? Meaningless. Also it will be interesting to say in which side of the
road will be the traffic sign if I put it as a node in the way.

Also :forward and :backward scheme are used by ways so we can use the same
tags and propierties talking about the same things (traffic signs informs
you about things will happen in the way you are driving - in the way you
are mapping)

Cheers (salut i senyals)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging