Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[Marc Gemis]

> I already have trouble imagining that there are mobile apps so badly
> made that it asks the user to transcribe the parking ref instead
> of finding it by geolocation

They do geolocation and suggest the ref. However, in some cases they
suggest the ref of a neighbouring zone. That zone can have a different
fee.
Hence the need to verify and correct the code manually.

Furthermore some apps (4411.be) also allow you to pay in underground
parkings where geolocation will not work.


m.

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

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Jo]

It is still possible to tag a highway with 1 single railway track on it
highway=* + railway=tram/train. But this proposal is for the case where the
highway has 2 railiway tracks which are already mapped separately because
the way railways curve is different from how how highways behave at
intersections.

This tag is only a hint for routers, so cyclists can try to avoid such
ways. What it really means is, there are railway tracks, BUT they are
already mapped on  separate OSM object that runs mostly parallel to this
highway.

Polyglot

El jue., 22 nov. 2018 a las 6:55, Yves () escribió:

> Sergio,
> This is not an issue, anyway some will argue that the highway is a highway
> AND a railway too, so they would be happy too.
> Yves ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Yves]

Sergio,
This is not an issue, anyway some will argue that the highway is a highway AND 
a railway too, so they would be happy too.
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Mateusz Konieczny]

It will not be a trouble. After OSM wiki page about specific value is created 
it is easy to find
(it is true for any documented value and it is not changing whatever given 
proposalis a good idea or not).
21. Nov 2018 23:11 by yve...@mailbox.org :


> I like the railway key: if it's a railway, don't make it an obscure tag that 
> no one can find in the wiki.
>
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Sergio Manzi]

Hello Yves,

maybe you're missing that according to the proposal we will have a first 
feature tagged as *both */highway=*/ *and */railway=separately_mapped/, *plus 
*a second overlapping/parallel feature tagged as/railway=*/

Utterly confusing, IMHO: the embedded rail is an attribute of the highway 
surface and so should be tagged, not as a hint to the renderer.

Cheers,

Sergio


On 2018-11-21 23:11, Yves wrote:
> Here is another example :
> https://www.openstreetmap.org/#map=18/46.72145/6.53707
>
> I like the railway key: if it's a railway, don't make it an obscure tag that 
> no one can find in the wiki.
> Yves
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Yves]

Here is another example :
https://www.openstreetmap.org/#map=18/46.72145/6.53707

I like the railway key: if it's a railway, don't make it an obscure tag that no 
one can find in the wiki.
Yves 

Le 21 novembre 2018 22:47:34 GMT+01:00, Graeme Fitzpatrick 
 a écrit :
>On Wed, 21 Nov 2018 at 19:04, Nikulainen, Jukka K <
>jukka.nikulai...@helsinki.fi> wrote:
>
>>
>> It is true that that would be more precise, but are there in fact any
>> examples of this? I mean a railway that runs parallel to _and_ on a
>road?
>> Usually highways do cross railways, but this is not a problem, since
>one
>> approaches the rails (and the grooves) tangentially and they do not
>pose a
>> great danger.
>>
>
>Yep, here's one:
>
>https://www.openstreetmap.org/#map=17/-23.38348/150.51344
>
>https://www.google.com/maps/@-23.3849743,150.5134603,3a,75y,1.08h,91.28t/data=!3m6!1e1!3m4!1symXKGQrpX9_K7nUyg9FbMg!2e0!7i13312!8i6656
>
>& that is the main North-South rail line!
>
>
>Thanks
>
>Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Graeme Fitzpatrick]

On Wed, 21 Nov 2018 at 19:04, Nikulainen, Jukka K <
jukka.nikulai...@helsinki.fi> wrote:

>
> It is true that that would be more precise, but are there in fact any
> examples of this? I mean a railway that runs parallel to _and_ on a road?
> Usually highways do cross railways, but this is not a problem, since one
> approaches the rails (and the grooves) tangentially and they do not pose a
> great danger.
>

Yep, here's one:

https://www.openstreetmap.org/#map=17/-23.38348/150.51344

https://www.google.com/maps/@-23.3849743,150.5134603,3a,75y,1.08h,91.28t/data=!3m6!1e1!3m4!1symXKGQrpX9_K7nUyg9FbMg!2e0!7i13312!8i6656

& that is the main North-South rail line!


Thanks

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

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Rainer]

