Re: [Tagging] Tagging of State Parks in the US

[Martin Koppenhoefer]

Am Di., 30. Juli 2019 um 00:51 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> -1 to a site relation for an area with a defined outer boundary.
>

> Relation = boundary (and =multipolygon) works fine for defining an area,
> and you can make holes to exclude at my “outparcels” or villages which are
> not part of the official protected area.
>



the difference is that in case a thing which is either outer or inner
member of a boundary or multipolygon changes, you will not know whether the
MP has to change or you have to duplicate the old border for the
multipolygon because it should remain. In a site relation it is clearer
that the modification of a member should likely have immediate effect on
the relation as well.



> Mappers don’t need to add things to relations when the geometry is enough
> to show that node A isi side of area B.
>


different semantics. IMHO there are situations where explicit relation is
preferable over implicit spatial relation.
This said, I am hardly ever using site relations ;-)

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

Re: [Tagging] Tagging of State Parks in the US

[Mateusz Konieczny]

Jul 30, 2019, 9:54 AM by dieterdre...@gmail.com:

>
>
> Am Di., 30. Juli 2019 um 00:51 Uhr schrieb Joseph Eisenberg <> 
> joseph.eisenb...@gmail.com > >:
>
>> -1 to a site relation for an area with a defined outer boundary.
>>
>
>
>>
>> Relation = boundary (and =multipolygon) works fine for defining an area, and 
>> you can make holes to exclude at my “outparcels” or villages which are not 
>> part of the official protected area.
>>
>
>
>
> the difference is that in case a thing which is either outer or inner member 
> of a boundary or multipolygon changes, you will not know whether the MP has 
> to change or you have to duplicate the old border for the multipolygon 
> because it should remain. In a site relation it is clearer that the 
> modification of a member should likely have immediate effect on the relation 
> as well.
>
Can you give more specific exampleof edit where site relation is better?

Things that are areas should be taggedas areas. So multipolygon seems
preferable to me.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Lionel Giard]

All electric charging station that i have ever encounter are in "kW" not in
watt (ex: 3 kW, 50 kW, 120 kW, 175 kW...). To me, it is the same as the
maxspeed tag, we don't put it in m/h but in km/h -> we use the common unit
as everyone use it. Thus we don't use the SI value everywhere and that seem
logical, so here it seems ok to me to leave it in kW.

Le mar. 30 juil. 2019 à 04:40, brad  a écrit :

> I don't have an opinion about kw or w, but if the value is only a number,
> then to prevent confusion and reduce mistagging the key should specify,
> output-kw=22 .
>
>
> On 7/29/19 5:00 AM, dktue wrote:
>
> I'd vote for kW aswell (and a value of "22" then), since we're not always
> using SI and not always base-unit-values (see kilometers per hour).
>
> Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:
>
>
>
> Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue :
>
>> Hello,
>>
>> the OSM-Wiki-page on charging stations [1] defines the tag
>> socket::output=watt
>>
>> wheres the examples contain values like "22 kW".
>>
>> What would the preferred format be? "22000" or "22 kW"? I would like to
>> clearify this on the wiki-page.
>>
>> Personally I would prefer "22000" as it fits with other OSM-values (no
>> units).
>
>
>
> generally people are encouraged to add units for disambiguation reasons
> and to use locally used units and preferably SI units.
>
> For power, no default units are currently specified on this page:
> https://wiki.openstreetmap.org/wiki/Map_Features/Units
>
> And it doesn't even mention horsepower for power, a unit that for many
> people may be more evocative than Watt (everybody can imagine 30 horses,
> but how much are 22 kW?) ;-)
>
> Personally, if we were to set up a default for power units, I would prefer
> kW, because if we'd use Watt we will get very high numbers for MW (e.g.
> needed for power generators). Presuming, we would have the same standard
> unit for all things power, and not different defaults for socket and say
> power stations.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Charging stations: socket::output -- which format for the value?

[Warin]

On 30/07/19 12:38, brad wrote:
I don't have an opinion about kw or w, but if the value is only a 
number, then to prevent confusion and reduce mistagging the key should 
specify, output-kw=22 .


OSM typically places unit after the value.
For examples see 
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Explicit_specifications





On 7/29/19 5:00 AM, dktue wrote:
I'd vote for kW aswell (and a value of "22" then), since we're not 
always using SI and not always base-unit-values (see kilometers per 
hour).


Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:



Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue 
mailto:em...@daniel-korn.de>>:


Hello,

the OSM-Wiki-page on charging stations [1] defines the tag
socket::output=watt

wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would
like to
clearify this on the wiki-page.

Personally I would prefer "22000" as it fits with other
OSM-values (no
units).



generally people are encouraged to add units for disambiguation 
reasons and to use locally used units and preferably SI units.


For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for 
many people may be more evocative than Watt (everybody can imagine 
30 horses, but how much are 22 kW?) ;-)


Personally, if we were to set up a default for power units, I would 
prefer kW, because if we'd use Watt we will get very high numbers 
for MW (e.g. needed for power generators). Presuming, we would have 
the same standard unit for all things power, and not different 
defaults for socket and say power stations.


Cheers,
Martin





___
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?

[Jo]

A bus stop, a place where a bus halts to pick up and drop off passengers is
both real and current. Tying it to a geographic object can be done in
various ways, as we've shown over the past years.

I read the wiki a few times over the past years and then I started looking
for something that works, both for mapping the stops and for adding them to
the route relations, WITHOUT

