Hi,
I disagree here as it's highly dependant of the type of POI.
This default might be a correct assumption for shops (in countries where
that's the case), but not for
- restaurants (as well as fast food, to stay in the OSM nomenclature)
- hotels
- fuels
- swimming pools
- casinos
- ...
Hi,
to mention a major drawback of a forum IMHO:
I can read a mailinglist offline. Fetch mails to my notebook once, read
and answer while being offline and sending mails from outgoing folder as
one batch late when online again.
With a forum I would have to open any unread thread beforehand,
Hi,
the wiki page about amenity=toilet clearly states - in English and
German version, that it is used to identify a toilet *open to the public*.
As far as I can see, this seems to be the case since at least 2010
(although I didn't check any single one for intermediate differences).
The French
Am 22.01.2015 um 21:18 schrieb Martin Koppenhoefer:
a minor issue with semicolon separated lists: we don't have yet defined how
to escape actual semicolons in values.
Hi,
Is that an issue?
IMHO it's only an issue for tags where the values are names as a
semicolon can be avoided easily for any
Am 18.01.2015 um 07:14 schrieb John F. Eldredge:
You could use a light meter to measure how bright the light is. That
isn't the only factor in the suitability of the lighting, but it is
objective.
... provided that you measure on a dark night without moon and stars,
without cars driving on the
I would ask if any section of that library is usable as a library on
it's own.
Let's take the local city library here, which has several sections at
different locations.
There is the main location, a children- and computer library as a
thematic branch and several localized branches in some
Am 18.09.2014 um 08:35 schrieb Alex Rollin:
On Thu, Sep 18, 2014 at 12:18 PM, Mateusz Konieczny matkoni...@gmail.com
wrote:
That is really poor idea. IMHO remembering location and object type should
be enough to identify it.
OK, I'm game: let us say it is a node with an amenity and name
Am 28.08.2014 um 23:02 schrieb Xavier Noria:
On Thu, Aug 28, 2014 at 10:39 PM, Peter Wendorff
wendo...@uni-paderborn.de wrote:
No, it isn't.
The interpretation of the database, and the meaning, restricted to the
fact of the streets oneway-ness is the same, but no value at all does
not say
Am 29.08.2014 um 09:58 schrieb Xavier Noria:
On Fri, Aug 29, 2014 at 9:43 AM, Peter Wendorff
wendo...@uni-paderborn.de wrote:
+0.5, as UIs are decoupled from the data in OSM. You may write your own
editor with a completely different UI, even one that doesn't know about
oneway at all, so
Hi André,
Am 28.08.2014 um 01:41 schrieb André Pirard:
Hi,
Thanks for your time, Peter, and for a message which I feel like the first to
want to cooperate.
However, I don't feel well how your variants fit with the scenario I am
dealing
with, namely:
* a mapper has a feature to tag
Hi Xavier,
no is the default value of the oneway tag as it's the most correct
assumption.
First as in general most roads are not oneway roads (considering any
road inside and outside of cities), and second as the other case around
would be even worse:
If yes, this is a oneway street would be
Am 28.08.2014 um 19:10 schrieb Xavier Noria:
On Thu, Aug 28, 2014 at 6:52 PM, John Packer john.pack...@gmail.com wrote:
For a street, there is no practical difference nowadays between no
and unset, which is a smell for me. Either way means no.
For the software? No, there isn't a difference.
Am 28.08.2014 um 22:35 schrieb Mateusz Konieczny:
2014-08-28 22:31 GMT+02:00 Xavier Noria f...@hashref.com:
that area in the center with many blue lines... almost all of them are
wrong. You cannot rely on that default in Barcelona at all.
And in this really rare situation it is reasonable
Am 27.08.2014 um 17:49 schrieb André Pirard:
All the replies in this thread showed absolutely no desire to join the
fight and make suggestions, just to disparage the idea.
I don't agree here.
But the way you proposed for this fight is not a solution.
It may be if what you call (and many see as)
.
Put the effort to add rendering for missing objects. This is harder to
achieve, yes; but it is the straightforward way, not a hack around, with
major drawbacks and side effects.
regards
Peter
Am 20.08.2014 um 14:46 schrieb André Pirard:
On 2014-08-15 16:31, Peter Wendorff wrote :
not a good
I agree on the general strategy, but in this case I don't think cave=yes
would work fine by itself as these are underground ways that require to
be interpreted as being underground.
With that it is required to interpret the new tag to handle these ways
in a useful way. Using tunnel=cave would make
Hi,
Am 23.07.2014 01:48, schrieb Andreas Goss:
What we need in Germany:
*amenity=* tag for a place for children 0-3
+1 for the tag, -0.5 for amenity is difficult here as that mixes with
kindergarten in Germany.
*tag that indicates if there is a service in the afternoon OR we use
daycare
Hi André,
I think where a visible painting like at zebra crossings is painted
along a street as you describe, that isn't a crossing (it doesn't cross
anything), but more like a sidewalk without being raised or separated by
anything else but the color pattern on the ground.
Tagging those as
Hi Janko,
I disagree.
If (!) any software uses that particular tag, it should/would try to
translate at least some of these tags to it's UI language, getting:
Sandwiches, Mars, Snickers, Kaugummi, Schokolade, Salzige Snacks, Eis
as a german example for the tag you mentioned.
For showing it as it
Hi Martin,
at a first glance I thought you're joking with this proposal.
Editor software often fuses nodes on the same coordinate, that's right
unfortunately, but it's not a problem of nodes being on the same spot,
but a bug in the editors.
The handling of relations in most cases is even more
Hi,
so you would call the Mittellandkanal, connecting Elbe and Weser in
Germany a lake?
I agree with Bulwersator. A canal does not necessarily have a flow
direction. It may be built for water transport (then it might have one),
it may be built inclining - indicating a natural flow. It may even
Am 05.07.2014 20:25, schrieb Martin Koppenhoefer:
Am 05/lug/2014 um 14:50 schrieb Peter Wendorff
wendo...@uni-paderborn.de:
so you would call the Mittellandkanal, connecting Elbe and Weser
in Germany a lake?
no, and I can't imagine how you read this from my posting
Hi Paul,
As long as I see hundrets of streets, (most of them in North and South
America, although that may be accidently), that abbreviate Street to St,
Avenue to Ave and much more I wouldn't bother in cases I don't know the
long term.
Even if there may be the chance to find what it means, I
What is the address in your opinion?
- If it is what the post office uses - then in Germany the city name is
not a required part of the address as far as I know as it's included in
the postcode.
- If you refer to what the government requires to be part of an address,
the zip code is not part of
Hi Andreas,
IMHO
- access=emergency is a basic access restriction, which states that only
emergency vehicles are allowed here (unless otherwise specified).
- emergency=yes is such an otherwise specification where the main
access rule is different, it's simply another way to define the same.
-
Am 10.06.2014 12:35, schrieb Serge Wroclawski:
Bitcoin mappers have been doing everything from copying other maps
outright (violating copyright), to geocoding against Google and then
placing that in OSM (violating copyright) to geocoding against
nominatim and then using that (really bad
Hi,
I don't see justification to edit it widely in the wiki without prior
discussion, but I oppose your interpretation of this conflicting with
the one feature, one osm element principle.
In fact a shop is a different entity than a building.
A shop can move to another building while staying the
Hi Tom
Cutting by a line is easy:
- add a way with nodes for start and end of the line where it cut's the
polygon first and last.
- add nodes where that new way intersects the old polygon
- split the new way at these nodes
- split the old polygon at these nodes
- delete the parts of the old
Hi Markus,
Wiki and taginfo both are correct, but your interpretation is not ;)
There is no area data type in OSM.
Any way that forms a closed polygon may be interpreted as an
area/polygon, depending on the tags.
The info boxes are dedicated to the mapper, here saying: use it on
polygons (that
Yes, sure - didn't talk about any tag to make it an area ;)
regards
Peter
Am 25.05.2014 09:52, schrieb Andreas Labres:
On 25.05.14 09:37, Peter Wendorff wrote [a perfect explanation].
I'd like to add one thing: A closed way just is a closed way (think of a
roundabout junction). Adding
Hi,
apart from the question about how to tag it: If it is mobile, is it in
that case stable enough to be in the map?
regards
Peter
Am 01.05.2014 12:55, schrieb Esben Stien:
I was looking at Relation:enforcement:
http://wiki.openstreetmap.org/wiki/Relation:enforcement
It seems to
traffic
flow, road closed and similar information (as well as the mentioned
mobile check point), but it's not useful to add them to the core
database if it's not stated that and in which way they are temporary.
regards
Peter
Am 01.05.2014 14:43, schrieb Esben Stien:
Peter Wendorff wendo...@uni
Hi,
Am 13.04.2014 21:35, schrieb Steve Doerr:
I'm surprised that so many people are jumping to this conclusion. Let's
remember that a way is just a series of nodes in a particular order. So
a node is not necessarily an isolated object.
Agree
In many cases, it exists solely as part of a way.
Am 10.04.2014 16:01, schrieb Pieren:
On Thu, Apr 10, 2014 at 3:48 PM, John Packer john.pack...@gmail.com wrote:
I also added the following phrase to the Usage section:
In the past this tag was used on ways very often, but because tagging on
ways has several disadvantages, you should rather
Hi Rob,
it's only a warning of josm. Read it as: Hey, you made something which
may be an error. Are you sure it's what you wanted to do? and if you
answer this question with yes, ignore it
On the other hand:
What's the benefit of having gritting routes in osm? are they stable?
Are they followed
Practically I don't think it will work, as it requires much more data to
be processed in the preprocessing - I therefore agree with Martin.
But I think an intermediate solution should and could work:
If all entrances to the area are not accessible (e.g. gates, lift-gates
and such), adding
Hi,
I agree partially with you here.
Yes, adding bridges in addition to the road is possible and may be a
good idea.
What we currently map as being a bridge in fact is the property of the
road is on a bridge instead.
Changing the current tagging scheme to duplicate the corresponding
segment of
outline
of the bridge rendered
Em 15/03/2014 10:02, Peter Wendorff wendo...@uni-paderborn.de escreveu:
Hi,
I agree partially with you here.
Yes, adding bridges in addition to the road is possible and may be a
good idea.
What we currently map as being a bridge in fact is the property
Am 15.03.2014 19:19, schrieb Fernando Trebien:
Here are a few arguable reasons to split the waterway and tag it with
layer=-1:
1. Bridges may come in pairs for dual carriageways. In this case, it's
a single layer tag for the waterway versus 2 layer tags for the
bridges. This may happen many
Hi Robin,
small suggestion for your opening-hours map (nice map, by the way):
The tags list in the lower part of the markers box is (technically and
visually) a table but the key is postfixed with an additional :, which
is confusing because it may as well be part of the key itself.
Within the
Another question to the map:
do you consider POIs mapped as polygons?
The Heinz Nixdorf Museumsforum [1] in Paderborn is not shown on your map
although there's an opening_hours tag since months (if not years).
regards
Peter
[1]
Am 10.03.2014 06:39, schrieb Yves:
Many music festival take place on otherwise landuse=meadow
+1
And even other shared purpose concepts are pretty common for event
spaces, I think:
- Sometimes parks (most of the year leisure=park) are used for events
regularly.
- Many parking spaces (most of the
Hi Richard,
Aren't volcanos exactly what geothermal refers to, only near or at the
surface instead of deep down in the earth?
IMHO geothermal refers to using the thermal energy (aka heat) of the
earth, which of course in general is higher if you go deeper down, but
the temperature per depth is
Hi Richard,
Am 05.03.2014 21:50, schrieb Richard Z.:
On Wed, Mar 05, 2014 at 12:58:51PM -0600, John F. Eldredge wrote:
I don't see anything in that definition that says the heat from within the
earth has to be a minimum distance below the surface in order to be classed
as geothermal.
Hi,
even if there are examples for such a thing - is it useful?
For the breakfast example: It's useful to know that breakfast is served
up to 11 if I'm there at 10 to 11 and have to decide to take a breakfast
buffet or not; but beforehand I would have to know when it starts serving.
For a bar
you could use office=e-commerce or something like that:
At that geolocation it's an office, but it operates in the e-commerce
section, so it's probably an online shop.
Not sure if that's the best value, but that's what values are for, right?
regards
Peter
Am 19.02.2014 18:22, schrieb L. David
Am 09.02.2014 21:30, schrieb Richard Welty:
On 2/9/14 3:11 PM, Tod Fitch wrote:
[...]
Since I'm not willing to setup for generating my own OBF files it
takes a couple of weeks for me to see if the fixes I add make any
difference.
i will at some point need to learn how to generate files for
Am 05.02.2014 07:44, schrieb Kytömaa Lauri:
Bryce Nesbitt wrote:
does not represent what's on the ground: there won't be a one way
street sign.
Dual carriage roads don't have one way signs, either, but the parts
have oneway=yes. I just noticed that the relatively recently changed
Hi Ronnia,
as the use case was an outer area shared by two amenities in different
building, it's a multipolygon with one outer and one inner member, and
that should be fairly common around the world, as it's the most simple
case for an osm multipolygon, right?
regards
Peter
Am 28.01.2014 12:20,
Soak:
2014/1/28 Peter Wendorff wendo...@uni-paderborn.de
Hi Ronnia,
as the use case was an outer area shared by two amenities in different
building, it's a multipolygon with one outer and one inner member, and
that should be fairly common around the world, as it's the most simple
case
this type of areas as well.
regards
Peter
Am 28.01.2014 15:50, schrieb Ronnie Soak:
2014/1/28 Peter Wendorff wendo...@uni-paderborn.de
one building (b1) and the outer space (s) are used by a kindergarten,
the second building (b2) and the outer space (s) are used by a primary
school.
Our
Am 22.01.2014 23:42, schrieb Frederik Ramm:
Hi,
On 01/22/2014 06:27 PM, Martin Koppenhoefer wrote:
IMHO this is a geographic reality. If you had to send a letter
(physically) you would need exactly this kind of information. A
letterbox is also very physical.
We are not an address
Sounds like a good starting point at least.
regards
Peter
Am 23.01.2014 14:12, schrieb Frederik Ramm:
Hi,
On 01/23/2014 09:26 AM, Peter Wendorff wrote:
At a real, existing office with working people, it's possible that I
want to go there to apply for a job, to talk to them about an idea
Hi Martin,
in general you're right, but in this case it's a bad choice.
we as a community, as the mappers, can accept multiple values - but even
we as the mappers don't have the tools to deal with multiple values,
that is: AFAIK editors create multiple-value-tags, but don't use them,
e.g. for
Hi Matthijs,
I agree on your opinion, but I don't imply from that any automatic
re-tagging.
shop=bag is already documented in German [1] and Russion, the English
page is empty yet unfortunately. But I don't think we need a proposal
for that.
shop=pet is documented as well, in English [2],
Am 02.01.2014 17:39, schrieb Fernando Trebien:
I'm quite convinced that it's impossible to pick only one tag or the
other for this particular rendering decision and please everyone at
the same time. That's why I'm still in favour of combining them, then
each community can use whatever they
Hi,
What about hazard=rock_slide [1]?
regards
Peter
[1] http://wiki.openstreetmap.org/wiki/Proposed_features/hazard
Am 02.01.2014 17:51, schrieb John F. Eldredge:
What tag would you use on a section of roadway prone to landslides or
fallen rocks? I am not talking about tagging a
Am 01.01.2014 17:28, schrieb Fernando Trebien:
A combined approach makes sense to me. Then people can choose if they want
to use the tracktype tag or continue using just the surface tag (either may
make sense in different communities; I'd guess the German community will
prefer to use tracktype
Am 06.12.2013 02:05, schrieb Masi Master:
I think we don't should tag something at a private (really private)
ground in a residential (except the house, entrance and way to it).
IMO we don't need any private things like swimmingpools, ways, trees,
sandboxes or playgrounds at the backyard in
facetious. Hence the smiley faces. The comment wasn't
intended to be taken seriously.
J
http://bigfatfrog67.me
On 01/12/2013 21:59, Peter Wendorff wrote:
I would say it assumes hat cyclists in theory have to obey traffic rules
and a map should reflect what they have to do, not what they do
Hi,
I thought about this as well when I read the current proposal.
In Germany there are lot's of shops that are named as being primarily
for selling lottery tickets, but looking into it they are usually
selling the common combination of newspapers and magazines, tobacco and
so on. The lottery is
Thanks for these examples.
Probably something like that should be added to the proosal for
documentation and further classification.
The proposal is very verbose with text, but hasn't much examples and
images for clarifications.
Adding something like the Images you linked to would be a benefit
Hi,
I'm not happy with contact:webcam, as the contact namespace IMHO serves
a different purpose.
contact:webcam could define whom to contact for questions regarding the
webcam, or whom to contact BY webcam (as contact:phone is for how to
contact e.g. a shop by phone).
1) I would change the order,
Am 01.12.2013 16:05, schrieb Egil Hjelmeland:
On 01. des. 2013 15:28, Peter Wendorff wrote:
Hi,
I'm not happy with contact:webcam, as the contact namespace IMHO serves
a different purpose.
contact:webcam could define whom to contact for questions regarding the
webcam, or whom to contact
Am 01.12.2013 21:04, schrieb Egil Hjelmeland:
On 01. des. 2013 18:11, Peter Wendorff wrote:
Am 01.12.2013 16:05, schrieb Egil Hjelmeland:
On 01. des. 2013 15:28, Peter Wendorff wrote:
Hi,
I'm not happy with contact:webcam, as the contact namespace IMHO serves
a different purpose
I would say it assumes hat cyclists in theory have to obey traffic rules
and a map should reflect what they have to do, not what they do.
Walkers cross lawns wherever they want if that's a shortcut and rules
against that aren't enforced strictly, but we don't map any possible
shortcut.
regards
Am 04.10.2013 21:47, schrieb Richard Fairhurst:
John F. Eldredge wrote:
That brings up an issue for routing in general, not
just cycle-routing. The routing algorithm needs
to take into account the day of the week, and what
time it will be when you reach a point with time-
dependent
Am 19.09.2013 12:24, schrieb Martin Koppenhoefer:
On 19/set/2013, at 12:10, Janko Mihelić jan...@gmail.com wrote:
We have to have a place where a data consumer sees that amenity=fastfood is
a specific kind of a amenity=restaurant.
is it?
If we want to follow the operators of big
Am 29.08.2013 12:26, schrieb Ferenc Veres:
Hi,
Sorry for late reply.
That's very interesting. From this viewpoint the current SHOP values are
also inconsistent, e.g. the store: jewelry bakery, or what it sells:
shoes, baby_goods.
http://wiki.openstreetmap.org/wiki/Key:shop
But then
Am 27.08.2013 17:38, schrieb Pieren:
On Tue, Aug 27, 2013 at 5:15 PM, Peter Wendorff
wendo...@uni-paderborn.de wrote:
It's more reliable to guess the direction by
nearest-distance-to-next-intersection than to rely on any mappers to
keep that up to date, especially with iD making it extremly
Am 28.08.2013 10:35, schrieb Volker Schmidt:
Thanks for your useful comments, which essentially reflect the reasons for
which I brought up the issue. Objective criteria are difficult to define.
In particular max_width and max_length are useless because they are linked
variables.
Locally
Am 28.08.2013 13:21, schrieb Martin Koppenhoefer:
2013/8/28 Peter Wendorff wendo...@uni-paderborn.de
bicycle:trailer=no would say it's not ALLOWED to cross this barrier
with a trailer - and that is simple but wrong.
-1, as this is a new key it would probably not be defined
It's more reliable to guess the direction by
nearest-distance-to-next-intersection than to rely on any mappers to
keep that up to date, especially with iD making it extremly easy (which
is good) to change a ways direction.
nodes should NOT depend on the direction of any way they belong to.
Am 26.08.2013 08:23, schrieb Steve Bennett:
Could this have been less anglo-centric with
amenity=official_park_police_museum_information_permit_center
or
amenity=official_park_visitor_services
building=yes
rather than
amenity=ranger_station
building=yes
Hmm,
Hi Martin,
Am 24.07.2013 23:55, schrieb Martin Koppenhoefer:
Am 24/lug/2013 um 20:42 schrieb Peter Wendorff wendo...@uni-paderborn.de:
natural=water, leisure=fishing (I think that was your example)
natural=water, leisure=swimming
natural=water|heath|grassland|..., leisure=nature_reserve
up to the user/software/logical
interpretation, which of these objects speak for themself and which ones
are only useful or of interest as an attribute of another one.
regards
Peter
Am 25.07.2013 15:55, schrieb André Pirard:
On 2013-07-25 10:54, Martin Koppenhoefer wrote :
2013/7/25 Peter
Hi André,
I agree with you that this Keepright error message is not useful, but my
solution is different from yours:
I tend to think that KeepRight is wrong here. Something CAN be
natural=water and leisure=whatever in common - and why not?
Your example is perfectly valid, and others are as well.
Am 10.07.2013 15:07, schrieb alyssa wright:
Again, thanks for all the discussion. I'm following most of it. ;) I think...
Could I attempt to articulate what I consider the major confusion in the
existing kindergarten tag? Perhaps this is already known, but perhaps an
explanation could
Hi.
I personally would use building=construction only for the building that
get's constructed currently, as it's the building key. Even a small area
around that belongs to the construction site is landuse=construction,
but building=construction (as it's no building).
But if I knew the buildings
Hi,
I think, there are two main objections here, that came up in this
thread: The key you propose and the objections you got by the
wheelmap-people regarding the wheelchair-Key.
1) The key you chose:
As other already pointed out, sticker can be anything, and even worse:
any entity can have more
Am 03.07.2013 20:12, schrieb Bryce Nesbitt:
On Wed, Jul 3, 2013 at 6:35 AM, Tobias Knerr o...@tobias-knerr.de wrote:
byop is not self explanatory. Wouldn't paper_available or something
be more easily understood?
Like many tags that would benefit from a set of local translations. Bring
Am 23.06.2013 22:10, schrieb martinq:
Note: I know that in US there are weight limits depending on the number
of axles, but this could be tagged (later or already?) by conditional
tagging like maxgross_weight = X @ axles3; Y @ axles4...
In Germany it's similar: there are weight restrictions
Am 21.06.2013 14:38, schrieb John Sturdy:
On Fri, Jun 21, 2013 at 1:30 PM, Pieren pier...@gmail.com wrote:
I'm inclined to agree that fish-and-chip vans are too mobile for OSM,
although I think we could perhaps map their scheduled stopping points (like
a catering version of bus stops).
Am 21.06.2013 14:49, schrieb Martin Koppenhoefer:
On 21/giu/2013, at 14:30, Pieren pier...@gmail.com wrote:
Could we avoid moving features in OSM ? Otherwise the same object, a
trailer, will be mapped in several places.
I don't see a problem with this as long as the times are
Am 18.06.2013 18:13, schrieb Bryce Nesbitt:
On Tue, Jun 18, 2013 at 1:29 AM, Martin Koppenhoefer dieterdre...@gmail.com
wrote:
What about
addr:housenumber=801
addr:street=North Mingo Road
addr:lot=252
Under current rendering, won't that create lots of little 801's all
scattered on the
Hi.
I'm not sure where best to add this in the huge discussion tree now, but
I stumbled upon this article out of the German magazine Spiegel a few
minutes ago:
http://www.spiegel.de/reise/europa/franzosen-wollen-begriff-restaurant-schuetzen-a-904427.html
While it deals most with what's a
Hi
That's already a problem for ways, too:
A motorway with two separate highways in OSM may be one bridge
alltogether - but is mapped as two.
A street where the footways along are separated by a small wall or a
hedge is drawn as distinct osm ways (at least it should be) but if these
ways share the
Hi.
I'm curious wether the existence/usage of an oven is the best criterium
for this issue.
At least in Germany a lot of bakeries have an oven, but use it only to
bake prepared raw rolls/buns/..., selling them fresh, sometimes still
warm (if you're there at the right time at least) while the
Hi Tac.
Tagging an ATM as a osm object (usually as node) is
amenity=atm.
If there's a bank and you do NOT add the atm as a separate node (which
is perfectly valid, too), use - as you wrote yourself
amenity=bank
atm=yes
The probably best thing to do is to tag two objects:
amenity=bank
name=bad
Hi
Am 07.04.2013 22:25, schrieb Guillaume Allegre:
Hello,
I would like to propose a new tag for discussion, here and on the
wiki page:
http://wiki.openstreetmap.org/wiki/Proposed_features/water_network#Water_network_.28drinkable.29
landuse=water_wellfield, a zone dedicated to water
See wikipedia for comparison:
https://en.wikipedia.org/wiki/Montane_ecology#Alpine_grasslands_and_tundra
regards
Peter
Am 27.03.2013 14:21, schrieb Martin Koppenhoefer:
2013/3/27 St Niklaas st.nikl...@live.nl:
Since the hut is situated in Australia, why name it Alpine hut ? I always
thought
Am 28.02.2013 00:05, schrieb Balaitous:
Hi,
You insinuate that I want to remove the other tags characterizing paths.
This is false.
What I propose is a new tag providing a summarized information, such
that no algorithm can do.
Besides, I think we should also tag of the markup, like
Am 27.02.2013 12:28, schrieb Janko Mihelic':
2013/2/27 Pieren pier...@gmail.com mailto:pier...@gmail.com
Tag operator:wikidata=Q38076 much better than
operator=McDonalds ?!
Are you all so disconnected from real contributors ?
Real contributors can continue to write operator
Am 27.02.2013 13:01, schrieb Pieren:
On Wed, Feb 27, 2013 at 12:49 PM, Peter Wendorff
wendo...@uni-paderborn.de wrote:
If you keep the original operator, then I don't see the point.
Either the tags operator and operator:wikidata are different and
you have a real problem. Or the tags have
You call for editor support for a new external ID that's not controllable.
You want it to be a replacement (well, you agree to keep the old tags,
but your argumentation is that the old tags are not necessary any more
with the existence of Wikidata.
This contains several preconditions you
Am 23.02.2013 20:02, schrieb Jo:
It seems that you would like a specific role, which you can add to 2
members of a route relation (I'd add it to the two ways around your
imaginary gap).
If you do it that way, you don't need a non-existing member. And you
don't need to add nodes to a relation
Am 04.02.2013 19:00, schrieb yvecai:
Janko, to group a bunch of elements into a relation or add same a tag
to all these elements is not quite the same. A relation carry a
meaning (type), while with all these tags, It's seems to me just a
collection that you can find with a query :)
(Actually,
Am 01.02.2013 13:30, schrieb Martin Koppenhoefer:
2013/2/1 Pieren pier...@gmail.com:
And you don't fix the rendering issue because Mapnik will
continue to draw one bridge per highway.
this will entirely depend on your rendering style, it is not a mapnik issue.
and it might be a non-issue:
Am 01.02.2013 14:19, schrieb Martin Koppenhoefer:
2013/2/1 Peter Wendorff wendo...@uni-paderborn.de:
case 2: the legacy style of at least one bridge highway is painted that
wide that it's outer line(s) is/are outside of the bridge area (including
casing).
This way the legacy styles bridge
Am 01.02.2013 15:01, schrieb Janko Mihelic':
2013/2/1 Peter Wendorff wendo...@uni-paderborn.de
mailto:wendo...@uni-paderborn.de
but on the other hand it's a reasonable preprocessing step to
calculate these conflicts (sharing nodes between ways having
bridge=* and ways having
1 - 100 of 230 matches
Mail list logo
