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
- ...
Therefo
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, write
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 s
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
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 th
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 subur
Am 18.09.2014 um 08:35 schrieb Alex Rollin:
> On Thu, Sep 18, 2014 at 12:18 PM, Mateusz Konieczny
> 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 tag
> att
Am 29.08.2014 um 09:58 schrieb Xavier Noria:
> On Fri, Aug 29, 2014 at 9:43 AM, Peter Wendorff
> 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
>> o
Am 28.08.2014 um 23:02 schrieb Xavier Noria:
> On Thu, Aug 28, 2014 at 10:39 PM, Peter Wendorff
> 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
Am 28.08.2014 um 22:35 schrieb Mateusz Konieczny:
> 2014-08-28 22:31 GMT+02:00 Xavier Noria :
>
>> 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 to use
Am 28.08.2014 um 19:10 schrieb Xavier Noria:
> On Thu, Aug 28, 2014 at 6:52 PM, John Packer 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.
>> For
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
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
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
own
tags - as long as it isn't rendered on the map itself.
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:
not a good idea IMHO.
1) what is the feature this tag should refer to? Consider a polygon that
is tagged as a building (building=yes) and a shop (shop=supermarked) and
a Walmart (operator=WalMart), and the mapper added RENDER=blue. What is
it that should be rendered blue? This object? Any supermark
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
> daycar
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 crossin
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 comp
Am 05.07.2014 20:25, schrieb Martin Koppenhoefer:
>
>
>> Am 05/lug/2014 um 14:50 schrieb Peter Wendorff
>> :
>>
>> so you would call the Mittellandkanal, connecting Elbe and Weser
>> in Germany a lake?
>
>
>
> no, and I can't imagine how
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
h
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 would
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.
- ser
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 the
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 qua
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 polygo
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
> roundabo
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 i
l database for stuff like 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 Es
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 de
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 wa
Am 10.04.2014 16:01, schrieb Pieren:
> On Thu, Apr 10, 2014 at 3:48 PM, John Packer 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 tag noex
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 access=n
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 m
the actual outline
> of the bridge rendered
> Em 15/03/2014 10:02, "Peter Wendorff" 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 curre
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
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]
http://openingh.openstreetmap.de/?setLng=en&zoom=18&lat=51.73124&lon
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 tab
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,
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 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 va
Hi André,
as far as I know, the same would be possible with
opening_hours="24/7, Fr 14:00-22:00 off"
no need for an extra tag.
Also keep in mind that two tags opening_hours and closing_hours are
error prone when used both together at the same object.
regards
Peter
Am 25.02.2014 14:50, schrieb An
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 that
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 B
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 fil
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 change
at least
cover this type of areas as well.
regards
Peter
Am 28.01.2014 15:50, schrieb Ronnie Soak:
> 2014/1/28 Peter Wendorff
>
>>
>> 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 pr
Soak:
> 2014/1/28 Peter Wendorff
>
>> 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&#
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,
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
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 addre
Am 22.01.2014 20:54, schrieb Philip Barnes:
> I think it is reasonable to map a warehouse/distribution centre, these
> are places that customers cannot go. But suppliers, truck drivers and
> the like need to find it.
+1 from me, too.
I think, the biggest problem is the way these things are tagged.
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 thei
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], Spanish
Hi Fernando,
What I'm afraid of is how a new quality-scale should be used by
arbitrary mappers around the world.
Let's assume the scale is from 1 to 5 (like tracktype is now).
For a city boy in the US who never left it's city the gravelled highway
malenki posted in this thread would be a bad road,
a simple
> numeric tag). See this: http://i.imgur.com/yEJ52eE.png
>
> On Fri, Jan 3, 2014 at 1:49 PM, malenki wrote:
>> Am Thu, 02 Jan 2014 19:36:13 +0100
>> schrieb Peter Wendorff :
>>
>>> I know (without being able to show you photos or something like that)
&
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 currently-k
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
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 trackt
IMHO the whole area may be a residential area, and residential includes
residential highways, houses, small parks and much more,
But I wouldn't say the whole area is a garden, so a garden should only
be tagged where there is a garden or mainly a garden.
In addition a single garden is a single garde
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
b Jonathan:
> I was being 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 tr
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
Pet
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
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 reg
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, a
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 for
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 of
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-
>> depen
Am 19.09.2013 12:24, schrieb Martin Koppenhoefer:
>
>
> On 19/set/2013, at 12:10, Janko Mihelić 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 fast food
Hi,
let's tackle the "problems" you mention one by one:
Am 16.09.2013 16:41, schrieb Matthijs Melissen:
> Dear all,
> [...] The lack
> of consensus does cause problems for the Openstreetmap community, though.
Most often it only cause problems for consumers of our data, not for the
mappers. Neverth
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:s
Am 28.08.2013 13:21, schrieb Martin Koppenhoefer:
> 2013/8/28 Peter Wendorff
>
>> 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
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.
>
> Locall
Am 27.08.2013 17:38, schrieb Pieren:
> On Tue, Aug 27, 2013 at 5:15 PM, Peter Wendorff
> 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'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.
Second
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
>>
>>
is an object, even a name is - but it's 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, M
Hi Martin,
Am 24.07.2013 23:55, schrieb Martin Koppenhoefer:
>
>
> Am 24/lug/2013 um 20:42 schrieb Peter Wendorff :
>
>> natural=water, leisure=fishing (I think that was your example)
>> natural=water, leisure=swimming
>> natural=water|heath|grassland|..., lei
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 ou
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 t
Am 03.07.2013 20:12, schrieb Bryce Nesbitt:
> On Wed, Jul 3, 2013 at 6:35 AM, Tobias Knerr 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
> Your O
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 @ axles>3; Y @ axles>4...
In Germany it's similar: there are weight restrictions
Am 21.06.2013 14:49, schrieb Martin Koppenhoefer:
> On 21/giu/2013, at 14:30, Pieren 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 predictable.
> E.g
Am 21.06.2013 14:38, schrieb John Sturdy:
> On Fri, Jun 21, 2013 at 1:30 PM, Pieren 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).
Probably we shoul
Am 18.06.2013 18:13, schrieb Bryce Nesbitt:
> On Tue, Jun 18, 2013 at 1:29 AM, Martin Koppenhoefer > 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 map?
Ye
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 "resta
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 other
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 wate
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 :
>> Since the hut is situated in Australia, why name it Alpine hut ? I always
>> thought the Alps to b
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
markup=yes/n
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 ass
1 - 100 of 263 matches
Mail list logo