On Tue, Jul 30, 2019 at 3:39 AM Joseph Eisenberg 
wrote:

> I think you might be referring to this proposal from Zverik last
> summer, which suggests stopping using
> public_transport=stop_position/platform/station, but keeps the
> relations:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport
>
> - =stop_position is not really needed for routing; doubles work for mappers
> =platform is ambiguous; use =bus_stop, highway=platform (if the bus
> stop has a physical platform) railway=platform etc
> = public_transport=station is not specific, use amenity=bus_station,
> railway=station etc).
>
> re: > "It's hard to ascertain precisely why PT was originally created"
>
> According to this comment, it started with imports, and a dispute
> between English mappers and a few Central European mappers (or just
> one?): back in 2010 there were 200,000 highway=bus_stop mapped beside
> the road in England, at the location of the bus stop sign. But there
> was data available in Switzerland that could be imported that had the
> node in the center of the highway, probably for bus operator purposes,
> and a mapper started importing these and changed the wiki to say this
> was better. There was a dispute about this. To resolve it, the
> proposal that was eventually approved created specific tags for
> stop_position (on the highway) which could use access tags like
> "bus=yes" to specify the vehicle and "platform" (for the bus stop),
> and a stop_area relation.
>
> This wasn't sufficient information to render bus stops differently
> than tram / light rail platforms, so the original tagging method
> remained more common up until now.
>
> This hasn't stopped some mappers  from claiming that there is a
> "version 2" of mapping for transit which should replace the "old"
> tags, and editing the wiki pages to put this view at the forefront,
> going so far as to suggest public_transport=platform and =station for
> ferry terminals and taxi stops, where this tagging is very rare.
>
> I've made to various wiki pages to describe the current situation. I'm
> also working on making specific wiki pages for tags like bus=yes (used
> for both access restrictions and to specify the type of public
> transport vehicle at a feature).
>
> Joseph
>
> On 7/30/19, Dave F via Tagging  wrote:
> > Hi
> >
> > This is not a criticism of Joseph.
> >
> > This post confirms what I've been saying for the past year - PT tags add
> > nothing but confusion to OSM, which directly leads to errors.
> >
> > highway=bus_stop is a completely separate tag to any in the PT schema.
> > It was created long before the invention of the PT schema and is the
> > original & the most popular, accurate way to map a bus stop.
> >
> > The PT schema purely duplicates existing, well used, clearly defined
> > tags. It adds no extra detail or information.
> >
> > A platform is a raised physical object compared to the surrounding area
> > to aid vehicle boarding. Popular tags such as railway=platform,
> > tram=platform are used for such entities.
> > Public_transport=platform has been hijacked by PT to falsely represent a
> > bus stop as an imaginary area on a pavement. As defined in OSM's welcome
> > page: "OpenStreetMap is a place for mapping things that are both /real
> > and current/ ".
> >
> > It's hard to ascertain precisely why PT was originally created but it
> > appears to be that the existing tags weren't complete. However instead
> > of adding that missing data, somebody though it would be a great idea to
> > start from the very beginning with a completely new set of tags & try to
> > paper over the gaps. The irony is that, after a lot of discussion over
> > tag names & locations & quickly waning enthusiasm for adding them to the
> > database,  PT is *less* complete than the original data. What a waste of
> > time. It's a mess.
> >
> > Over on the transit forum the PT schema has become so convoluted even
> > those who helped create it are baffled. At least one is advocating its
> > removal.
> >
> > It's time for the PT schema to be redacted.
> >
> > DaveF
> >
> >
> >
> > On 29/07/2019 15:29, Joseph Eisenberg wrote:
> >> I read up on the rather exhausting history of public transport tagging.
> >>
> >> The strange thing is that the approved proposal which introduced
> >> public_transport=* and the current public_transport pages suggest
> >> using bus=yes only for public_transport=stop_position. In contrast,
> >> public_transport=platform doesn't have bus=yes added.
> >>
> >> Does this mean that tagging highway=bus_stop on the same node as
> >> public_transport=platform is the a

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

[Jo]

duplicating information across multiple objects.

I found that what works best is to have nodes on the side of the road to
represent the stops. These nodes have positional information and can carry
all the tags for the details.

If there is an actual elevated platform, it can be represented by a way or
an area, but I don't see any need to move the details tags from the node to
that area. Nor do I see a need to move them to a shelter area, if there is
one, or to a bench or a waste basket that has the typical colours of the
operator. For these ways / areas highway=platform / railway = platform is
enough. Additional tags can be wheelchair yes, tactile_paving=yes and maybe
height.

The platfrorms are just additional features that may be there, or not.

When I still had the idea that one day public_transport=platform /
stop_position would actually supersede highway=bus_stop / railway=tram_stop
/ station and so on, I started adding bus = yes to the pt=platform nodes.
Now I see less point into continuing to do so. The only advantage it has,
is that JOSM will automatcially assign platform roles to such nodes.

Nowadays, I'd say let's indeed drop the whole public_transport schema.
Somewhat radical, but a simple schema is better than a complex one.

Polyglot
___
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?

[Jo]

By the way, I don't think the 'schism' of some people/countries mapping the
stops as nodes of/on the highway and others nodes/ways next to the highway
comes from an import in Switzerland. I think it came from habits in mapping
of railway infrastructure. At one point, we had a single way for multiple
tracks, then we added more detail. Back then it made sense to have station
nodes on those ways. But that is more like a model and it doesn't represent
reality very well, once you want to start adding more detail, like the
separate platforms in the stations.

