Hi,
I just made the proposal page for discussion about enhancing
natural=peak tag:
http://wiki.openstreetmap.org/wiki/Proposed_features/peak
This is my first attempt to define OSM features.
***
BTW - my mail was awaiting for admin approval too long, so I canceled it
and now I post it
W dniu 08.07.2014 16:14, SomeoneElse napisał(a):
Currently taginfo suggests almost no usage of peak like this
http://taginfo.openstreetmap.org/keys/peak#values
Yes, but that's exactly where the problem is: I think people are simply
cheating now. =} They see no other peak tags in wiki, so
W dniu 08.07.2014 18:50, Martin Koppenhoefer napisał(a):
the tag, i.e. I would deliberately choose natural=peak for all kind of
peaks and hilltops regardless their (geological) history. If someone
took off some stones from a natural peak it would become a man made
peak for you and you'd tag it
W dniu 08.07.2014 20:25, Martin Koppenhoefer napisał(a):
I agree, man_made=mound isn't a bad idea.
Great, feel free to make such amendments!
My original proposition is rather wide, since I'm not familiar with many
types of terrain objects and don't want to pretend I get the whole
picture.
W dniu 08.07.2014 20:04, yvecai napisał(a):
However, if rendering is an interesting topic, wiki is full of
rendering examples and advices that aren't followed anywhere. Let the
You don't even realize how sad is this observation for me...
What is the role of writing documentation than - and
W dniu 09.07.2014 2:56, John Packer napisał(a):
Daniel, I don't know about standardization of rendering, but I would
say the advice on the wiki is followed by OSM mappers much more often
than some veterans think.
Still there are some notable cases when they're not. I wouldn't be
interested in
W dniu 09.07.2014 13:39, Christoph Hormann napisał(a):
I can very much relate to that but this is not a matter that can be
resolved easily. Everyone has things he/she likes to change in the
Of course, but even open projects are not completely disconnected and we
can try to find a good
W dniu 09.07.2014 14:01, Matthijs Melissen napisał(a):
I think it's best to think of it as a two step process: first propose
the tags that describe the reality (here), then propose how they
should be rendered (on the openstreetmap-carto Github).
Well, as I said: in my proposition I did
W dniu 09.07.2014 16:56, Christoph Hormann napisał(a):
This would still require significant additional ressources including
the
workload of managing two separate styles. I don't think testing is the
In my vision testing would be not very much different, but include all
the standard tags we
W dniu 09.07.2014 17:01, Martin Koppenhoefer napisał(a):
+1. These are really two different aspects, because the tagging has
the aim to give a short, detailed, precise, specific description of
something (and so allows distinction from something different).
And then sometimes you end up with
W dniu 09.07.2014 19:08, SomeoneElse napisał(a):
Historically, the standard style was a for mappers style - it was
designed to show features that mappers had mapped. That has been
changing (largely without community involvement or review). I tried
That is exactly what I would expect! There
W dniu 09.07.2014 22:03, John Packer napisał(a):
MapQuest matches the prerequisites to be a feature tile on OSM
homepage [1].
OpenSeaMap matches them even better, so it's still not clear to me why
MQ was selected and OSeaM was not.
A similar discussion recently started on the _talk_
W dniu 16.07.2014 15:08, John Willis napisał(a):
If we trust users to tag businesses, shops, cities, roads, and
bridges, why can't we trust them to know their area better than we do?
+1 - not everything has to be official-hard-data driven to be useful,
meaningful and have sense. In real life
W dniu 18.07.2014 13:22, Martin Koppenhoefer napisał(a):
English spellings in order to keep it simple. If we started to use
arbitrary spellings we'd soon end up in a mess where you'd have to
look up the specific spelling of every single tag even when you
remember the tag...
-0,5 =}
I think
Hello,
We (in Polish forum) think, that changing landuse=grass into
natural=grass would make better tagging scheme, since grass is seldom a
landuse (like the tree is natural=tree, not the amenity or something
else). How do you find this idea?
--
Mambałaga
W dniu 2014-12-03 11:02, Mateusz Konieczny pisze:
Are there really road signs with additional plates listing all of
that stuff?
Some egregious example from Poland:
https://www.google.pl/maps/@50.0661474,19.9390468,3a,41.6y,230.88h,84.66t/data=!3m4!1e1!3m2!1s-rGw0-IoKZGQKjyZKeRl0Q!2e0?hl=en
W dniu 15.01.2015 23:35, Warin napisał(a):
What I'm after is a 'guide' rather than strict rules. Strict rules
won't encourage people to map things. Consistent tags, tools that are
easy to understand and use will encourage people as they don't have to
understand complex things.
For me
W dniu 16.01.2015 14:23, Volker Schmidt napisał(a):
Basically you want to label restaurants/shops only if they offer
something different from what's the typical local fare.
I have no proposal, I am just observing.
Of course we don't want to tag every feature if it's obvious, but as the
W dniu 27.01.2015 11:25, André Pirard napisał(a):
On 2015-01-27 09:51, Simone Saviolo wrote :
To be correct, the Virgin Mary isn't a saint either ;-)
You should urgently warn the Vatican [3] ! ;-)
It doesn't really matter anyway. =} Someone has already mentioned on
this thread that
W dniu 2015-02-09 o 12:50, Martin Koppenhoefer pisze:
2015-02-07 1:12 GMT+01:00 Jo winfi...@gmail.com
mailto:winfi...@gmail.com:
Keep in mind it's only a model to represent reality. A model which
uses lines for what in reality are areas, so whatever we do, it
will never be a
W dniu 09.03.2015 15:32, fly napisał(a):
Still miss support for man_made=bridge which leads to mapping for the
renderer as user add highway=* + area=yes to the area to get it
rendered.
The ticket is not closed, but I don't know the final decision or what
may be obstacles, however there was
W dniu 11.03.2015 17:18, Mateusz Konieczny napisał(a):
Key: square_paving_stones:width
Value: size of square paving stone in cm.
I guess similar schema can be also used with trylinka:
https://commons.wikimedia.org/wiki/File:Trylinka.jpg
which is quite common in Poland, but:
Key:
W dniu 11.03.2015 18:04, althio napisał(a):
It indeed looks to fit well within the existing scheme as a more
refined urban territorial subdivision.
place = city/town suburb neighbourhood city_block/block / plot
Yet another two, to be complete:
... borough suburb quarter
W dniu 11.03.2015 13:06, Martin Koppenhoefer napisał(a):
maybe a new place value? Of the existing ones, maybe
place=neighbourhood? Although this is a really small nieghbourhood
compared to other areas with this tag.
Probably place=city_block is exactly what you're looking for:
Lately I was trying to rethink our general tagging schemes and came up
with the impression that areas half-designed part of OSM tagging system.
IMO we have 2 problems with it: small one in microscale and a big one in
macroscale, but most probably we can deal with them separately.
***
In
W dniu 30.03.2015 18:07, Mateusz Konieczny napisał(a):
Mapping street areas should not use [highway=*; area=yes] -
[area:highway=*] is much better.
That's exactly what was proposed regarding street areas:
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area#Tagging
but I wouldn't
W dniu 30.03.2015 22:24, fly napisał(a):
In general area=yes/no is broken. Usually, there should not be a
problem
to get the information from the object (type).
You seem to be talking about interpreting data already in the database
(forest is an area - of course! =} ), while I'm talking
W dniu 31.03.2015 0:47, John Willis napisał(a):
They worry so much about vandalism and verifiability - but landmark
and importance level of local things can only be mapped and verified
by local mappers - mappers are trusted to map so many things, this
should be one of them.
I don't know this
W dniu 31.03.2015 10:18, Martin Koppenhoefer napisał(a):
I have for long been promoting a clearer approach for this kind of
mess, and I agree that there would be need to implement some changes.
While my propositions are much more than this (I'd like to fix more
fundamental issues), I'm happy
W dniu 31.03.2015 11:22, Janko Mihelić napisał(a):
Nominatim heavily uses the Wikipedia tag to decide which search result
to put in front. So if you write Paris in the search box, Paris,
Texas is not going to be the first result. They look at the length of
the article, number of translated
W dniu 01.05.2015 17:54, pmailkeey . napisał(a):
electronics says Tandy / Radio Shack / Maplin to me - with
components, boards and soldering irons and cables/connectors.
For me that would be electronic_parts or electronic_components these
days. This was different indeed when I was a child,
W dniu 11.05.2015 18:18, Andreas Goss napisał(a):
Pastry-only shops are
quite rare. See also shop=patisserie (62 uses).
But is pastry = patisserie ?
Yet another item just for sugar?... =}
I was about to create an icon for shop=confectionery in default map
style, because it looked like an
W dniu 13.05.2015 10:46, Martin Koppenhoefer napisał(a):
I'm not convinced that such a generic approach will help to get
unambiguous tagging, e.g.
Preface first (sorry, just jump to the *** section if not interested =}
)...
One thing is sure for me - there's no way to avoid ambiguity when
W dniu 16.05.2015 20:31, Marc Gemis napisał(a):
On Sat, May 16, 2015 at 5:01 AM, André Pirard
a.pirard.pa...@gmail.com wrote:
Yes, there is THE (main) map at OSM.org
That is just because you are not German or French, otherwise you might
refer to openstreetmap.de [1] or openstreetmap.fr [2].
W dniu 15.05.2015 14:52, Daniel Koć napisał(a):
And note, that it's hard for us, advanced mappers! But I guess this
project has a long tail - that means advanced users are just a tiny
(even if important) part of community. So most of the work is done by
casual mappers. They have iD as a tool
W dniu 14.05.2015 18:44, Mateusz Konieczny napisał(a):
As difference is not obvious from tag key/values I guess than most
(nearly all?) *=ice_cream are tagged by people no aware or not caring
about such nuances.
+1, that makes some noise (=avoidable errors!) in our database.
Effect is like
W dniu 13.05.2015 23:56, pmailkeey . napisał(a):
Orchard. Natural or man-made ? Does it even matter, it's just orchard.
Building IS man-made but does not come under man made.
And building is also kind of area (especially if it's large)...
Regarding this and removing amenity=* namespace - yes,
W dniu 13.05.2015 18:24, Bryce Nesbitt napisał(a):
On Wed, May 13, 2015 at 1:46 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
I'm not convinced that such a generic approach will help to get
unambiguous tagging, e.g.
children + education + building (= school building) -
architectural
W dniu 12.05.2015 21:50, Michał Brzozowski napisał(a):
1) Don't reinvent the wheel. See how competitors have tackled a
problem (Gonna elaborate very widely on that when I'll have enough
examples and time to write).
I don't know the competition and I'm curious how do they deal with it.
After
W dniu 13.05.2015 0:56, Bryce Nesbitt napisał(a):
Something that gets proposed from time to time is a tree hierarchy:
shop=food:bakery:muffins+sweets:cookie
So what are the reasons it does not catch up?
I think the downside of this example is that it would be tedious and too
detailed for
W dniu 15.05.2015 13:02, pmailkeey . napisał(a):
My concern is that OSM is/should be open to all. For it to succeed at
that, it needs to be easily understood by all - but even I would
+1 - I couldn't agree more!
10+ years of just adding more types of objects makes a lot of unneeded
cruft,
W dniu 15.05.2015 15:11, Martin Koppenhoefer napisał(a):
either one of the available tags fit for your purpose or you will have
to invent a new tag, that's how OSM works. The situation would be
Sure, I know! =}
However when you have only few fixed categories, it's much harder to
invent a
W dniu 15.05.2015 18:33, Martin Koppenhoefer napisał(a):
the area tag is sort of a special tag, it is used as a geometry flag
to say whether a closed way is linear or a polygon.
That is how we are used to think about it, but it's just a convention.
If you flip the point of view, you can say
W dniu 16.05.2015 5:01, André Pirard napisał(a):
But lately, under Is what we're doing useful?, I reported a reply
from Tom Hughes [1] seeming to say that THE map is not for the general
public and refusing to set a help page for it (plus saying that the
documentation we make amounts to being
W dniu 15.05.2015 19:35, Martin Koppenhoefer napisał(a):
yes, it is planned to have a real area datatype, sooner or later.
http://wiki.openstreetmap.org/wiki/The_Future_of_Areas [1]
Great, that'd be even better! However I guess this technical step will
be a simple transition and we may still
W dniu 18.05.2015 11:18, David Earl napisał(a):
On Mon, 18 May 2015 at 00:40 pmailkeey . pmailk...@googlemail.com
wrote:
Unfortunately change is inevitable and it happens to Microsoft and
Google customers.
Yes, of course. But they go to considerable lengths to provide upward
compatibility,
W dniu 18.05.2015 19:24, Clifford Snow napisał(a):
On Mon, May 18, 2015 at 9:13 AM, Janko Mihelić jan...@gmail.com
wrote:
This talk by Richard Fairhurst suggests that 5% of mappers do 95% of
work. So it's more important to find those few dedicated mappers and
So I probably misunderstood the
W dniu 18.05.2015 16:29, Marc Gemis napisał(a):
So you want to replace shop=bakery by bakery=yes, shop=butcher with
butcher=yes, etc. ?
This means that you cannot write a query that retrieves all shops in a
town. You would need a list of things for which the value is yes.
But you cannot
W dniu 18.05.2015 20:02, pmailkeey . napisał(a):
I disagree with this approach as it's targeted. Can we moderately
safely assume new users edit with iD ? Can we not use that interface
to offer a 'feedback' link available to all ? Even if it simply points
to a dedicated wiki page for different
W dniu 16.05.2015 9:55, Janko Mihelić napisał(a):
It maybe controversial, but I think we don't want everyone editing
the map. I think we need some barriers to filter out people who are
good mappers. Good mappers have to understand this is not a service
for them, but a community. They have to
W dniu 16.05.2015 19:42, Richard Welty napisał(a):
on the other hand, demanding that the rendering on
www.openstreetmap.org [1]
be all things to all people is actually pretty unreasonable. the
current
architecture which separates data from style is well considered and
in line
with modern
W dniu 18.05.2015 11:32, Martin Koppenhoefer napisał(a):
yes, it is a shop, but will not get the shop=* tag in OSM because it
is not a shop function, just a shop location / structure. you could
maybe use building:part=shop for it
We need a generic way of separating function from the form, in
W dniu 05.04.2015 8:16, Bryce Nesbitt napisał(a):
So come up with a better word.
Let's find common ground to improve the wiki's role in the project.
The misunderstanding in the role of the wiki vote has been persistent,
harmful, and long standing.
In my opinion this is the key problem - it's
W dniu 09.04.2015 3:42, Bryce Nesbitt napisał(a):
On Wed, Apr 8, 2015 at 11:54 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
what about exits?
Why entrance=exit of course :-).
We already have 1793 of it. =}
I would rather choose one of these:
1. entrance=emergency (3318
W dniu 19.05.2015 14:25, SomeoneElse napisał(a):
Also, it's worth mentioning that despite people sometimes describing
OSM as unfriendly the vast majority of changeset discussion
comments, especially to new users, are very friendly and happy to
help.
That's why I want to have some hard data:
W dniu 19.05.2015 16:48, Simon Poole napisał(a):
There has been at least one study which gave indications why people
stop
contributing (main reason given was time). I don't think that we are
This is really something we can't improve, sure. =} But even if it was
as high as 75% (another wild
W dniu 16.05.2015 18:41, Martin Koppenhoefer napisał(a):
There surely is some logical structure in the current osm tagging
system and yes, you either look up the tags or learn them, or you will
have to use presets ;-)
Presets are good! But I think their primary purpose is for thing you
have
W dniu 05.06.2015 17:11, Martin Koppenhoefer napisał(a):
Am 05.06.2015 um 14:12 schrieb Warin 61sundow...@gmail.com:
you might add an attribute like
sells:beverages=yes
if you find it noteworthy
Why sells ?
because it is explicit and clear
beverages=yes
fee:beverages=yes ?
bring
W dniu 06.06.2015 3:56, Warin napisał(a):
I have absolutely no objection to locals using their own language
names for things but having different icons is surely not a benefit ?
It is to the locals.
e.g. They may not see 'fast food' as a hamburger!
This is a much bigger issu than just
W dniu 06.06.2015 11:29, Colin Smale napisał(a):
Time to work towards an updated metamodel, with:
* Multiple values (lists of values - sorting out the semicolon
business?)
Sure!
* Complex values (data structures - formalising the namespace syntax?)
Any example? I don't know what are you
I'd like to ask about access=* values for some objects.
1. First is rather easy - there is fenced area with a few big apartment
houses. You can enter only if you have a key or somebody open it. Should
the highways inside be tagged with access=private? It's like few hundred
people inside, so I
W dniu 29.05.2015 13:47, pmailkeey . napisał(a):
On 29 May 2015 at 12:42, Daniel Koć daniel@koć.pl wrote:
W dniu 29.05.2015 13:34, John Willis napisał(a):
I know there is a way to tag what the building as to what it was
initially used for - but i don't think that is the proper way
(afaik
W dniu 29.05.2015 13:34, John Willis napisał(a):
I know there is a way to tag what the building as to what it was
initially used for - but i don't think that is the proper way (afaik).
So what do you think about building=church + amenity=museum then?
I think we need some clear, general
W dniu 29.05.2015 3:54, John Willis napisał(a):
Currently, building=industrial +landuse=industrial has usurped
man_made=works completely.
I think of building=industrial like a building=church - it's just a
form, we need some way to describe the function, just like we do with
I would like to ask a question about Wiki page for shop=hifi - there's a
suggestion for merging it with shop=electronics, however there's only
one statement on discussion page and it's 4 years old, so it looks like
this proposition is not valid anymore:
W dniu 31.05.2015 20:07, Marc Gemis napisał(a):
I think good presets in the editors are much more important than any
proposal to move something from one top level tag to another. Only in
case there is a problem to extend the schema (e.g. drinking water and
water), it is worthwhile to discuss a
W dniu 01.06.2015 7:15, Marc Gemis napisał(a):
On Mon, Jun 1, 2015 at 12:48 AM, Warin 61sundow...@gmail.com wrote:
The mixed ones in particular are hard to mentally recall, organise.
Do you think a tagging schema with several different sub tags is
easier ? Just use the presets in case you
W dniu 01.06.2015 14:18, Marc Gemis napisał(a):
The need to choose top-level tag for it is the problem itself.
What's a top level key ? Suppose you drop shop. Then you get
bakery=yes. Is bakery now a top level key ? Is everything acceptable
as top level in this new schema ? Won't we have
W dniu 01.06.2015 13:51, Martin Koppenhoefer napisał(a):
2015-06-01 11:51 GMT+02:00 Daniel Koć daniel@koć.pl:
You _have_ to decide whether it's a shop=travel_agency or
office=travel_agent.
no, you don't have to, you can also use both tags if you think they
should apply both.
But it's
W dniu 01.06.2015 20:51, Martin Koppenhoefer napisał(a):
no, that would be tagged area:highway=service
not even, it is an area without directional traffic
I would say that the example is really the least important part here and
you are nitpicking. =}
The same could be true with
W dniu 31.05.2015 1:33, Warin napisał(a):
Big?
Height over, say, 5 metres? Use the height= tag.
Width/length over, say, 10 metres? Use the appropriate tag.
{There is no diameter tag? Could be usefull for pipelines and
fountains and silos and etc..}
I mean big like the whole area:
W dniu 31.05.2015 10:25, Martin Koppenhoefer napisał(a):
recently there is a lot of discussion from newbies(?) here, that seem
to propose new tags and tagging schemes for stuff that is already
discussed and agreed upon and in widespread use.
Please, if you are not familiar with the tagging,
W dniu 31.05.2015 12:31, Martin Koppenhoefer napisał(a):
I'd keep amenity=fountain and render just a name (zoomlevel area size
dependent ) with no icon, and would use
man_made=nozzle or maybe
waterway=nozzle
for the single nozzle (not rendered in default style or rendered just
with a small dot)
W dniu 28.05.2015 11:22, AYTOUN RALPH napisał(a):
And with this argument for a hierarchical approach we are back to the
start point of umbrella tags that cover all possibilities which is
landuse=educational as a polygon encompassing the whole area and the
whole range of educational facilities.
W dniu 01.06.2015 0:52, Warin napisał(a):
I'd keep amenity=fountain and render just a name (zoomlevel area
size dependent ) with no icon, and would use
I think we should render areas with just a name, but points with both a
name (if available) and the icon. Here's my draft on tagging and
We try to make some conclusions regarding rendering fountains on default
map:
https://github.com/gravitystorm/openstreetmap-carto/issues/705
The discussion is rendering centered, but we need some tagging hints to
resolve it properly.
The main issue is that some fountains are in fact big
W dniu 26.05.2015 22:35, Tobias Knerr napisał(a):
On 26.05.2015 20:06, Janko Mihelić wrote:
I think we need a separate instalation of wikibase on our wiki.
I don't understand what you mean exactly: just a service without
Wikimedia data to use our own, or with a copy of Wikimedia objects
W dniu 27.05.2015 9:38, Jean-Marc Liotier napisał(a):
Also, the address must be unique - it must not be present on more than
one object, even if more than one POI exists at that address.
So there are exceptions to this rule: I know at least one example where
the same address is given for two
W dniu 26.05.2015 12:46, Jo napisał(a):
So a usecase:
Say you want to locate all the streets and other objects named after
17th century Dutch painters, worldwide.
You could start by finding the painters from wikidata, then use the
Overpass API to do a regular expression search with all the
W dniu 21.05.2015 11:30, André Pirard napisał(a):
An amenity is not an object, it's an attribute of an object like a
building.
That would be more true for building=school probably (building with the
attribute of being suitable for school use) - things are very
complicated under the
W dniu 26.05.2015 16:54, Andy Mabbett napisał(a):
On 26 May 2015 at 13:01, Daniel Koć daniel@koć.pl wrote:
Wikidata alone may be problematic, because it's independent project,
Why would that be a problem?
If you start rely on something, it's good if you have some control
W dniu 17.08.2015 4:10, Martijn van Exel napisał(a):
But after some discussion I realized that this may be a side effect of
a different problem, namely how we tag national forests. In the US,
these seem to be tagged as landuse=forest which is only partly true:
within a National Forest, many
W dniu 16.08.2015 1:27, Friedrich Volkmann napisał(a):
No, because the landcover=* key is just nonsense. There is no
definition for
http://wiki.openstreetmap.org/wiki/Landcover
that key. What does landcover mean? Vegetation? Soil? Atmosphere?
Buildings?
Ocean? Everything we map is
I have a problem understanding these two important keys. They are
defined on Wiki as:
Shop: Use shop=* to mark the location of a shop and the products that
it sells. + A place selling retail products or services.
Amenity: Covering an assortment of community facilities including
toilets,
W dniu 24.08.2015 14:11, Warin napisał(a):
So I do both ends of the scale ... benches in parks and gardens,
rubbish bins .. and upto city wide areas. Both have their appeal. The
detail is most usefull for people that are there, the larger stuff for
planning.
This what I've experienced trying
W dniu 24.08.2015 5:30, John Willis napisał(a):
On Aug 24, 2015, at 9:03 AM, Warin 61sundow...@gmail.com wrote:
The solution for me is to move shops that are in amenity= to shop=
+1
Any retail establishment should be in shop=*
Great! Thanks for your responses, especially for the background,
W dniu 29.07.2015 17:01, Martin Koppenhoefer napisał(a):
This is admittedly only the German situation but my guess is that many
other countries operate in a similar way (i.e. do have more complex
road classes internally than what is visible from signposted ref).
We have similar discussion
W dniu 02.08.2015 21:26, geow napisał(a):
I would like to propose an advanced definition of footway in order to
have a
classification criteria from path.
It would be very useful to have more clear definitions for example to
help understand how we should display it on default map style -
I have just discovered that while landcover=trees has no Wiki page, it's
quite established tag (I wouldn't say popular here, because it's just
about 1% of forest/wood uses) and we could officially define as a
generic tag for trees areas, when it's not clear for the mapper if it's
natural or
I was about to add new icon for shop=boutique and shop=fashion on our
default style, but after short discussion it seems we need some
clarification of these schemes definition:
https://github.com/gravitystorm/openstreetmap-carto/issues/1706
The only sure thing is shop=clothes, both boutique
W dniu 03.08.2015 11:59, Tom Pfeifer napisał(a):
christian.pietz...@googlemail.com wrote on 2015-08-03 09:20:
landcover=trees has it's origins in this proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/landcover
The proposal wanted to seperate the phsyical landscape (landcover)
Anybody other have problems with posts to the list getting lost? I
resend this one and hope this time it will get there:
Wiadomość oryginalna
Temat: Re: [Tagging] landcover=trees definition
Data: 10.08.2015 11:35
Od: Daniel Koć dan...@xn--ko-wla.pl
Do: Tag discussion
W dniu 10.08.2015 12:29, Jean-Marc Liotier napisał(a):
To me, it seems that mapping this area as a combination of
landuse=residential and landcover=grass would be most fitting. I have
thought about using the landuse=residential + natural=grass
combination instead, but those lawns do not strike
W dniu 10.08.2015 13:38, Ruben Maes napisał(a):
I received your original message at 11:35. (UTC+02:00)
I didn't and I have also seen no trace of it in the archive for at least
20 minutes.
In general I get them almost instantly and the archive shows them fast
too, but once or two my
Hi,
I think some feedback loop would be good from rendering dept, because
some features are requested and we could show them, but the help is
needed regarding tagging and Wiki documentation:
1. We had problems trying to render site=parking relation on default
map:
W dniu 24.07.2015 15:41, Tom Pfeifer napisał(a):
Many places where concerts are given, are multifunctional in fact,
such as playing both operas and symphonic concerts, or have speech
theatre one day and chamber_music the other.
Thus having one master value for performing arts, currently
There's a lengthy discussion going on polish forum about using
motorway/trunk tagging for our main highways:
http://forum.openstreetmap.org/viewtopic.php?id=31488
It looks that whatever solution we will choose, there's no clear mapping
between OSM and country-level classification of highways,
W dniu 16.07.2015 15:16, Richard Mann napisał(a):
You might have to explain a little more what the issue is, if you want
comments from people from other countries who don't speak much/any
Polish...
I gave the link only as a convenience for those who speak or may be
otherwise interested.
The
W dniu 16.07.2015 16:06, Richard Mann napisał(a):
I'd probably do separate relations each time the classification
changes, and let people combine information as they see fit. I'm not
convinced that further tags would help.
There is always problem of interpretation which OSM classification to
Seems like this message got lost (in the moderation maybe), so I send it
again:
W dniu 12.07.2015 17:04, Martin Koppenhoefer napisał(a):
importance: memorials are smaller. The walk into criterion is often
useful but should not be seen too strict. E.g. this obelisk, weighting
455 tons and with
1 - 100 of 295 matches
Mail list logo
