cke.jpg
Bye,
Rainer
Am 21.11.18 um 13:00 schrieb tagging-requ...@openstreetmap.org:
Re: Feature Proposal - Voting - (Tramtrack_on_highway)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
embedded_rails=tram | embedded_rails=railway.
The latter is even worse for bicycles, because the rail grooves are broader.
Best regards,
<https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dseparately_mapped&action=edit&redlink=1>Rainer
Am 20.11.18 um 13:00 schrie
ave a geographic location.
I would avoid a too generic tag like non-geographic postcode, because it
is used on POIs and any map that is made from OSM data would show it and
any user of such POI information wouldn't know, what it is.
- Rainer
Am 19.12.2017 10:50, schrieb althio:
I think o
an additional
physical address which has a different postcode for the street
address, which is regularly tagged on the physical location.
tom
On 17.12.2017 13:42, Rainer wrote:
Hi all,
recently I came across postal codes in POI addresses, which
aren&
about that are welcome.
Best regards,
Rainer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
> and what exactly is a neutron bean?
correction: should read "neutron beam"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
> I'd like to repeat once again that "substance" doesn't seem to be a nice
> key descriptor for values like ...
during the draft stage, I (we) couldn't come up with an expression that
covered everything that might one day be transported in a pipeline.
content ... too static
medium ... too spooky
hi,
first, I wouldn't use the value of substance=* as key for the detailed
level, because in this case we would introduce a new key (i.e. fuel=)
whenever a new substance is introduced (i.e. substance=fuel).
second, I'd stick with two levels (general, detailed), otherwise we'd
eventually end u
Hello Warin,
Wednesday, January 28, 2015, 8:48:16 AM, you wrote:
W> Request For Discussion
W> http://wiki.openstreetmap.org/wiki/Key:substance
thanks for picking up thus topic. I have to leave in a few minutes for
a 6 week assignment, therefore only just a few words:
- my intention & impression
michal,
MB> I don't know whether re-using service=* key is a great idea, as it's
MB> normally used as a refinement to highway=service
I took the idea from the shop=car wiki page.
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar
MB> (Compare that with
MB> all these type=* issues where it collide
hi,
MB> I am writing to propose a new, hopefully more precise and
MB> self-describing tag for shops that sell electronic parts.
there is a shop nearby that exactly matches this definition. but in
addition, it also offers repairs of TV sets, radio sets and other
consumer electronics.
In this case
andy,
thank your for joining this list.
S> You might be surprised.
that's nice to hear. finally, all the work may not have been in vain,
after all ;-)
S> To be clear, I don't think that anyone's criticising the change itself,
S> just the notification of it. [...] but it would still have been n
hi,
IJ> Won't this apply to your change:
no, because I still insist on the fact that changing 13 nodes manually
is not a mechanical edit. neither by the (small) number, nor by the
way it was done.
the main critique here is that a tag was changed during the proposal
process (type=* to substance=*
frederik,
FR> I think it's a slippery slope problem. Agreed that 13 nodes is not a
FR> lot. But at how many would you draw the line? 20? 100? 500?
all 13 nodes have been checked and edited by me manually (not using
search-and-replace). since this case is not covered in the mechanical
edit policy,
hey guys,
can you please check the comments on this changeset:
http://www.openstreetmap.org/changeset/27805365
short summary: manually editing 13 nodes is a mechanical edit that
needs to be discussed in advance, this list here is unimportant,
nobody reads proposals and 18:4 yes votes don't count.
W> Ultimate 'accuracy'? You do realise that the tectonic plates are moving?
btw: as a result of the Mar.2011 earthquake, japan has moved by at
least 5m. how did OSM react?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.
hi,
since the pipeline proposal was approved, I'm currently creating
sub-pages for most tags used in the proposal. I took the liberty to
create a page for support=* [1], as discussed earlier.
two ideas:
- support=* could also be useful for man_made=surveillance. the
example picture in [2] promine
TP> It was not clear if the OP indeed wants to map pipelines,
TP> or was just quoting the pipeline expert for his opinion about
TP> surveying methods.
the latter. I'm referring to all nodes, not just pipelines & marker.
Just used the conversation I had some time ago as an example.
W> Terms !!
W>
MK> maybe just add a note to the pipeline (note = "maped mit GPS with
MK> guaranteed accuracy of ").
I'm rather thinking of something machine-readable, enabling the editor
to warn the user in case he/she is about to change high precision
data.
___
Tag
while we are at it, imagine the following situation:
mapper A, by means of DGPS, MilStd GPS, crystal ball etc., is able to
achieve an accuracy of, say, a few centimeters and uses it to add new
nodes (POIs) to OSM.
some time later, mapper B with his/her ancestors mechanical GPS device
(*), achiev
oh well, couldn't have done it with the valuable input from members on
this mailing list and the guys on the proposals talk page.
also a big thanks to Imagic, who tutored the very beginnings of the
proposal, among other things.
cu
f> Am 11.12.2014 um 23:25 schrieb François Lacombe:
>> This is a
hi,
https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension
is now open for voting.
tnx & cu
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
MR> I do not know why anyone should tag one OSM way both with power=* and
MR> railway=*.
and here I contradict my own oppinion:
In many cities, there's a gas pipeline running under (almost) every
street, providing gas to domestic homes (as do water, sewage ...)
just imagine a city like vienna,
m
FL> @InfosReseaux <http://www.twitter.com/InfosReseaux>
FL> 2014-12-02 13:02 GMT+01:00 Rainer Fügenstein :
>> LS> I agree with you if you say that usage
>> LS> sounds like a very general key and not a railway specific key. So the
>> LS> railway guys have jus
gt;
>>> Maybe we could use a key with a namespace: power:usage=* or something
>>> else. Keeping is separate from the railway usage could give us more
>>> clairity.
>>>
>>> Lukas Sommer
>>>
>>> 2014-11-24 15:24 GMT+00:00 François Laco
hi,
FL> I knew usage=* and it can be the ideal key to indicate usage=transmission,
FL> usage=distribution,... on power lines or power cables.
If I'm not mistaken, this key is intended to serve the same purpose
as the network=* key is in the pipeline proposal:
https://wiki.openstreetmap.org/wiki/
hi,
TK> I'm certainly no pipeline expert, so forgive my ignorance. Does
TK> flow_direction=both mean that there actually is flow in both direction
TK> at the same time or does it alternate between flow directions?
the latter. the direction of the flow within the pipeline may be
changed.
TK> If th
MK> +1, also this way you give information about the direction of flow relative
MK> to the osm way, while flow_direction=oneway doesn't imply any specific
MK> direction, it only states that the direction is not reversible.
proposal updated in this regard.
__
hi
hi
f> Found one more, loop=*
f> Some month ago we were talking on this list about flow of waterways and
f> pipelines.
f> The far I remember flow_direction=forward/backward/both was mentioned to
f> tag the direction a pipeline or canal is used.
agreed; it is better to define a tag that can al
hi,
(I'm cc'ing this to the list; guess that was your intention)
>> f> 1. Please do [not] use type (it should by used only for relations) but add
>> f> some works like medium_type or pipeline_type.
after careful consideration, my GF came up with "substance". all other
options had some "substance
hi,
f> 1. Please do [not] use type (it should by used only for relations) but add
f> some works like medium_type or pipeline_type.
"type" was largely in use at the time the proposal draft was started,
therefore I kept it, but I see the point of changing it.
"pipeline_type" rather implies what's n
I'd like to bring the following proposal to your attention:
https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension
it describes a set of tags in addition to the existing
man_made=pipeline and pipeline=marker tags.
thnx for your attention
best regards
_
32 matches
Mail list logo