Polyglot

On Tue, Jul 30, 2019 at 11:41 AM Jo  wrote:

> duplicating information across multiple objects.
>
> I found that what works best is to have nodes on the side of the road to
> represent the stops. These nodes have positional information and can carry
> all the tags for the details.
>
> If there is an actual elevated platform, it can be represented by a way or
> an area, but I don't see any need to move the details tags from the node to
> that area. Nor do I see a need to move them to a shelter area, if there is
> one, or to a bench or a waste basket that has the typical colours of the
> operator. For these ways / areas highway=platform / railway = platform is
> enough. Additional tags can be wheelchair yes, tactile_paving=yes and maybe
> height.
>
> The platfrorms are just additional features that may be there, or not.
>
> When I still had the idea that one day public_transport=platform /
> stop_position would actually supersede highway=bus_stop / railway=tram_stop
> / station and so on, I started adding bus = yes to the pt=platform nodes.
> Now I see less point into continuing to do so. The only advantage it has,
> is that JOSM will automatcially assign platform roles to such nodes.
>
> Nowadays, I'd say let's indeed drop the whole public_transport schema.
> Somewhat radical, but a simple schema is better than a complex one.
>
> Polyglot
>
>
>
___
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?

[Martin Koppenhoefer]

Am Di., 30. Juli 2019 um 11:47 Uhr schrieb Jo :

> By the way, I don't think the 'schism' of some people/countries mapping
> the stops as nodes of/on the highway and others nodes/ways next to the
> highway comes from an import in Switzerland. I think it came from habits in
> mapping of railway infrastructure. At one point, we had a single way for
> multiple tracks, then we added more detail. Back then it made sense to have
> station nodes on those ways.
>


for me it was a new interpretation as well, that the dispute about bus stop
nodes on the highway and nodes aside the highway was based in an import
which "had the node in the center of the highway". It doesn't seem
completely logical, because it would make an import more complicated, not
less, if you had to add the node to a highway. This topic was discussed a
lot, so it may be rather impossible from reading old threads how it came to
the situation, from what I remember there were numerous proponents in both
camps. and it doesn't really matter, because we are a step further and have
more competing alternatives now ;-)

WRT stations, there were a lot of variations out there in the early days,
some people adding the railway=station tag on the main station building or
a node within the building, others as part of a rail, again others near the
centroid of the rails in the station but not part of a rail and some places
even had nodes with railway=station on every rail in the station. This mess
was structured by inventing stop positions, some stations have been mapped
as polygons, and generally by agreeing to not use more than one
railway=station per station.

Back to your main question: was pt intended to replace the legacy tags,
e.g. bus_stop?
Maybe, but it doesn't really matter what it was intended for, almost 10
years ago. Let's document what we have now. The standing of tags derives
mainly from their usage in the map, and much less from voting in the wiki
(because a deprecation is only about the voting outcome, it isn't about
meaning, as is a proposal).
>From my reading, we now have 2 de-facto tags (tag/combination) for
bus_stops, with the legacy tag still (and maybe forever) dominating the
ptv2 usage (for bus stops).

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

[Tagging] Connectivity relations - approved

[Leif Rasmussen]

Hi everyone,
A few weeks ago, the new relation type "connectivity' was approved.  I've
updated the proposal, created a new page
https://wiki.osm.org/Relation:connectivity , and updated relavent wiki
pages to mention connectivity relations.

Connectivity relations are a new relation type of relation that can be used
to specify the lane connectivity between two ways when it's not already
specified by placement=* or lane tags.  They will allow mappers to clarify
the majority of situations where lane connectivity couldn't previously be
specified, and will allow for a whole new level of lane detail to be added
to osm.  They may also make change:lanes more useful in places where it's
added, since data consumers will be able to tell how the lane dividers
connect between ways.

Thanks to everyone that voted or helped improve the proposal!

Leif Rasmussen

***

Sorry about the late email, but I've been traveling through Europe and have
had much less time to work on the proposal than I usually would.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Jérôme Seigneuret]

Please don't use lanes=0. That don't make sense! If there is a road marked
or not there is one lane without oneway. lanes=0 is same as virtual road.
Maritime road isn't marked and there is one lane in database (implicitly).
This is a real word abstraction! Rules are etablished to work with this
database. Oneway=reversible is an other way. This is a condition to pass
because circulation work with conditional traffic_sign. If there is no
condtional that can be lane=1 and if you twice to arrived in this point you
shall apply civility rules.
On area there is no represation of lane. all area is defaut one lane. there
is no direction that is the problem to use it with routing parameters
specificty for foot



Le mer. 3 juil. 2019 à 00:31, Richard  a écrit :

> On Thu, Jun 13, 2019 at 12:59:27PM +1000, Warin wrote:
> > Hi,
> >
> >
> > There are a few uses of lanes=0... I would think these are errors. Even
> if
> > unmarked a road would have at least one lane otherwise it is not really a
> > road.
> >
> >
> > But looking at tag info there are a fair few uses fo it in various
> > locations. So ... what is it used for?
>
> this might also be something like an attempt at oneway=reversible
>
> Richard
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Cordialement,
Jérôme Seigneuret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Martin Koppenhoefer]

Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
jerome.seigneu...@gmail.com>:

> Please don't use lanes=0. That don't make sense!
>


if lanes is about the total amount of marked "2-tracked-vehicle"-lanes (as
it is according to my understanding), then lanes=0 means no marked lanes.

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

