Regarding the private_hire, I’m not so sure. We indeed you English spelling for
tags (colour, neighbourhood), and that’s okay since it’s consistent. But when
instead of just spelling we use a UK-specific legal term, it might be not
understood. For example, see village_green.
My point is that
019, at 10:46, Martin Koppenhoefer wrote:
>
>
>
> Am Di., 22. Okt. 2019 um 09:35 Uhr schrieb Ilya Zverev <mailto:i...@zverev.info>>:
> Hi folks,
>
> Today we were looking for a tag to mark this structure:
>
> http://not.textual.ru/zverik/2/5/some_hide.j
for calculating population
density.
Ilya
> On 12 Apr 2019, at 01:41, Warin <61sundow...@gmail.com> wrote:
>
> On 11/04/19 19:06, Ilya Zverev wrote:
>> You are mostly correct, =rural is for quarter areas (that are bonded by
>> streets and have no streets inside) that conta
You are mostly correct, =rural is for quarter areas (that are bonded by streets
and have no streets inside) that contain mostly one- or two-level houses, and
=urban is for bigger (~4-5 levels), usually detached apartment buildings. The
value of the tag is mostly used to assume height of
Yes.
We in maps.me, for example, use them to label continents.
It is a strange question, which can be applied to virtually anything in
OSM. Potholes — are they useful? Street lamps — are they useful? Island
nodes? Tree nodes? Landcover? Paths?
Ilya
07.08.2018 10:58, Frederik Ramm пишет:
> be, but I can't do it myself because I just didn't manage to understand
> in a reasonable amount of time the PT tagging scheme. So I'll have to
> rely on you (yes, thou who readeth me) to write it, sorry!
>
>
> On 07/20/2018 10:48 PM, Ilya Zverev wrote:
>> Hi folks,
>
Lifecycle prefixes are not for adding historic or future data in OpenStreetMap.
Please see http://openhistorymap.org/ for that.
These prefixes are in OSM only to avoid mapping mistakes. For example, when a
building is visible on a commonly used satellite imagery, but has been
demolished, we
Hi folks,
As you might've noticed, in the past year there has been growing discomfort
with the current Public Transport tagging schema. Of course, it brought order
to our route relations, but also introduced a lot of redundant concepts. We've
seen a couple proposals aiming to fix some of
Hi folks,
A while ago I've made a proposal to deprecate some public_transport=* tags:
https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms
The discussion was very slow, and in general mappers seemed to accept the
change. I'd like to push this to voting in a
Selfish Seahorse wrote:
> The course of the route is determined by the order of the stops in the
> route relation. Therefore forward/backward roles would be redundant.
But stops are not mandatory in public transport routes, unlike
highways/railways!
Ilya
Hi Muramoto-san,
Subway Entrances and Exits
If I can walk into subway station through an underground shopping mall,
where could be a subway entrance?
Most likely on the doors of a shopping mall. This is out of scope for
the proposal and should be described on the "railway=subway_entrance"
Hi,
You may remember the "Metro Mapping" proposal, which was too complex for
some, and tried to explain the rapid transit mapping in its entirety.
That was not a regular proposal, which put off a lot of people. So I am
doing the second take, now only with parts that actually change things.
marc marc wrote:
what do you think of the different issues raised? whether your proposal
is adopted or rejected, it will be difficult to implement. Would it not
be better to cancel the current vote in order to improve the proposal
with the problems raised ?
Did you read the Talk page? I
Hi,
I'd like to remind you to read the Metro Mapping proposal and to leave
your verdict in the Voting section. There is a week left until the
voting is closed.
https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping
There are a few votes that are obviously based on authority,
marc marc wrote:
> with so many modifications, it would have been useful in my opinion to
> call for comments a second time before the vote. I even think that a
> 15-day vote to make the current mapping of the majority of the big
> stations INVALID is a bit short.
I posted news about the
José G Moya Y. wrote:
> How do you map this situation:
> You can enter with wheelchair to Pacifico Metro Station metro line 1.
> You can enter with wheelchair to Pacifico Metro Station line 6.
> You can't go with wheelchair from line 6 to line 1 (or vice versa) without
> paying
> your metro fee
Martin Koppenhoefer wrote:
> sorry for asking so late, but why should we deprecate mapping subway stations
> with a relation or a way and insist on nodes? There are already a significant
> number of stations mapped like this. I would also not write: "The location of
> the node is irrelevant."
Hi everyone,
After six weeks of discussion and improvements, I am happy to start the voting
on my proposal about mapping metro stations and lines:
https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping
Note that the proposal mostly compiles mapping practices already in use and
Hi everyone,
Two months ago I suggested a way for tagging river size, from small to major.
It is a very simple proposal, offering just three tags — river=small, =big and
=major — and some numeric thresholds for these. Since it hadn't attracted many
comments, let's do a vote on that. I'm pretty
Hi,
As you know, I'm interested in formalizing the metro stations mapping.
Interchanges are an important part of subways, and there are many
different types of these. For example, sometimes there are two different
stations with different names that are linked by an underground passage.
Or
Hi,
I have elaborated on my thoughts on the correct ordering of key parts:
https://www.openstreetmap.org/user/Zverik/diary/42430
You can invert your arguments and still be right: "wikipedia:brand is the
wikipedia link for the brand, hence it is the right order, the same as with
ref:brand :
Sorting tags should not be an argument in this. You can sort by any letter you
like. I'd prefer to have all wikipedia links grouped, not all brand-related
links.
Also, would you retag all "ref:brand" to "brand:ref"? All "source:geometry" to
"geometry:source"?
Also, I've got a taginfo database
Hi folks,
One question: why brand:wikipedia and not wikipedia:brand?
Should we now use brand:ref, en:name, maxspeed:source instead of the regular
order?
http://www.openstreetmap.org/changeset/52002801
http://www.openstreetmap.org/changeset/52529386
etc.
Ilya
Hi Michael,
Am 2017-09-24 um 10:49 schrieb Ilya Zverev:
https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping
I don't understand what's the aim of your "proposal". There are almost
no new tags. Is it intended as a write-up of what could and should be
mapped and tagg
Hi,
I had a task of extracting subway infrastructure from OpenStreetMap, and
I found out that some things cannot be mapped at all (e.g.
interchanges), and some are unclear or mapped differently in different
countries.
Please consider this proposal that clarifies tagging and mapping of
> I originally thought i'd stay out of these discussions on importance tags for
> rivers (because in the end i don't think there is anything to be gained from
> it) but this is just too good an opportunity, in particular to ask a former
> Saint-Petersburg resident: So the Neva:
>
Hi everyone,
After a proposal about waterways classification by Daniel Koć, I decided to
make an alternative one. To me, using subjective values and criteria for
classifying rivers is a better way, since it can work in any country regardless
of the official classification. It could be adjusted
Martin Koppenhoefer wrote:
> to me office=notary seems ok as a tag, I'd prefer it over the office=lawyer +
> subtag tagging, they are sufficiently distinct, and I see no point in
> implying they are a subclass of lawyers which they might be or not. Office is
> a tag that is already finegrained
Hi everyone,
Recently I found that JOSM uses different tags for notary offices than I'm used
to. Turns out, there are two competing tagging schemas:
* office=lawyer + lawyer=notary: introduced in wiki in 2010, number of uses
gradually rises to ~1000.
* office=notary: introduced by accident in
Frederik Ramm wrote:
As written on the imports list, I think that separate mapping of
sidewalks will not, and should not, be the norm;
In Russia it has been the norm for a long time. Not that we have mapped
every sidewalk, but using the sidewalk=* tag is frowned upon.
IZ
Hi! I've noticed today there is an epic voting battle on the fields of
wiki. Hundreds of mappers came to state their disapproval of person
relation type. I wonder how many of them actually mapped one, or even
seen such relations. I found some of them in 2011, and posted an entry
in SHTOSM about
Dear community, WTF?
admin_level on place nodes surely duplicates admin_level tag value
from one of relations which contain that node, but is that a bad
thing?
Did you try to calculate admin_level for a place in osm2pgsql
database? I've spent two hours now trying to construct and optimize an
SQL
Sorry, two facts that I forgot to check before sending the last mail.
1. There are 63762 place nodes with an admin_level in the database,
and ~330k other nodes with this tag. I guess it's too late to forbid
using the tag on nodes.
2. It's Berlin that was edited, not London:
Martin Koppenhoefer:
admin_level has no real definition in the wiki what it is supposed to
express: the key link redirects to boundary=administrative:
http://wiki.openstreetmap.org/wiki/Key:admin_level#admin_level
...
Now there is also a key capital that can tell the administrative
Hi!
Three months ago I've prepared a proposal for turning lanes, and now,
having mapped some of those lanes, I consider it appropriate: simple,
but powerful enough. So, after a slight polishing, the voting on it is
opened -- and will continue till the end of the month. I'd be glad to
answer
http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes
Just started looking at it, and I was confused by PSV (though now I
know). Perhaps expand the acronym and provide a link to a detailed
definition, i.e. the access page. These aren't common where I live,
though it's good to know how
Martijn van Exel:
While it looks well thought out in general, I am missing the case of
the US
style center turn lane, which is a continuous center lane marked by a
yellow line that is designated for vehicles turning off of OR onto
the main
road.
bkmap:
When we already have numbers for the track positions, why we do not
use them thus? So the data consumer knows the location without the
lanes:location tag.
lanes=4
lanes:turnleft=3;4
lanes:merge=1
lanes:through=2;3
I considered this notation, but it has many drawbacks, the major one
bkmap:
It is not too late to change this. We must change about 11+2+7=20
tags worldwide if we consider to modify the notation of the
lanes:*:tag.
I'm strictly against global retagging. And it's impossible to
unambigously resolve number of lanes to lane numbers in most of those
cases.
Hi. The proposal for marking building entrances with entrance=* tags
was discussed a year and a half ago, but didn't really go anywhere:
http://wiki.openstreetmap.org/wiki/Proposed_features/entrance
Notice that there is a conversion mentioned in it, from deprecated
building=entrance.
So, how about proposals to replace tags globally? For example, after
this proposal is accepted, we could start voting on mass-retagging
entrances, so 1) it's official; 2) most data consumers get to know about
the change and adjust their software accordingly? With this we could
make a precedent
Martin Koppenhoefer wrote:
I wonder if in this case:
http://wiki.openstreetmap.org/w/images/6/69/Simpleuklanes.jpg
it would not be better to draw 2 ways (and add a relation to say that
you could - against the traffic rules or maybe as a pedestrian -
cross
the street from one way to
Martin Koppenhoefer:
how would the data consumer know, where the lanes are? E.g. a lane to
turn left might also be right of the through-lanes, and this is crucial
for routers to give good indications.
Specially for data consumers and advanced mappers there is a section in
the proposal
Hi!
lanes:directions tag was bad, and I acknowledge that. Yesterday we
finally chose a good alternative for it: lanes:X:location. It denotes
the location of lane group for X. Self-evident example:
lanes:merge:location=left. This tag removes some of mine doubts about
the proposal, and I hope,
Hi!
I've changed proposal a bit: now lanes:directions (still no good
alternative to this tag, despite long discussion in russian forum)
values are separated by commas, not semicolons: l,s,sr. This was done
because a semicolon is used to enumerate simultaneous, not consequent,
values (so
Hi! Following discussions in this list and in couple of forum threads
(and since there are some eager nav software programmers that wish to
use the first proposal they see), I studied all of the proposals for
tagging turn lanes and made a compound tagging scheme, which is not hard
to use, but
e.g. trunk_turnlanes:left:forward=1 meaning that from this point we
have
a left turning lane till the next intersection with a trunk highway
('forward' or 'backward' being relative to the osm way direction as
usual).
So, are you suggesting to use :forward/backward on nodes? I don't think
that
Peter Wendorff wrote:
Some remarks have been mentioned here already, why this proposal is
not
well designed.
Another one is, that it's tackling the lanes-problem, but not solving
it.
You propose something for turning lanes - but again restrict it to
cars.
It was not my decision, but was the
Hi! Since there were no comments for two weeks, I've pushed both
proposals to voting stage.
http://wiki.openstreetmap.org/wiki/Proposed_features/direction
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Directional_node
IZ
___
Tagging mailing
Fundamentally, I think we need to remember that OSM is not intended to
be a true representation of the world, but rather a logical
representation.
So why do we have tags for road signs and trees and colours then?
The direction that a bench, or a sign faces is not significant from
the
Hi.
Right now I've had a wtf moment. As some of you remember, there was a
proposal for water=* tag. It was discussed, voted upon and approved by 16
to 3 votes. But now there are some enraged wiki editors, one of whom erased
the whole voting section and reverted status to Proposed. And the
Hi!
Since there were no comments for the last week, I've initiated a voting on
the water=* proposal.
http://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
IZ
___
Tagging mailing list
Tagging@openstreetmap.org
I guess I can answer some of the questions.
1. In the provided links I can see all the street names in German. Do
you have any examples of uses outside of the German cultural raum?
We in Russia have created several routes using this schema. For example,
Dave. F wrote:
But also in this proposal I point out that waterway=riverbank does not
differ much from natural=water, and suggest to map it with natural=water
+
water=river.
This means you have multiple keys for river (water waterway).
It also means your using river to describe two different
Dave F. wrote:
Aren't most of these in use already?
water=river A body of river, which is currently mapped as
waterway=riverbank.
You seem to be unaware of waterway=river. Please refer to his for a
complete tagging guide:
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
On Fri, 1 Apr 2011 17:35:37 +0200, M∡rtin Koppenhoefer
dieterdre...@gmail.com wrote:
what natural=water on an area means. Is this area a lake, a pond? We
have
no means to determine that now.
could you expand what a pond is? I get several translations for this,
ranging from natural to
On Fri, 1 Apr 2011 17:55:06 +0200, M∡rtin Koppenhoefer
dieterdre...@gmail.com wrote:
So looking at wikipedia also for lake I found that basically the main
difference between the two is the size but also, how deep it is. If it
were
only the size this tag would not be needed, because unless you
Hi.
At some point we've been fed up with fixing name=Pond and such, so I guess
it's time to be more specific about what natural=water is. I suggest a new
detail tag, water=*. It's pretty straightforward, but there are some
deprecations (which at this point can't deprecate anything because there
58 matches
Mail list logo