Yes, I agree, railway tracks in a highway is more seldom than tram 
rails. In former times that existed oftener and I assume that in eastern 
Europe more of such cases still exist, also in Asia.

Some examples that I know:
Many streets in Forst (Lausitz) had such railways, some still exist 
(unused):

https://www.openstreetmap.org/#map=18/51.74037/14.63721
http://www.buntbahn.de/fotos/data/7191/158Forst_-_Stadt_-_Ausweiche_Alexanderstr_02.JPG
Still in use:
https://www.openstreetmap.org/query?lat=52.84362=8.94250#map=17/52.84359/8.94328=N
Combined railway/highway bridge between France and Germany (currently 
not used, but talked about reactivation):

https://www.openstreetmap.org/way/315375218#map=16/48.8472/8.1177=N
Lindaunisbrücke (another combined bridge - in use):
https://de.wikipedia.org/wiki/Lindaunisbrücke#/media/File:Boren_Lindaunis_Eisenbahnbruecke.jpg

Bye,
Rainer

Am 21.11.18 um 13:00 schrieb tagging-requ...@openstreetmap.org:

Re: Feature Proposal - Voting - (Tramtrack_on_highway)



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

Re: [Tagging] Physical vs legal access tagging on barriers

[Jérôme Seigneuret]

that is simple with a reallity ;-)

you can have barrier=lift_gate+access=private+foot=no (or
foot=use_sidepath)

in lot of cases there is an other acces specificelly fo foot (and bicycle)
because lift_gate work with weight detection and when the barrier was
lowered it can shoot your head!

logically you use a side passage with other barrier or not...





Le mer. 21 nov. 2018 à 18:25, OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> a écrit :

> The wiki says the access tag represents the *legal* access condition, so
> not related to the physical aspects of the feature.
>
> Reading the wiki a bit, I see the access on gates exists to override the
> default characteristics inherent to the barrier type: “Each barrier has
> its own accessibility defaults. Use tag access=* to override them.” [1]
>
> So, lift_gate with access=foot is probably redundant, because the
> lift_gates I can think of do not have features that effectively prevent
> foot passage (they might deter or have signs, but the physical construction
> of the gate itself is not preventing foot passage).
>
> I don’t know where the default accessibility condition per gate type can
> be consulted, however.
>
> [1] https://wiki.openstreetmap.org/wiki/Barriers
> ___
> 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] Physical vs legal access tagging on barriers

[OSMDoudou]

The wiki says the access tag represents the *legal* access condition, so not 
related to the physical aspects of the feature.

Reading the wiki a bit, I see the access on gates exists to override the 
default characteristics inherent to the barrier type: “Each barrier has its own 
accessibility defaults. Use tag access=* to override them.” [1]

So, lift_gate with access=foot is probably redundant, because the lift_gates I 
can think of do not have features that effectively prevent foot passage (they 
might deter or have signs, but the physical construction of the gate itself is 
not preventing foot passage).

I don’t know where the default accessibility condition per gate type can be 
consulted, however.

[1] https://wiki.openstreetmap.org/wiki/Barriers___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[Paul Allen]

On Wed, Nov 21, 2018 at 4:04 PM marc marc  wrote:

I already have trouble imagining that there are mobile apps so badly
> made that it asks the user to transcribe the parking ref instead
> of finding it by geolocation
>

Then you have not tried as many badly-designed apps as I have.  None of
them were for parking,
but they were all badly designed.  Anyway, a parking app might offer
alternatives to geolocation for
those with stupid phones rather than smart phones.  And for people who
prefer not to face a parking
fine because bad weather meant they couldn't get a GPS lock.

but for those apps, it seems more convenient to me to use
> payment:=
>

That's one possibility.  It is better than ref=12345 and  you have to guess
whether or not that
ref is an SMS payment number, and whether you send an SMS to 12345 or you
send an SMS to
some other number quoting 12345 in the body.


> > ALL of them might be possible
>
> might ? of course ! but does this situation exist or it's it's purely
> fictional ?
>

All of them might be possible because older technology hangs around.  And
some people don't
adopt new technology.  So it may be possible to pay by SMS because that was
set up years ago
and some people don't have phones capable of anything better.  It may be
possible to pay by app,
but some people may not have the app installed and the signal may be too
weak to install it at that
moment.  It may be possible to pay by NFC, but not everyone has a phone
with that capability.  So
all of those alternatives might be possible at the same car park, along
with machines accepting coins
and debit cards.  Coin payments are likely to go away in the future because
they're a temptation to
break into the vending machines but other payment methods will hang around
a lot longer.