Re: [Tagging] lanes = 0

[Volker Schmidt]

Comments on the  Key:lanes 
page

1) Heading "Narrow roads"
The pageit proposes:

width=4
source:width=estimated
This construct is used 5k times acording to TI.
est_widh=x
is used 40k times, and hence should be mentioned at least.

Furthermore the established tag
passing_places=yes
which has its own wiki page and is used 7k times, is missing in the text

2) "Assumptions" table:

The most frequent assumptions are missing, i.e. the case no lane count
and no indication of oneway/two-way.

Also, highway=path should not have an assumed lane count, as it is
normally not suitable for car-width vehicles

3) Examples

Bicycle lanes on cycleways

Under the heading "Description" the page says
"And the following lanes should be *excluded*:
...
Bicycle lanes. Use the tag cycleway
=lane
 for those."

but, under  "Examples" the page shows a bidirectional stand-alone
cycleway with a dashed separator with "lanes=2".,
a situation which I would have tagged highway=cycleway;
oneway:bicycle=no, but wihthout lanes=x tag

4) No line markings

Under the heading "No line markings"
the proposal, which is hidden there, i.e.lane_markings
=no

opens a potential can of worms.
This tag is used 13 times in total. And there are zillions of roads
that have no markings in the real world.








On Tue, 30 Jul 2019 at 12:32, Jérôme Seigneuret 
wrote:

> Please don't use lanes=0. That don't make sense! If there is a road marked
> or not there is one lane without oneway. lanes=0 is same as virtual road.
> Maritime road isn't marked and there is one lane in database (implicitly).
> This is a real word abstraction! Rules are etablished to work with this
> database. Oneway=reversible is an other way. This is a condition to pass
> because circulation work with conditional traffic_sign. If there is no
> condtional that can be lane=1 and if you twice to arrived in this point you
> shall apply civility rules.
> On area there is no represation of lane. all area is defaut one lane.
> there is no direction that is the problem to use it with routing parameters
> specificty for foot
>
>
>
> Le mer. 3 juil. 2019 à 00:31, Richard  a écrit :
>
>> On Thu, Jun 13, 2019 at 12:59:27PM +1000, Warin wrote:
>> > Hi,
>> >
>> >
>> > There are a few uses of lanes=0... I would think these are errors. Even
>> if
>> > unmarked a road would have at least one lane otherwise it is not really
>> a
>> > road.
>> >
>> >
>> > But looking at tag info there are a fair few uses fo it in various
>> > locations. So ... what is it used for?
>>
>> this might also be something like an attempt at oneway=reversible
>>
>> Richard
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
> ___
> 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

[Paul Allen]

On Tue, 30 Jul 2019 at 12:21, Martin Koppenhoefer 
wrote:

if lanes is about the total amount of marked "2-tracked-vehicle"-lanes (as
> it is according to my understanding), then lanes=0 means no marked lanes.
>

That's logical but not particularly useful.  Around here there are a lot of
minor roads.  Some of
them are only wide enough for one vehicle, so are unmarked.  By your logic
that's lanes=0.
Some of them are wide enough for two vehicles, but still unmarked.  By your
logic that's
also lanes=0.  For many of us, it's nice to know if an unmarked road is
only wide enough
for one vehicle (so you might have to back up to a passing place one or
more times) or
wide enough for two vehicles.  The presence or absence of marking can
really only be
used to infer the presence or absence of marking and nothing more.

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

Re: [Tagging] lanes = 0

[Jérôme Seigneuret]

if lanes is about the total amount of marked "2-tracked-vehicle"-lanes (as
it is according to my understanding), then lanes=0 means no marked lanes.

No simply because 2 lanes = opposites 1 forward 1 backward marked or not.
This a routing comportement.

You can have 2 lanes but no mark on road. This is the case in rural France
road. Legaly,  absence of marking is permit and you need fix right position
on road.

https://www.mapillary.com/map/im/bPYmBV9vGQr2CxoSIKGfRw this is 2 lanes
departmental road. In fact in some routing tools if there is no lane there
is no road. A lane is not in relation to road marking.

Same remark as Paul

Le mar. 30 juil. 2019 à 13:33, Paul Allen  a écrit :

> On Tue, 30 Jul 2019 at 12:21, Martin Koppenhoefer 
> wrote:
>
> if lanes is about the total amount of marked "2-tracked-vehicle"-lanes (as
>> it is according to my understanding), then lanes=0 means no marked lanes.
>>
>
> That's logical but not particularly useful.  Around here there are a lot
> of minor roads.  Some of
> them are only wide enough for one vehicle, so are unmarked.  By your logic
> that's lanes=0.
> Some of them are wide enough for two vehicles, but still unmarked.  By
> your logic that's
> also lanes=0.  For many of us, it's nice to know if an unmarked road is
> only wide enough
> for one vehicle (so you might have to back up to a passing place one or
> more times) or
> wide enough for two vehicles.  The presence or absence of marking can
> really only be
> used to infer the presence or absence of marking and nothing more.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Cordialement,
Jérôme Seigneuret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Paul Johnson]

I, for one, consider not including bicycle lanes to be a harmful
shortcoming.  It tells you nothing about where, how many or what turn
restrictions apply to the bicycle lanes, all because bicycle lanes don't
count because reasons.  It also means lane guidance where bicycle lanes
exist will automatically be off by a lane and makes it useless for
cyclists, who need lane information more given relative difficulty changing
lanes.  This is something that desperately needs to change.

