On 18.08.2017 10:01, Tom Pfeifer wrote:
> If e.g. the lower floors of the apartment building is wider than the
> upper floors, you can tag the outline with both, building=apartments and
> building:part=yes and the appropriate 3D-properties, and the narrower
> upper floors with building:part=yes and
On 16.09.2017 00:56, Tom Pfeifer wrote:
> IMHO these are not means of contact, instead these are review websites.
> While I personally think that we do not need them in OSM at all, they
> certainly do not belong in the contact:* namespace.
I agree that these aren't contact channels, and it makes n
On 17.09.2017 07:54, Erkin Alp Güney wrote:
> This brings education key instead of amenity=school.
In my opinion, and speaking broadly, the job of the OSM tagging system
is to answer two questions:
- What kind of feature is this?
- What properties does this feature have?
The first question can u
On 19.09.2017 09:46, SwiftFast wrote:
> Imagine an app where you'd click a shop, then you'd get a popup with a
> logo(see my other proposal), a slogan, and a description. All of these
> help a user understand what they're looking it.
While I accept the argument that logos allow easy visual identif
On 19.09.2017 16:27, José G Moya Y. wrote:
> It's up to
> the rendering app creators to decide if they want to display some shops
> using its logos. In that case, the app would probably have some other
> way to display them.
What way would that be?
Unless we want each render style author to maint
On 19.09.2017 23:41, Martin Koppenhoefer wrote:
> AFAIK wikidata's notability requirements should not be an issue, because
> it is sufficient there is a link to a commons page [1] to comply.
> [1] https://m.wikidata.org/wiki/Wikidata:Notability
The notability requirements specifically mention "si
On 10.12.2017 19:25, Nick Bolten wrote:
> More or less, you describe sidewalks as `highway=footway`
> `footway=sidewalk`
Unfortunately, this breaks the semantic relationship between sidewalks
and the rest of the road ("this section of sidewalk belongs to that road
section"). Many applications do n
On 11.12.2017 09:54, Selfish Seahorse wrote:
> There's a simple solution: putting a name tag on the sidewalk, as a
> sidewalk is a part of a road, like a separate carriageway.
This does not solve the problem at all, as the network of streets and
side-streets sharing the same name can be arbitraril
On 11.12.2017 01:25, Nick Bolten wrote:
>> Unfortunately, this breaks the semantic relationship between sidewalks
>> and the rest of the road ("this section of sidewalk belongs to that road
>> section").
[...]
> Absolutely, this is an open problem. However, there's no reason we can't
> tag streets
I sometimes use surface=* as a stand-alone tag for areas with an unclear
or uninteresting purpose. Doing so captures the physical reality on the
ground pretty well in my opinion.
From this point of view, the area in question is already tagged
correctly. Maybe we can find out what it's being used f
On 17.01.2018 23:16, OSMDoudou wrote:
> There is a shopping mall here [1] for which a mapper detailed the inside
> shops with a node for the "identity" and an area for the "physical
> perimeter" of the shop inside the mall. [...]
> Can you suggest tagging improvements ?
My suggestion (based on Sim
ed proposal, that
additional two weeks period will not cause any harm, and can eliminate
any doubts about the validity of the proposal.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
-world feature, then the width of e.g. a sidewalk can
still be determined at any point along the road from just the single
outline area and the way position. So unless I'm mistaken, separate
areas for the individual "lanes" wouldn't provide more
area:highway=* boundary. You wouldn't need relations or other
solutions to connect them.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
currently use for roads. I
don't believe it would work without a major redesign of our editing
tools, and I don't see OSM as a project with enough coordination to
successfully implement a major change like that if it cannot easily be
broken down into small evolutionary steps.
Am 11.05.2011 23:45, schrieb Stefan Bethke:
> Am 11.05.2011 um 23:01 schrieb Tobias Knerr:
>
>> M∡rtin Koppenhoefer wrote:
>>>> If you follow the convention that each way should be drawn along the
>>>> center of the real-world feature, then the width
d
the entire road could reduce the amount of guessing involved. Of course,
that's not the purpose the area:highway key was originally invented for.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.or
Stefan Bethke wrote:
> Am 12.05.2011 um 10:50 schrieb Tobias Knerr:
>> * I assume that most road shapes are adequately described with just a
>> single outline area for the entire road, and no one has provided a
>> counter example yet.
>
> Ever been to any city? Should
hat the proposed approach
is the best way to go. I therefore expect that proposal to be tested in
practice (-> mapping and applications) before a vote.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
ks
> prettier when the renderer doesn't do anything special to support
> residential gardens
The same effect can be achieved if residential gardens are not rendered
at all, and the residential landuse that contains the gardens is
re
t; or 16'6". "
http://wiki.openstreetmap.org/wiki/Map_Features/Units
In practice, applications should be robust enough to handle variations
in the use of spaces, but it doesn't hurt if we try to stick to a common
syntax anyway.
-- Tobias Knerr
_
erb" (in fact, I first wrote this reply based
on that assumption, and only then noticed that the proposal was using it
differently).
Furthermore, I don't understand at all why the "no" value has been
removed. There are sidewalks that are defin
cm for raised. I've edited the proposal to that effect.
I agree with your decision to go for functional classification. However,
I just noticed that it seems there isn't a value for "standard" kerbs?
(One that is neither raised nor lowered?)
-- Tobias Knerr
__
some native speakers (not all, though [1]) consider
normal kerbs "raised", and are completely confused about the originally
suggested values as a consequence.
-- Tobias Knerr
[1]
http://www.southglos.gov.uk/NR/exeres/efb6adfb-b0b4-4f00-a185-73f4dcf5197d
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
end to cause height limitations, ...) to warrant their own tags.
I'm convinced that this point wouldn't come up if the English language
didn't happen to use the term "turnstile" for both types of barriers.
-- Tobias Knerr
_
Much like Dinamik's proposal announced earlier today, my proposal
suggests an extension to restriction relation tagging. It is designed to
handle not just modes of transport, but also time-based restrictions.
http://wiki.osm.org/Proposed_features/Conditions_for_restriction_relations
-- T
native ideas floating around, and I'm
currently not aware of software support for this or any of the potential
alternatives.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
http://wiki.osm.org/Proposed_features/Conditions_for_restriction_relations
This is a proposal for tags on restriction relations. Some restrictions
do not apply universally, but are limited to certain vehicles, some days
or even some times of the day.
__
t a "cycleway", it's an exception from
an oneway restriction! The oneway:bicycle key is much better because it
fits in with other exceptions from oneway restrictions, such as oneway:bus.
So just use both for now. cyceway=opposite for backwards compatibility,
o
relation (even if the edit is not
related to the purpose of the relation!) is annoying.
Relations should therefore be avoided in favor of tags if possible. And
I'm far from convinced that relations are necessary in the particular
example that started this thread.
-- Tobias Knerr
ind an agreement and join
your proposals.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
h or latin.
> What's your opinion ?
It should be Latin because Latin species names are a well-established
convention for scientific classification of species.
-- Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
at
removing your addition to the page is a redefinition of the lanes tag.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Am 10.10.2011 01:05, schrieb Martin Koppenhoefer:
> 2011/10/10 Martin Koppenhoefer :
>> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area#area-steps
>
> Not sure how we should proceed to keep routing working.
In my opinion, the least painful option is to simply continue mapping
highway=s
Pieren wrote:
> It was not widely discussed but the proposal seems to be accepted as
> an improvement. But deprecating a tag is never easy in OSM. It needs a
> large consensus, a wide audience and time ...
The proposal is actually well designed in that regard. It doesn't
redefine any existing tags
Erik Johansson wrote:
> sport=multi is very well used but have no description in the wiki. Is
> there anyone that uses this tag?
>
> For some reason I get the feeling this is at least when I see it used
> as a shorthand for multiple values on a sport key
I'd use sport=multi on a typical gym that
Racing Ralph wrote:
>
>> BTW, the proposed feature page is misspelled: needs another F
>
> Is it possible to change? Seem sI have to add a new proposal..
Just move it. There's a little downward arrow in the right part of the
menu above the page (next to the search field). It hides a menu with
exa
Martin Koppenhoefer wrote:
> I am not sure whether this was initially only for parkings "on
> surface" (I had thought it would have been for all kind of parkings,
> so also underground and multistorey)
The "surface" default was part of the proposal that introduced the
surface/underground/multi-sto
Martin Koppenhoefer wrote:
a) ele is the elevation of the ground around/below the tower (in the
case of a mountain summit it would be the elevation of the mountain,
not the tower).
In practice, this is closest to how I would have interpreted it.
I would usually expect ele to define the elevati
Jonathan Bennett wrote:
> In summary: I believe the three classes to be separate and
> non-overlapping. So I disagree with the wiki edit made, but do think
> surface=sett is a sensible, verifiable tag.
A "sett" (a word I've never heard before) is apparently colloquially
called "cobblestone". To
John F. Eldredge:
If a structure is located on sloping ground, do you record the elevation of the
highest point in contact with the structure, the lowest point, halfway between
the highest and lowest points, or what?
This is related to the question: Where do you measure the structure's
heigh
Martin Vonwald wrote:
The proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension
is now open for voting.
Is voting on this really helpful right now? I believe that nobody can
honestly know at this point whether the proposal's idea is actually
good, whether it n
Martin Vonwald wrote:
Regarding your comments (which would better fit into the discussion page):
They were more of a footnote, but I'm happy to discuss them anyway. If
you prefer to have this discussion on the talk page, feel free to copy
the relevant sections of my mails to it. I don't mind
Martin Vonwald wrote:
1) The objective part: How is it done currently? Take a look at my
first example in the proposal - it's using maxspeed. How is maxspeed
currently tagged? According to the wiki maxspeed:forward and
maxspeed:backward should be used. What tells use taginfo? The
forward/backward
Martin Vonwald wrote:
~ 11.500 cycleway:left/right
~ 10.000 footway=left/right, 22.000 if you count "both" (same proposal)
~ 4.500 footway:left/right/both:*
As far as I understand, those are ways next to the carriageway.
If they are mapped as tags on the highway=* way, rather than as separ
I've not participated in this discussion for a while due to distractions
such as FOSSGIS and the Garching 3D Workshop.
Nevertheless, I'd like to take this opportunity to do two things before
the voting period ends: Clarify what I was talking about in the first
place, and then explain why I no
Graham Jones wrote:
> Err...what does tmc stand for?
TMC stands for Traffic Message Channel, see e.g.
http://en.wikipedia.org/wiki/Traffic_Message_Channel
It's a standardized format for transmitting information about blocked
roads, traffic jams, accidents etc. They have IDs for road sections to
b
yvecai wrote:
> What is the best way to 'separate' values?
> I think about piste:grooming='classic;skating' or 'classic+skating'.
Reasons to prefer semicolon: Has been done that way for years. Is also
documented in the wiki. http://wiki.osm.org/Semi-colon_value_separator
> Actually, this can be a
Martijn van Exel wrote:
> Consider this situation: a road on an
> incline, the sidewalk follows the road but has steps in some places. You
> would want to capture the steps for accessibility reasons, and you can't
> by just adding a sidewalk tag to the main way feature.
Except if you use one of th
Martijn van Exel wrote:
> A sidewalk is not a lane and it should not be tagged as such. Doing so
> would be utterly confusing. Does the lanes proposal (which I think is
> horribly overwrought to begin with) not exclude sidewalks?
Not explicitly. And while it is true that the examples don't include
Nathan Edgars II wrote:
> On 4/10/2012 6:38 PM, Tobias Knerr wrote:
>> Not explicitly. And while it is true that the examples don't include
>> sidewalks, they do include cycleways, where we have basically the same
>> debate whether or not they should be separate ways.
On 11.04.2012 02:04, Martijn van Exel wrote:
> On 4/10/2012 4:38 PM, Tobias Knerr wrote:
>> A sidewalk=left/right/both fails when you want to define the relative
>> ordering, and separate footway=cycleway fail in practice because no
>> renderer is actually able to puzzle the
Am 13.04.2012 08:20, schrieb Peter Wendorff:
> If we would define a set of defaults and mappers follow that set, nobody
> will add "default" values again, and it's not possible to distinguish
> between default and unknown any more.
You have identified a real problem: The distinction between defaul
Steve Bennett wrote:
> So, whoever really wants to introduce this distinction is going to
> have to find another way, perhaps "surface=cobblestone,
> cobblestone=sett".
Thank you for dealing with the issue.
Subtagging seems like a good suggestion for making this distinction. We
would also need a
Anthony wrote:
> On Wed, Apr 25, 2012 at 5:17 AM, Nathan Edgars II wrote:
>> Where did I mention a renderer? If you draw a closed polygon with
>> railway=platform, that's a continuous platform with a hole in the middle.
>> There may be a few cases of such in real life at a complicated junction.
>
Anthony wrote:
>
>> "area=no" can be considered a "sic!", but that tag should never have any
>> actual effect.
>
> Effect on what?
On renderers or any other applications working with OSM data.
> If I were writing a renderer, I would assume that a
> closed way railway=platform represented an are
28.04.2012 11:34, Peter Wendorff wrote:
> Let's consider two well known examples:
>
> building=* => usually by default area=yes, a non-closed way may be
> considered as invalid(?)
Yes, it would be invalid. As documented in the wiki, the building key
(ignoring building=entrance and the like) is fo
28.04.2012 11:24, Nathan Edgars II wrote:
> So there are a lot of major canals that have no fixed direction. How
> should these be mapped? Is there any existing scheme that can show how
> water flows under different conditions?
We have this abandoned proposal for explicitly mapping flow directions
On 27.04.2012 10:12, Pieren wrote:
> You have to know anyway if your feature can be either a closed way or
> an area and therefore need some special handling in your apps.
Unfortunately, yes. I wish we already had a proper area primitive so
this whole discussion would be obsolete.
> The question
01.05.2012 11:53, Pieren wrote:
> Not only mine. I'm still waiting at least a single example where a
> closed way for platforms is not an area
How about that one?
http://www.openstreetmap.org/browse/way/48923955
It's a public_transport=platform for busses. There's a building with
ticket shops and
On 10.05.2012 17:35, Nathan Edgars II wrote:
> On 5/10/2012 11:30 AM, Josh Doe wrote:
>> I've made some significant edits to this article to improve the
>> overall quality, as well as hopefully provide text which satisfies
>> both concerned parties.
>
> Nope - you said that it's erroneous to use t
14.05.2012 09:50, Martin Vonwald wrote:
> According to the current wiki chicanes are "Hazards on the street you
> have to drive round". This would fit the image. Also at least in my
> region we use traffic_calming=chicane to map these:
> http://www.adfc-laatzen.de/adfc/radwege/fahrbahnverengungen/e
14.05.2012 13:04, Martin Vonwald:
> Actually a wiki page exists for that:
> http://wiki.openstreetmap.org/wiki/Tag:traffic_calming=island
> It was created just two months ago and the value is not documented in
> the main article about traffic calming. The value is used about 400
> times currently.
Tobias Johansson wrote:
And preferbly the nodes with addresses should correspond to an
entrence of the building. Some reasons for this, I add a .pdf with
some:
http://wiki.openstreetmap.org/wiki/File:Housenumbers.pdf
May I ask you to avoid quoting that PDF? It only presents Lulu-Ann's
persona
On 07.06.2012 17:33, sly (sylvain letuffe) wrote:
> A recent proposal (and change after that) on the wiki has been made, which
> roughly sums up to : "relations type=multipolygon's members should only be
> closed ways, not sums of ways making closed rings, unless the way is too big
> that it wou
On 13.06.2012 15:07, Martin Vonwald wrote:
> 2012/6/13 Eckhart Wörner :
>> Competing proposals:
>> *
>> http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5
>> - in my opinion a horrible and incomprehensible syntax with arbitrary
>> distinctions, taginfo revealed almost n
On 13.06.2012 16:12, Martin Vonwald wrote:
> If you use a different character (like the ? in the 1.5)
> it would be clear where the conditions start.
That's a valid argument, but we need to be aware that there is already a
lot of existing tagging that uses a colon as the condition separator.
These
On 13.06.2012 17:18, Martin Vonwald wrote:
>
>> :forward, :backward, ...
>
> I don't think of them as conditions, but more a selection of a part of
> a way. Just like :lanes is to me not a condition.
I think we've discussed this several times already, and as you know I do
not think this "part of
On 13.06.2012 23:48, Colin Smale wrote:
> Taking the access discussion to a higher
> level of abstraction, and without abandoning the key-value pair
> paradigm, I believe we are looking for a way of giving a tag a value
> which "depends" on all kinds of "variables". *IMHO* we need a way of
> making
On 14.06.2012 08:38, Colin Smale wrote:
> My concern with this is that it may become unwieldy and cumbersome with
> anything beyond fairly trivial cases such as your maxspeed example.
For me, the goal is to make the common cases *easy*, and the rare
complex cases *possible*.
> For the human audie
On 14.06.2012 13:30, Colin Smale wrote:
>> motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural
> At first glance this looks like a motor vehicle going "forward" between
> those times is considered "agricultural". It doesn't feel very
> intuitive, based on the established key=value paradigm.
P
On 15.06.2012 23:38, Peter Wendorff wrote:
> To conclude: I really don't see any benefit in creating variable keys
> over creating fixed keys with a variable, slightly more complex
> (compared to the already complex one) value scheme.
There's one immediate problem: The 255 character limit for valu
on 29.06.2012 20:32, sabas88 wrote:
> [0]http://wiki.openstreetmap.org/wiki/Key:wholesale
> [1]http://wiki.openstreetmap.org/wiki/Proposed_features/cash_and_carry
An ideal solution would be to discuss of the issue with the key page's
creator, agree on one of the tags, and document that one.
If th
On 05.07.2012 11:59, Martin Vonwald (Imagic) wrote:
> IMO there is only one possibility to completely prevent variable keys and
> that's a solution no one really likes: =
> ;;
I don't think this solution is bad at all, in fact it would be my #2
favourite. (With me being the original a
On 05.07.2012 14:30, Frederik Ramm wrote:
> This means the whole thing isn't ready for voting. Yet I read that
> voting was "full underway". You cannot vote *instead* of having a
> discussion, it won't work. Legitimate criticism cannot be countered by
> "but we got 51% in the vote for this". Whoeve
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 database
> limit, bu
On 06.07.2012 08:47, Martin Vonwald wrote:
> One issue of the ext-cond jumped into my mind again when I read your examples
> above: in the prop it is written that the most specific value should be
> taken. But what is "most specific"? I think the correct determination of this
> could be quite co
On 04.07.2012 19:43, Tormi Tabor wrote:
> Created a new tag proposal for an apiary, let's discuss about it:
> http://wiki.openstreetmap.org/wiki/Proposed_features/apiary
landuse is generally intended for relatively large-scale features.
That you are listing nodes as an option for mapping this fea
On 06.07.2012 16:33, Chris Hill wrote:
> And you expect Jo Mapper to get this and moreover to use it, without
> mistakes?
Don't confuse "how would a program implement this" with "how do we
explain this to mappers".
If you describe a routing algorithm, it will also sound like gibberish
to most map
On 13.07.2012 02:12, Andrew Errington wrote:
> I expect that "trunk road", "roundabout", "shelter" and
> "archaeological site" are not well known in all languages, however,
> the language of OSM is English and "potable" has a very clear meaning.
Wikipedia seems to think that "potable water" and "d
On 16.07.2012 11:01, Frederik Ramm wrote:
> amenity=gym is rarely used and the wiki page advises against using it
> because it is "ambiguous":
> http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgym
There's also a proposed tag amenity=fitness_center:
http://wiki.openstreetmap.org/wiki/Proposed_feat
On 03.06.2012 17:53, Andreas Hubel wrote:
> http://wiki.openstreetmap.org/wiki/Proposed_features/Escalators_and_Moving_Walkways
The proposal has been updated to take feedback from the wiki talk page
into account. If you are interested, I suggest you review it again.
Voting will be started soon if
18.07.2012 17:51, Peter Wendorff:
> Probably add access as a useful combination to it
I've added a link to access tagging in the "other useful tags" section.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagg
18.07.2012 21:04, Martin Koppenhoefer:
> Maybe there could be an additional value proposal for
> "conveying" for cases where there is a moving walkway, but it is out
> of order (for years in the case I am thinking about). Maybe
> conveying=disused ?
To clarify: This is a "moving walkway" that neve
On 19.07.2012 23:57, Martin Koppenhoefer wrote:
>
>> To clarify: This is a "moving walkway" that never moves anymore, but you
>> can still walk on ?
>
> Yes. Probably disused=yes would be better than conveying=disused because this
> way you could still keep the information whether it is an
> es
On 30.07.2012 20:08, Paweł Paprota wrote:
>> the more redundancy the more
>> automated checks can be done to find errors.
>
> Sorry if I am being too harsh, I am not trying to be mean or anything
> but... I don't understand how this sentence would be true in any
> context. More redundancy, especia
On 02.08.2012 12:56, MilošKomarčević wrote:
> name=* without any context of what language is recorded in it is one of the
> biggest fallacies of OSM i18n and needs to be addressed.
You need to realize, though, that mappers in areas where only one
language is commonly used will not want to put more
"Petr Morávek [Xificurk]" wrote:
> Tobias Knerr wrote:
>> You need to realize, though, that mappers in areas where only one
>> language is commonly used will not want to put more effort into mapping
>> names than they do today. And rightly so, imo - from their pers
Komяpa wrote:
>
>> PS: Same with amenity=bench [2]
>
> I found linear amenity=bench quite useful for micromappning and 2.5D
> rendering:
>
> http://wiki.openstreetmap.org/wiki/File:Kothic-metrics6.png
The particular bench in your example could also be modelled as a node
with direction and width
On 05.08.2012 11:49, Vincent Pottier wrote:
> Le 05/08/2012 09:56, Tobias Knerr a écrit :
>> As far as I know, though, there is no obvious or even documented
>> convention on what side of the way the backrest would be?
>>
> It could be : backrest=left|right|none|middle
On 10.08.2012 16:47, Rob Nickerson wrote:
> I've been thinking a bit more about this and would like to improve on my
> initial thoughts from yesterday. So expanding on the existing
> opening_hours type tag, I would like to suggest the following format for
> extended access tags:
>
> * := ; ...
On 19.08.2012 14:09, Markus Lindholm wrote:
> On 19 August 2012 11:44, Fabrizio Carrai wrote:
>>
>> Indeed a "Divider=solid_line" proposal [3] was already presented . I'm would
>> revamp such proposal.
>> What is your opinion ? Is there any router developer here ?
>>
> In my opinion it's best to
On 19.08.2012 15:09, Markus Lindholm wrote:
> On 19 August 2012 14:49, Fabrizio Carrai wrote:
>> This could be a solution but it is against the reality: this kind of road
>> are indeed a single entity. The "legal" division, i.e. the "solid_line" is
>> just an attribute.
>
> There's a multitude of
On 20.08.2012 12:51, Markus Lindholm wrote:
> But why would one want to reassemble two highways going in opposite
> direction and from which there is no direct legal route to the other?
The obvious reason would be implementing any rendering style that
represents one physical highway as one line, r
On 20.08.2012 16:53, Pieren wrote:
> The proposal with "divider=solid_line" has a disadvantage : the
> meaning of a solid line differs in countries/continents. It should be
> better tagged with "divider=no_u_turn" or "no_crossing" or whatever
> you like describing the restriction, not the painted l
On 11.09.2012 14:17, Pieren wrote:
> - "customer" is documented as "disputed" in the "Values" table and
> similar do "destination". And when you read the definition of
> "destination", it says "e.g. customer parking lots". Very confusing.
> I think too that a signle value is enough as already menti
On 19.09.2012 14:44, SomeoneElse wrote:
> What attempt has been made to get editor support for this "proposal"?
Tagging ideas are often documented (as a proposal or elsewhere) first,
then actually used in the database, and only then added to editors.
At this point, a JOSM/Potlatch patch would pr
On 22.09.2012 07:19, Martin Vonwald (Imagic) wrote:
> 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
>>
On 11.10.2012 20:52, Alexander wrote:
> I am trying to establish a standard for external links to various
> platforms (including but not only facbook, qype, foursquare etc.)
[...]
> I wouldn't like to limit the tagging to these dominating platforms. New
> players should be threaten equally. Maybe t
On 14.10.2012 14:04, Eric SIBERT wrote:
> On a motorway, the emergency lane can be used by psv (bus and taxi) when
> there is traffic jam on the usual lanes. There is no predefined hours.
> Just, when traffic jam is detected, light signal are switched to
> indicate it.
You could combine "Condition
201 - 300 of 438 matches
Mail list logo