of course we can put several ref: ref: on all parking
> of the planet just in case another entity would designate this parking
> lot with another ref... but if the majority of car parks have only one
> reference, their operator's ref, it seems to me to bring no advantage to
> use several ref:*=* over using ref=* without suffix and add suffixes
> only when necessary.
>

I wasn't suggesting tagging every possible option in advance.  Just
anticipating what might happen
in the future by not overloading the already-overloaded ref=*.  Operators
do have unique references
for car parks.  Several payment options may be available.  Using ref=* on a
first-come, first-served
basis is not helpful ("Of course it means the SMS number because I mapped
that first and added
NFC later.")  If we're going to have ref:*=* for other payment methods it
makes no sense to
appropriate ref=* for just one of those methods, especially when ref=* is
better reserved for the
operator's unique reference for the car park (if there is one).  We
shouldn't have to GUESS what
a bare ref=* means for any particular car park, which is what you appear to
be suggesting.

In this case, the suffix should be the same between the payment key
> and the ref key like payment:sms=yes with ref:sms=*
> not payment:sms=yes with ref:payement-by-sms=*
>

That seems sensible.  What I wouldn't want to see is "ref=12345 means the
pay-by-sms reference
UNLESS it means the operator's unique reference and you'll have to guess
which it is."  Nor do I
want to see "ref=12345 is the pay-by-sms reference but ref:nfc is the
pay-by-nfc reference because
we didn't anticipate future needs and anyway a foolish consistency is the
hobgoblin of little minds."

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

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[marc marc]

Le 21. 11. 18 à 16:33, Paul Allen a écrit :
> On Wed, Nov 21, 2018 at 3:21 PM marc marc wrote:
> 
> Le 21. 11. 18 à 13:39, Michael Brandtner a écrit :
>  > it's a ref specific to this parking lot to be entered into an app
> or sms.
> 
> payment:sms=yes or payment:sms=
> payment:=yes
> 
>  > ref:payment:app=12345
>  > ref:payment:sms=12345
> 
> ref=12345 look enough, isn't it ?
> 
> No.  

I already have trouble imagining that there are mobile apps so badly 
made that it asks the user to transcribe the parking ref instead
of finding it by geolocation
but for those apps, it seems more convenient to me to use
payment:=


> ALL of them might be possible

might ? of course ! but does this situation exist or it's it's purely 
fictional ?
of course we can put several ref: ref: on all parking 
of the planet just in case another entity would designate this parking 
lot with another ref... but if the majority of car parks have only one 
reference, their operator's ref, it seems to me to bring no advantage to 
use several ref:*=* over using ref=* without suffix and add suffixes 
only when necessary.
In this case, the suffix should be the same between the payment key
and the ref key like payment:sms=yes with ref:sms=*
not payment:sms=yes with ref:payement-by-sms=*

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

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[Paul Allen]

On Wed, Nov 21, 2018 at 3:21 PM marc marc  wrote:

> Le 21. 11. 18 à 13:39, Michael Brandtner a écrit :
> > it's a ref specific to this parking lot to be entered into an app or sms.
>
> payment:sms=yes or payment:sms=
> payment:=yes
>
> > ref:payment:app=12345
> > ref:payment:sms=12345
>
> ref=12345 look enough, isn't it ?
>

No.  Not if it's pay-by-app instead of pay-by-sms.  Not if it's pay-by-bonk
(NFC).  Etc.  Any of those might
be possible.  More to the point, ALL of them might be possible, each
requiring a different code.

No.  Not if ref has other possible meanings.  Such as the operator's
reference to that particular
car park (or whatever) but NOT the number to put in an SMS.  Etc.

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

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[marc marc]

Le 21. 11. 18 à 13:39, Michael Brandtner a écrit :
> it's a ref specific to this parking lot to be entered into an app or sms.

payment:sms=yes or payment:sms=
payment:=yes

> ref:payment:app=12345
> ref:payment:sms=12345

ref=12345 look enough, isn't it ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Physical vs legal access tagging on barriers

[Mateusz Konieczny]

There may be a sitation where
1) there is a barrier (like barrier=lift_gate)2) it is not blocking foot 
traffic3) but pedestrians are not allowed to pass
I think that optimal tagging in this case would be
barrier=lift_gate + foot=yes on barrierhighway=* + foot=no on way with barrier 
node
See for example https://commons.wikimedia.org/wiki/File:Slan%C3%BD_(0486).jpg 