On Tue, Jul 30, 2019, 06:27 Volker Schmidt  wrote:

> Comments on the  Key:lanes 
> page
>
> 1) Heading "Narrow roads"
> The pageit proposes:
>
> width=4
> source:width=estimated
> This construct is used 5k times acording to TI.
> est_widh=x
> is used 40k times, and hence should be mentioned at least.
>
> Furthermore the established tag
> passing_places=yes
> which has its own wiki page and is used 7k times, is missing in the text
>
> 2) "Assumptions" table:
>
> The most frequent assumptions are missing, i.e. the case no lane count and no 
> indication of oneway/two-way.
>
> Also, highway=path should not have an assumed lane count, as it is normally 
> not suitable for car-width vehicles
>
> 3) Examples
>
> Bicycle lanes on cycleways
>
> Under the heading "Description" the page says
> "And the following lanes should be *excluded*:
> ...
> Bicycle lanes. Use the tag cycleway 
> =lane 
>  for those."
>
> but, under  "Examples" the page shows a bidirectional stand-alone cycleway 
> with a dashed separator with "lanes=2".,
> a situation which I would have tagged highway=cycleway; oneway:bicycle=no, 
> but wihthout lanes=x tag
>
> 4) No line markings
>
> Under the heading "No line markings"
> the proposal, which is hidden there, i.e.lane_markings 
> =no
>  
> 
>  opens a potential can of worms.
> This tag is used 13 times in total. And there are zillions of roads that have 
> no markings in the real world.
>
>
>
>
>
>
>
>
> On Tue, 30 Jul 2019 at 12:32, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> wrote:
>
>> Please don't use lanes=0. That don't make sense! If there is a road
>> marked or not there is one lane without oneway. lanes=0 is same as virtual
>> road. Maritime road isn't marked and there is one lane in database
>> (implicitly). This is a real word abstraction! Rules are etablished to work
>> with this database. Oneway=reversible is an other way. This is a condition
>> to pass because circulation work with conditional traffic_sign. If there is
>> no condtional that can be lane=1 and if you twice to arrived in this point
>> you shall apply civility rules.
>> On area there is no represation of lane. all area is defaut one lane.
>> there is no direction that is the problem to use it with routing parameters
>> specificty for foot
>>
>>
>>
>> Le mer. 3 juil. 2019 à 00:31, Richard  a écrit :
>>
>>> On Thu, Jun 13, 2019 at 12:59:27PM +1000, Warin wrote:
>>> > Hi,
>>> >
>>> >
>>> > There are a few uses of lanes=0... I would think these are errors.
>>> Even if
>>> > unmarked a road would have at least one lane otherwise it is not
>>> really a
>>> > road.
>>> >
>>> >
>>> > But looking at tag info there are a fair few uses fo it in various
>>> > locations. So ... what is it used for?
>>>
>>> this might also be something like an attempt at oneway=reversible
>>>
>>> Richard
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>> ___
>> 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] lanes = 0

[Mateusz Konieczny]

30 Jul 2019, 15:04 by ba...@ursamundi.org:

> This is something that desperately needs to change. 
>
Maybe, but please do not attempt to redefine "lanes" tag (all_lanes=*?).

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

Re: [Tagging] lanes = 0

[Martin Koppenhoefer]

Am Di., 30. Juli 2019 um 14:05 Uhr schrieb Jérôme Seigneuret <
jerome.seigneu...@gmail.com>:

> if lanes is about the total amount of marked "2-tracked-vehicle"-lanes (as
> it is according to my understanding), then lanes=0 means no marked lanes.
>
> No simply because 2 lanes = opposites 1 forward 1 backward marked or not.
> This a routing comportement.
>
>

maybe you just can't assume in your router that the OSM tag lanes describes
what you expect for lanes?



> You can have 2 lanes but no mark on road. This is the case in rural France
> road. Legaly,  absence of marking is permit and you need fix right position
> on road.
>


Sorry for being ambiguous, I was referring to the wiki definition of the
tag lanes. I agree that there can be lanes without lane markings,
observable lanes. I have to deal with the same situation in Italy.
Basically what I am doing is adding lanes=2 if there are 2 lanes, even if
they are not marked. ;-)
Interestingly, one of those roads I was thinking of, just has gotten (or
renewed) lane markings. It may often be a maintenance question, markings
being renewed in such long intervals, that there are years without markings
but then they might eventually return.

I'm even tempted sometimes to add lanes=1.5, although these cases are
better described with a width.

Cheers,
Martin
___
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?

[Joseph Eisenberg]

I got the information about the origin of the dispute about
highway=bus_stop next to or on the way from this page:

https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Contradictions_in_the_wiki

"In the early days of OSM, the bus stops were mapped beside the street
simply because the poles are beside the street. ... A couple of
software developers adapted this in several imports 
At that point, X came around with the idea to import data from
professional sources ... Transmodel). ... After some imports with the
shifted model, the data was quite messed, because highway=bus_stop got
ambigous for either the pole beside the street or a technical datum
from Transmodel on the street.
... X put a lot of time in writing wiki pages. In the end, the wiki
was less ... in line with the majority of the exisiting data and
software tools. ... To stop worsening the wiki, the 2010 proposal was
organized. Of course, X was involved in the proposal ...
This ended up with a proposal that is even more complex ... ,  simply
because it is intentionally vague. But at least it contains a way to
make the people passionate on On-Street-Stops happy by using their
specific tagging. ..."

