Hi!
Am 09.04.2013 um 17:22 schrieb François Lacombe
:
> In my mind, define a role in a relation is mandatory but you say it's
> definitely not right.
Roles can make sense. For example ways in a route relation may have the role
forward or backward, if this specific way is only used in one dire
Hi!
Am 08.04.2013 um 00:03 schrieb François Lacombe
:
> Hi again :)
>
>
> 2013/4/7 Martin Vonwald
>> Hi!
>>
>> Actually how could that happen?
>
> I don't have example, I was only guessing.
>
> Assuming 2 different power plants with output generators in each (and links
> for power exchang
Hi!
Am 08.04.2013 um 04:44 schrieb John Baker :
> As you are talking about rendering of the roads. I am actually looking at
> this for the new cartoCSS mapnik style for osm.org.
Have you had a look at the style "Lane and road attributes" for JOSM? I know
it's not a cartoCSS style but it demons
Hi!
Am 29.03.2013 um 00:15 schrieb Paul Johnson :
> I tend to go with access=no, hov=*, and possibly motorcycle=yes or
> psv=designated, since I've yet to find an HOV road that allows you to walk,
> ski, ride an animal or a bicycle, etc. on it; it literally only allows the
> modes specified.
Hi,
Are there any arguments against using amenity=shelter +
shelter_type=field_shelter for field shelters (see [1]) for horses?
From the wiki:
The amenity=shelter tag marks all sorts of small shelters to protect against
bad weather conditions.
Sounds good to me.
Regards,
Martin
[1] http://ww
Am 01.02.2013 um 15:33 schrieb Peter Wendorff :
> That's why I promoted to keep bridge=yes nevertheless (see previous posts)
We definitively should keep bridge=yes!
Regards,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openst
Am 01.02.2013 um 15:01 schrieb Janko Mihelić :
> I think that's harder than you think. What if you have the next example:
>
> http://i.imgur.com/ETBsfSQ.png
>
> How does the renderer preprocesor know if the middle line is inside the
> bridge area? It has to make some difficult calculations for
Am 01.02.2013 um 00:01 schrieb Michael Kugelmann :
> On 31.01.2013 12:06, Martin Vonwald wrote:
>> I'm looking for some alternatives to map tunnels and bridges that
>> contain several ways. I'm not really happy with the proposed relation
> -1
> The current method is used and well established sinc
Am 28.01.2013 um 17:26 schrieb Tobias Knerr :
> Am I missing something?
Dont think so.
> I'd like to hear your opinions.
My opinion is your opinion: if there is no good reason for gigantic areas,
don't use them.
Martin
___
Tagging mailing list
Tag
Am 25.01.2013 um 20:23 schrieb Ole Nielsen :
> It is a little bit sad that the proposal
> http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement
> died due to lack of votes. It would have resolved these problems. Maybe
> somebody could review and eventually improve it
I didn't invent neither building:use nor building:type. I was also curious
about building:type. I've seen these keys somewhere - cant remember where - and
thought they were accepted. Obviously I was wrong.
Regards,
Martin
Am 23.01.2013 um 16:59 schrieb Martin Koppenhoefer :
> 2013/1/23 Martin
Hi!
Am 03.12.2012 um 20:27 schrieb Ole Nielsen :
> I intentionally chose not to deprecate maxspeed:wet as I had the feeling that
> doing so might upset some people and I didn't want such minor issues to
> affect the voting process. Of course I will recommend to use the conditional
> scheme and
Hi,
Am 31.10.2012 um 23:49 schrieb Johan C :
> Ok, so what you guys are saying is that
> http://wiki.openstreetmap.org/wiki/Map_Features#Restrictions is wrong on the
> description of motor_vehicles. Fine to me, but I would appreciate an
> improvement of that page then. How can that be achieved
Hi,
The problem is the hierarchy of the access tags (see Land-based transportation
in http://wiki.openstreetmap.org/wiki/Access): the tag vehicle=no implies
motor_vehicle=no and e.g. bicycle=no, the tag motor_vehicle=no implies e.g.
psv=no and goods=no, and goods=no implies hgv=no. At least tha
Am 29.10.2012 um 14:27 schrieb Tobias Knerr :
> It is currently not valid - vehicle types can only appear in the key,
> whereas "groups of users" (forestry, customers, delivery, ...) can only
> appear in the value. For the "groups of users", it actually gives
> exclusive access rights to that grou
Hi!
I'm wondering what ref should be used on slip roads/ramps of a motorway (not
the junction node, but the way tagged with motorway_link). Up to now I've seen:
* the reference of the junction
* the reference of the motorway
* the reference of the junction not in the ref tag but in junction:ref
*
Am 16.10.2012 um 21:30 schrieb Eric SIBERT :
> Sorry for late answer. There is so much traffic related to lanes on this
> mailing list.
>
>> I suggest the following rewording which should reflect the initial intention:
>> "Other lanes such as Wikipedia spitsstrooken in the Netherlands or
>> Wiki
Am 15.10.2012 um 17:55 schrieb Markus Lindholm :
> But as I'm sure you've noticed there's some divided opinion about this.
That's why I asked! Actually I don't think that we see any consensus about this
soon. But then I can document at least that there are two variants under
discussion.
If I c
Am 13.10.2012 um 14:48 schrieb Janko Mihelić :
> I don't like the "lanes" tag where there are no lines on the street, it
> misses the point.
It completely misses the point! The lanes tag should only be used for lanes
that are somehow marked - usually with lines.
A narrow bridge is a narrow bri
Hi,
A quick question how you would tag this:
* one building (looks from the outside mostly like a residential building)
* the building is used for three different things: an office, a riding ground
(just assume it's a pitch) and a stable.
* the building is not separated - it's just one building
Am 21.09.2012 um 23:43 schrieb Vincent Pottier :
> But, is it possible to have something more generic across the religions like
> man_made=(something saying it is a small religious monument)
> (something saying it is a small religious
> monument)=cross|virgin_statue|statue_of
> saint|chörten|sac
Am 11.09.2012 um 16:10 schrieb Georg Feddern :
> http://roads.osm4people.org/?zoom=7&lat=49.60305&lon=10.72137&layers=B0TFF
Thanks! This covers surface, but smoothness isn't supported as far as I can see.
___
Tagging mailing list
Tagging@open
Hi,
First I have to excuse myself for this 100% off-topic mail. I nonetheless sent
it to this mailing list because here might(!) be the right target group.
I need a few volunteers for a short survey. They need to be native speakers,
preferable from GB, and not(!) involved in the legal or financ
Am 06.07.2012 um 20:48 schrieb Martin Koppenhoefer :
> If you would like to subtype it, I'd use an award-namespace, similar
> to how it was mentioned in the other thread: award:blue_flag=yes on
> the entity it applies to (be it a beach or something else)
This looks to me more descriptive and appr
Just a quick thought: wouldn't it be more readable if this tag would be a
subkey of beach, i.e. beach:blue_flag=yes? So you see at once that this is a
property of the beach.
Regards,
Martin
Am 06.07.2012 um 17:10 schrieb Johan Jönsson :
> There are plenty of beaches (and marinas) that have a b
Am 05.07.2012 um 14:59 schrieb Tobias Knerr :
> On 05.07.2012 14:03, Martin Vonwald wrote:
>> Am 05.07.2012 um 13:25 schrieb Tobias Knerr :
>>
>>> There could occasionally be an issue with the value length limit, though.
>>
>> That's what IMO is the limiting factor. And I don't think at the data
Am 05.07.2012 um 14:30 schrieb Frederik Ramm :
> reading this discussion again demonstrates how useless our voting process
> is.
Sad, but true.
> It is obvious that this issue has not been thoroughly discussed, that there
> is no consensus about which problem exactly it should solve and wha
Am 05.07.2012 um 13:49 schrieb aighes :
> Am 05.07.2012 12:08, schrieb Chris Hill:
>> This really is the wrong way round. We must always consider the mapper
>> *first*. If a scheme is too complex there will be no data added for
>> consumers to use.
> This shouldn't be a problem, because you can
Am 05.07.2012 um 12:08 schrieb Chris Hill :
> This really is the wrong way round. We must always consider the mapper
> *first*. If a scheme is too complex there will be no data added for consumers
> to use.
I fully agree with you, but simply wrote it badly. We need a scheme that is
supported b
Hi Peter,
Let's try it the other way around: how could it work (not too complex) for data
consumers? IMO there is only one possibility to completely prevent variable
keys and that's a solution no one really likes: =
;;
When we agree (do we?) that we don't want such (or a similar) co
Am 02.07.2012 um 22:09 schrieb sabas88 :
> I'd opt for landcover system.
+1 for landcover. IMO the tag natural should not be used for areas (yes, I
know, currently it is used often for areas).
___
Tagging mailing list
Tagging@openstreetmap.org
http://l
+1 to the summary and especially to:
Am 15.06.2012 um 16:41 schrieb Eckhart Wörner :
> I would also like to ask people not to blindly start new proposals, because
> otherwise we'll inevitably end up with hundreds of proposals and no
> conclusion at all.
I would even prefer to have only one, sin
Am 01.06.2012 um 15:01 schrieb Colin Smale :
> On 01/06/2012 14:19, Jason Cunningham wrote:
>>
>> On 1 June 2012 08:09, Martin Vonwald wrote:
>> But we have to make sure, that this values are only applied if real
>> indications (e.g. signposts) are present and not e.g. if one just
>> thinks that
Am 18.05.2012 um 16:32 schrieb Tobias Johansson :
>> Are we talking about
>> this?http://2.bp.blogspot.com/-Uvl-p3eVBeM/Tr8xUuhRYbI/Iho/NJZGrhCH6yk/s400/53242_1431458077448_1562786087_30891073_4275686_o.jpg
>>
>> If would think this is a Magic Roundabout.
>>
>
> Thats.. Cool :D sort of
ch allows large vehicles to turn around. "
>
> 2012/5/17 Martin Vonwald (Imagic) :
>> But this is exactly the definition of turning_place: a widening of the road
>> without any island.
>>
>> Am 17.05.2012 um 22:23 schrieb Tobias Johansson :
>>
>>>
But this is exactly the definition of turning_place: a widening of the road
without any island.
Am 17.05.2012 um 22:23 schrieb Tobias Johansson :
> There is one thing. In Sweden we have something called "Vändplats"
> http://www.transportstyrelsen.se/sv/Vag/Vagmarken/Forbudsmarken/Vandplats/
> ro
Can someone please stop NE2? I'm sick and tired of this person. Beside
contraproductive statements and continuous vandalism (yes, I call it this way)
and can't see anything useful coming from his direction.
If this isn't stop here and now I don't see any point in investing a single
second in th
Am 16.05.2012 um 19:44 schrieb Nathan Edgars II :
> Does anyone have an actual use case where it's so important to know whether
> entering traffic yields that the user expects a completely different tag when
> one or more approaches has right-of-way?
Penalties for routing?
__
Am 26.04.2012 um 20:03 schrieb Jason Cunningham :
> Major problem: You've haven't adequately dealt with the lanes=1.5 issue.
> You've suggested something that can't solve the issue, but simply looks like
> an attempt to cleanse it from the lanes tag and forget about it.
Actually I thought it wa
Am 21.04.2012 um 13:34 schrieb "Ilpo Järvinen" :
> ...What I don't really care if it is called lanes=1.5 or
> lanes=1/2+some_other_agreed_tag_which_is_not_an_estimated_width=x, but
> simply saying that use lanes=1/2 alone instead I oppose.
I would recommend lanes=2 and width=xxx. Maybe give som
Am 20.04.2012 um 16:58 schrieb Jason Cunningham :
> On 20 April 2012 14:35, Philip Barnes wrote:
> Which prompts another question, do we have a tag for a 'passing place'?
> There is a photo of one on this page
> http://en.wikipedia.org/wiki/Single-track_road
>
> Tag info shows it does highway=
Am 08.02.2012 um 20:38 schrieb Martin Koppenhoefer :
> you could have a relation to say that there is a linear possibility to
> switch between the lanes (proposed area relation). This would make
> some things much easier (we could use standard tags on the ways and it
> would be clear without count
Am 08.02.2012 um 18:48 schrieb Colin Smale :
> On 08/02/2012 17:52, Martin Vonwald wrote:
>>> I suggest putting the "lanes" qualifier in front,
>>> allowing arbitrary tag hierarchies to follow at a fixed location.
>> This was suggested, but dropped for better readability: see "Default
>> values; m
43 matches
Mail list logo