In other words: ways have access tag defined by legal situation, barriers have 
tagsdefined by physical obstacles.
I think it would be the best way to tag and I used it so far (for example many 
barriers 
have no legal blockade for cyclists but are made in way that makes dismounting 
and 
crossing on foot necessary)/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] RfC: tagging whatever power line is insulated as an attribute

[Mateusz Konieczny]

I created https://wiki.openstreetmap.org/wiki/Proposed_features/insulated 
 to 
with intention of allowing mappers not interested in the extreme detail of 
power networks
to allow ignoring this detail in case of isolation of power lines.

Feedback is highly appreciated. I have little experience with power tagging in 
OSM. 
This proposal is primarily based on tagging scheme issues that I discovered 
during 
an attempt to handle 
https://github.com/gravitystorm/openstreetmap-carto/issues/3460 


PS This is second RfC, first one allowed me to fix a major naming error but 
some people
maybe skipped thread due to a misleading name.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[Michael Brandtner]

 Philip Barnes  schrieb am 23:29 Dienstag, 20.November 
2018:

 > I am not 100% sure that mobile payment is the correct term, that to me 
 > implies using your phone for contactless payment.
But wouldn't that be payment:contactless? 

> The English term used in these cases is Pay by Phone.
So your suggestion is payment:pay_by_phone and ref:pay_by_phone?   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

[Michael Brandtner]

Am Dienstag, 20. November 2018, 23:32:40 MEZ hat marc marc 
 Folgendes geschrieben:

> it's a ref specific to this parking to be entered in an app ?

> or a 
> https://wiki.openstreetmap.org/wiki/Key:payment#Payment_via_phone ?


Yes, it's a ref specific to this parking lot to be entered into an app or sms. 

But I just realized that I'm also not sure how to enter this payment method. 
payment:sms is documented in the wiki but how should we enter payment via an 
app? payment:mobile_payment? payment:app?

And maybe the ref should then be more like

ref:payment:app=12345
ref:payment:sms=12345

Michael

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

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Jo]

The whole issue is that due to tram rails bending differently than road
ways, the tram rails are mapped on their own OSM ways. This gives a nicely
detailed rendering, a better description of reality, but now the
information that for the straight parts the rails are embedded into the
highway is missing. It's just a model, not a highly detailed architectural
plan.

I would also be in favour of not using railway=*,

embedded_rails conveys more information without going into conflict with
the railway ways. We don't want to render them 3 times if there are 2
tracks.

Polyglot

El mié., 21 nov. 2018 a las 10:04, Nikulainen, Jukka K (<
jukka.nikulai...@helsinki.fi>) escribió:

> Sorry, I forgot to comment on this earlier
>
> >embedded_rails=yes or even more precise
> >embedded_rails=tram | embedded_rails=railway.
> >The latter is even worse for bicycles, because the rail grooves are
> >broader.
>
> It is true that that would be more precise, but are there in fact any
> examples of this? I mean a railway that runs parallel to _and_ on a road?
> Usually highways do cross railways, but this is not a problem, since one
> approaches the rails (and the grooves) tangentially and they do not pose a
> great danger.
>
> But you are of course correct that this tag would allow for more specific
> tagging, if this is something that is needed.
>
> Sincerely,
> Jukka (Tolstoi21)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Michael Brandtner]

 I think I agree with Rainer: You propose to add a  "railway=" tag to a way 
that already has a "highway=" tag. So then why not just add "railway=tram" and 
delete the separate way? If this is not wanted (e.g. for rendering reasons) 
then I think we should use another tag instead of "railway=".
Am Mittwoch, 21. November 2018, 09:55:54 MEZ hat Nikulainen, Jukka K 
 Folgendes geschrieben:  
 
 Hello, and thank you all again for your comments!