I don't know if this is a fair assessment of the history, but it does
suggest that the problem with that imported data from some sources had
the nodes on the highway.

It does sound like everyone agrees on the history that some mappers
wanted to move highway=bus_stop to the highway way, but most wanted it
besides the way. So public_transport=stop_position was created, plus
bus=yes and train=yes to say what sort of vehicle stops there  - but
then there was also a new tag public_transport=platform, so now the
proposal suggested adding 2 points with at least 2 main feature tags,
plus name / operator / ref etc, for each place a bus stops.

And later, people who wanted to deprecate highway=bus_stop and
railway=platform realized that public_transport=platform isn't a full
replacement, so they recommended adding bus=yes or train=yes etc to
each public_transport=platform feature, which leads to 3 tags for each
one.

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.

Joseph

On 7/30/19, Martin Koppenhoefer  wrote:
> Am Di., 30. Juli 2019 um 11:47 Uhr schrieb Jo :
>
>> By the way, I don't think the 'schism' of some people/countries mapping
>> the stops as nodes of/on the highway and others nodes/ways next to the
>> highway comes from an import in Switzerland. I think it came from habits
>> in
>> mapping of railway infrastructure. At one point, we had a single way for
>> multiple tracks, then we added more detail. Back then it made sense to
>> have
>> station nodes on those ways.
>>
>
>
> for me it was a new interpretation as well, that the dispute about bus stop
> nodes on the highway and nodes aside the highway was based in an import
> which "had the node in the center of the highway". It doesn't seem
> completely logical, because it would make an import more complicated, not
> less, if you had to add the node to a highway.

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

Re: [Tagging] lanes = 0

[Jérôme Seigneuret]

@martin this is a problem on what is accepted as a 1 lane because if you
are on a path there is also 1 lane but accepted size is less than what?

highway type need have a base width to appreciate or range values If you
have 1 or more lanes. This case is for normal gabarit what about motorcycle
| car or car | truck.

This is the problem we need defined if there is no marked. width can help
to appreciete that situation but by default there is 1 lane forword and 1
lane backward.
What is the base frame to define lanes in a model? car? truck? motorcycle?
specifics width?


Le mar. 30 juil. 2019 à 15:34, Martin Koppenhoefer 
a écrit :

> Am Di., 30. Juli 2019 um 14:05 Uhr schrieb Jérôme Seigneuret <
> jerome.seigneu...@gmail.com>:
>
>> if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>> (as it is according to my understanding), then lanes=0 means no marked
>> lanes.
>>
>> No simply because 2 lanes = opposites 1 forward 1 backward marked or not.
>> This a routing comportement.
>>
>>
>
> maybe you just can't assume in your router that the OSM tag lanes
> describes what you expect for lanes?
>
>
>
>> You can have 2 lanes but no mark on road. This is the case in rural
>> France road. Legaly,  absence of marking is permit and you need fix right
>> position on road.
>>
>
>
> Sorry for being ambiguous, I was referring to the wiki definition of the
> tag lanes. I agree that there can be lanes without lane markings,
> observable lanes. I have to deal with the same situation in Italy.
> Basically what I am doing is adding lanes=2 if there are 2 lanes, even if
> they are not marked. ;-)
> Interestingly, one of those roads I was thinking of, just has gotten (or
> renewed) lane markings. It may often be a maintenance question, markings
> being renewed in such long intervals, that there are years without markings
> but then they might eventually return.
>
> I'm even tempted sometimes to add lanes=1.5, although these cases are
> better described with a width.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Cordialement,
Jérôme Seigneuret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Paul Johnson]

I don't see it as redefining lanes so much as fixing a bug that never
should have been there in the first place.  Like whoever came up with the
current concept hates cyclists or something.

An analogous situation would be of someone decided ground floors don't
count.  Of course we'd fix that.  This isn't something that could not be
rapidly resolved with a Maproulette, either.  Let's fix this glitch.

On Tue, Jul 30, 2019, 08:12 Mateusz Konieczny 
wrote:

>
>
>
> 30 Jul 2019, 15:04 by ba...@ursamundi.org:
>
> This is something that desperately needs to change.
>
> Maybe, but please do not attempt to redefine "lanes" tag (all_lanes=*?).
>
> ___
> 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

[Tobias Zwick]

This topic again? We had this just a few weeks back and we actually reached to 
a conclusion that lanes=0 should NOT be used to denote that there are no marked 
lanes.

I believe I also documented that conclusion on the wiki, prompting here for 
review.

Tobias 

On July 30, 2019 1:19:32 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
>jerome.seigneu...@gmail.com>:
>
>> Please don't use lanes=0. That don't make sense!
>>
>
>
>if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>(as
>it is according to my understanding), then lanes=0 means no marked
>lanes.
>
>Cheers,
>Martin

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

[Tagging] Someone in OSM hates cyclists? Shurely Shome Mistake! (was: lanes = 0 )

[Andy Townsend]

On 30/07/2019 15:26, Paul Johnson wrote:
I don't see it as redefining lanes so much as fixing a bug that never 
should have been there in the first place.  Like whoever came up with 
the current concept hates cyclists or something.


... or perhaps they came from a country that _really loves cyclists_ and 
all cycling infrastructure there is separated from motor vehicle 
infrastructure :)


Best Regards,

Andy



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

Re: [Tagging] lanes = 0

[Tobias Zwick]

Also, the mention of that lanes key (should) only be used to denote the number 
of MARKED lanes was added in 2017 after a short discussion in the German forum 
about the same topic.

However, in this topic here on the ML, arguments were brought forth that made 
us get to a different conclusion (the one documented in the wiki, see recent 
change history) which is why I consider the decision reached in 2017 (to only 
include marked lanes) obsolete.

Tobias 

On July 30, 2019 1:19:32 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
>jerome.seigneu...@gmail.com>:
>
>> Please don't use lanes=0. That don't make sense!
>>
>
>
>if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>(as
>it is according to my understanding), then lanes=0 means no marked
>lanes.
>
>Cheers,
>Martin

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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[dktue]

OSM typically places unit after the value.
For examples see 
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Explicit_specifications
In Some cases the unit is omitted and a default is assumed. Would this 
default be "kW" in this case?



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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Joseph Eisenberg]

The tag socket::output has been used 5000 times, so I think it's
best to describe existing usage on the wiki. The current usage is to
tag the units, which are almost always kW:

socket:type2:output has been used 3663 times, and the majority (>70%)
are tagged with 22kW, 22 kW, 43kW and 11 kW - they all have kW after
the number, but the presence of a space is variable.
https://taginfo.openstreetmap.org/keys/socket%3Atype2%3Aoutput#values

socket:chademo:output has been used 1 275 times, and 91% are tagged
50kW or 50 kW - there are 12 with 5 and 11 with 50 and no units
(0.1% each).

socket:schuko:output has been used 1 306 times and 80% are tagged
3.6kW, with another 11% tagged 3.7␣kW - all but one common value
included kW as a unit (3700 is used 11 times; 0.1%).

socket:typee:output has been used 128 times, and 84% area tagged "3
kW", none have no units.

socket:type1:output is used 83 times, all values end with "kW"

socket:tesla_supercharger:output is used 72 times, all values end with
"kW" except 2 (one is 12, the other 120).

So 99% have the format "kW" or " kW" with a space.

I think the wiki should state that the output is specified in kW and
the unit is specified, to match current usage.

Joseph

On 7/30/19, dktue  wrote:
>
>> OSM typically places unit after the value.
>> For examples see
>> https://wiki.openstreetmap.org/wiki/Map_Features/Units#Explicit_specifications
> In Some cases the unit is omitted and a default is assumed. Would this
> default be "kW" in this case?
>
>
> ___
> 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] Charging stations: socket::output -- which format for the value?

[brad]

On 7/30/19 2:59 AM, Warin wrote:

On 30/07/19 12:38, brad wrote:
I don't have an opinion about kw or w, but if the value is only a 
number, then to prevent confusion and reduce mistagging the key 
should specify, output-kw=22 .


OSM typically places unit after the value.
For examples see 
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Explicit_specifications

+1  I think this is best.







On 7/29/19 5:00 AM, dktue wrote:
I'd vote for kW aswell (and a value of "22" then), since we're not 
always using SI and not always base-unit-values (see kilometers per 
hour).


Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:



Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue 
mailto:em...@daniel-korn.de>>:


Hello,

the OSM-Wiki-page on charging stations [1] defines the tag
socket::output=watt

wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would
like to
clearify this on the wiki-page.

Personally I would prefer "22000" as it fits with other
OSM-values (no
units).



generally people are encouraged to add units for disambiguation 
reasons and to use locally used units and preferably SI units.


For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for 
many people may be more evocative than Watt (everybody can imagine 
30 horses, but how much are 22 kW?) ;-)


Personally, if we were to set up a default for power units, I would 
prefer kW, because if we'd use Watt we will get very high numbers 
for MW (e.g. needed for power generators). Presuming, we would have 
the same standard unit for all things power, and not different 
defaults for socket and say power stations.


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] lanes = 0

[Mateusz Konieczny]

30 Jul 2019, 16:26 by ba...@ursamundi.org:

> I don't see it as redefining lanes 
>
It is not changing that it would redefine
meaning of this tag.

So it would require survey of all 
places tagged with lanes tag so
it is not going to happen.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Paul Johnson]

Not really, no, you could easily Maproulette this for items tagged
cycleway=lane.  Besides, just because something is hard to fix doesn't mean
it shouldn't be fixed.

On Tue, Jul 30, 2019, 13:24 Mateusz Konieczny 
wrote:

>
>
> 30 Jul 2019, 16:26 by ba...@ursamundi.org:
>
> I don't see it as redefining lanes
>
> It is not changing that it would redefine
> meaning of this tag.
>
> So it would require survey of all
> places tagged with lanes tag so
> it is not going to happen.
> ___
> 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

[Paul Allen]

On Tue, 30 Jul 2019 at 19:46, Paul Johnson  wrote:

 Besides, just because something is hard to fix doesn't mean it shouldn't
> be fixed.
>

Yes, but modal verbs are tricky. :)  I agree it SHOULD be fixed, but that
doesn't mean that it
CAN be fixed.  And even if it CAN be fixed, that doesn't mean it WILL be
fixed.

Redefining lanes means we also need to re-examine all of them.  Some will
be obvious
from aerial imagery, some will need feet on the ground. And then we need to
agree on
an additional tag (which could just be a note, but with formal syntax) to
show that the
lanes tag has been used in a way that conforms to the new definition, or
mappers are going
to waste time checking the same roads many times.