>>Le 20 novembre 2018 22:02:01 GMT+01:00, Rainer  a écrit :
>>Sorry that I enter the discussion late.
>>First, is my understanding correct that you want to add a tag on a
>>highway that has embedded tram rails? So e.g. a bicycle router might
>>avoid such highways?
>>Generally a good idea, I think. However to use
>>railway=separately_mapped
>>is not so good in my opinion, because then the way has highway=* and
>>railway=*. What should a renderer do, render a highway or render a
>>railway?
>>As the rails in the highway are a feature that describes the shape of
>>the highway similar to surface=*, I would rather use a new tag
>>embedded_rails=yes or even more precise
>>embedded_rails=tram | embedded_rails=railway.
>>The latter is even worse for bicycles, because the rail grooves are
>>broader.
>>
>>Best regards,

That's a good point, although I don't know whether the renderer is the main 
issue. There are lots of other tags that the renderer (rightly) ignores.
It might be construed as strange that a highway= has a rail= -tag and that the 
railway is, specifically, not rendered. But I'm not sure whether the semantics 
of my tag proposal are troublesome. What do other people think about this? The 
point of my tag-proposal after all is that there _is_, in fact, a pair of rails 
_on_ the highway.

>Hmm, if someone want to do something with the railway key, they will look at 
>the value.
>It's a good proposal.
>Yves

Sorry, I'm not quite sure whether this a comment for or against the rail= -tag, 
but thank you for the input!

Since I initiated the voting process already, could you all please cast a vote 
on the poroposal page ( 
https://wiki.openstreetmap.org/wiki/Proposed_features/Tramtrack_on_highway ) 
and add comments so that in two weeks time I could possibly mend the proposal 
according to the vote and possibly have a new vote on the winning 
tag-identification. Yves, this would also make clear whether you are against or 
for the current proposal.

Thank you all very much, and please vote and add comments on the proposal page!

Sincerely,
Jukka (Tolstoi21)

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

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Nikulainen, Jukka K]

Sorry, I forgot to comment on this earlier

>embedded_rails=yes or even more precise
>embedded_rails=tram | embedded_rails=railway.
>The latter is even worse for bicycles, because the rail grooves are
>broader.

It is true that that would be more precise, but are there in fact any examples 
of this? I mean a railway that runs parallel to _and_ on a road? Usually 
highways do cross railways, but this is not a problem, since one approaches the 
rails (and the grooves) tangentially and they do not pose a great danger.

But you are of course correct that this tag would allow for more specific 
tagging, if this is something that is needed.

Sincerely,
Jukka (Tolstoi21)

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

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

[Nikulainen, Jukka K]

Hello, and thank you all again for your comments!

>>Le 20 novembre 2018 22:02:01 GMT+01:00, Rainer  a écrit :
>>Sorry that I enter the discussion late.
>>First, is my understanding correct that you want to add a tag on a
>>highway that has embedded tram rails? So e.g. a bicycle router might
>>avoid such highways?
>>Generally a good idea, I think. However to use
>>railway=separately_mapped
>>is not so good in my opinion, because then the way has highway=* and
>>railway=*. What should a renderer do, render a highway or render a
>>railway?
>>As the rails in the highway are a feature that describes the shape of
>>the highway similar to surface=*, I would rather use a new tag
>>embedded_rails=yes or even more precise
>>embedded_rails=tram | embedded_rails=railway.
>>The latter is even worse for bicycles, because the rail grooves are
>>broader.
>>
>>Best regards,

That's a good point, although I don't know whether the renderer is the main 
issue. There are lots of other tags that the renderer (rightly) ignores.
It might be construed as strange that a highway= has a rail= -tag and that the 
railway is, specifically, not rendered. But I'm not sure whether the semantics 
of my tag proposal are troublesome. What do other people think about this? The 
point of my tag-proposal after all is that there _is_, in fact, a pair of rails 
_on_ the highway.

>Hmm, if someone want to do something with the railway key, they will look at 
>the value.
>It's a good proposal.
>Yves

Sorry, I'm not quite sure whether this a comment for or against the rail= -tag, 
but thank you for the input!

Since I initiated the voting process already, could you all please cast a vote 
on the poroposal page ( 
https://wiki.openstreetmap.org/wiki/Proposed_features/Tramtrack_on_highway ) 
and add comments so that in two weeks time I could possibly mend the proposal 
according to the vote and possibly have a new vote on the winning 
tag-identification. Yves, this would also make clear whether you are against or 
for the current proposal.

Thank you all very much, and please vote and add comments on the proposal page!

Sincerely,
Jukka (Tolstoi21)

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