Better would be to come up with a new tag for it.  That way you know if the
road has an old
lanes=n tag or a new whatever=n tag and don't have to re-examine if it has
the new tag.
However, if standard carto makes any rendering decisions based upon lanes=n
(I don't
know if it does or not) then the carto guys may completely ignore our nice,
new
whatever=n tag because they seem to have a strict rule about "no aliases"
and they might
consider whatever=n to be an alias of lanes=n.

Oh, and you'd have to get editors and routers to support the new whatever=n
tag, although
that probably isn't an insurmountable problem.

Don't hold your breath for a change.

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

Re: [Tagging] lanes = 0

[Paul Johnson]

Maybe quit fighting against a good idea just because it's hard?  And since
when have we ever been against incremental improvement over none at all
except for this specific thing?

On Tue, Jul 30, 2019, 14:04 Paul Allen  wrote:

> On Tue, 30 Jul 2019 at 19:46, Paul Johnson  wrote:
>
>  Besides, just because something is hard to fix doesn't mean it shouldn't
>> be fixed.
>>
>
> Yes, but modal verbs are tricky. :)  I agree it SHOULD be fixed, but that
> doesn't mean that it
> CAN be fixed.  And even if it CAN be fixed, that doesn't mean it WILL be
> fixed.
>
> Redefining lanes means we also need to re-examine all of them.  Some will
> be obvious
> from aerial imagery, some will need feet on the ground. And then we need
> to agree on
> an additional tag (which could just be a note, but with formal syntax) to
> show that the
> lanes tag has been used in a way that conforms to the new definition, or
> mappers are going
> to waste time checking the same roads many times.
>
> Better would be to come up with a new tag for it.  That way you know if
> the road has an old
> lanes=n tag or a new whatever=n tag and don't have to re-examine if it has
> the new tag.
> However, if standard carto makes any rendering decisions based upon
> lanes=n (I don't
> know if it does or not) then the carto guys may completely ignore our
> nice, new
> whatever=n tag because they seem to have a strict rule about "no aliases"
> and they might
> consider whatever=n to be an alias of lanes=n.
>
> Oh, and you'd have to get editors and routers to support the new
> whatever=n tag, although
> that probably isn't an insurmountable problem.
>
> Don't hold your breath for a change.
>
> --
> 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] lanes = 0

[Paul Allen]

On Tue, 30 Jul 2019 at 20:27, Paul Johnson  wrote:

Maybe quit fighting against a good idea just because it's hard?
>

I'm not fighting against a good idea.  I agree that the current situation
is broken.  But I've
been on this list long enough to understand that there are problems in
changing the
status quo.

OSM is anarchic in nature.  In many ways, that is a good thing.  But it's
not conducive to
joined-up thinking.

And since when have we ever been against incremental improvement over none
> at all except for this specific thing?
>

I'm not against fixing the lanes problem.  I've supported similar changes
in the past.
And seen what happened to them.  The best I hope for these days is that
somebody will
figure out a way of getting a good idea implemented instead of running up
against the
same old obstacles.

Redefining lanes has no chance.  A replacement tag might have.  But you go
ahead and
try to redefine lanes, if you wish.  Good luck with that.

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

Re: [Tagging] lanes = 0

[Mateusz Konieczny]

30 Jul 2019, 21:03 by pla16...@gmail.com:

> However, if standard carto makes any rendering decisions based upon lanes=n
>
It is not used at all.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Paul Allen]

On Tue, 30 Jul 2019 at 23:33, Mateusz Konieczny 
wrote:

> 30 Jul 2019, 21:03 by pla16...@gmail.com:
>
> However, if standard carto makes any rendering decisions based upon lanes=n
>
> It is not used at all.
>

That's one potential problem disposed of.

How about routers?  Although I'd expect them to be able to cope with a new
tag
lanes_whether_marked_or_unmarked=n with less difficulty than changes to
standard carto.

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

Re: [Tagging] lanes = 0

[Paul Johnson]

On Tue, Jul 30, 2019 at 5:50 PM Paul Allen  wrote:

> On Tue, 30 Jul 2019 at 23:33, Mateusz Konieczny 
> wrote:
>
>> 30 Jul 2019, 21:03 by pla16...@gmail.com:
>>
>> However, if standard carto makes any rendering decisions based upon
>> lanes=n
>>
>> It is not used at all.
>>
>
> That's one potential problem disposed of.
>
> How about routers?  Although I'd expect them to be able to cope with a new
> tag
> lanes_whether_marked_or_unmarked=n with less difficulty than changes to
> standard carto.
>

 Osmand's working on access by lane already, and JOSM already handles this,
so counting bicycle lanes won't cause issues there.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Joseph Eisenberg]

Based on current practice, it seems that most people are ok with
adding new values to certain keys that already have a long list of
documented values in map features, as long as the tag is frequently
used and well-documented?

The relevant keys appear to be:

craft=
building=
office=
shop=
sport=

Are there any others that don't need a proposal to add a new value to
Map Features?

I'd like to mention this at the end of the Proposal Process page, as
the final lines of "Non-proposed features" like this:

"Generally, new [keys] should always be discussed before being added
to [Map features], and new tags in major keys like "highway=" should
be formally proposed. A proposal is also recommended for any new tag
which replaces an existing tag.

"However, if a tag is commonly used and clearly documented in the
wiki, and does not replace an existing tag, new values for certain
keys with can be added without a proposal to these keys: craft=,
building=, office=, shop= and sport=. Please discuss the new tag in a
public forum before adding to Map Features."

Does everyone agree with this wording?

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