On Sun, Jun 29, 2014 at 7:11 PM, Lukas Sommer wrote:
> Am I right?
FYI, we had a recent discussion about roundabouts controlled by
traffic lights on this list:
http://gis.19327.n5.nabble.com/Signal-controlled-roundabouts-td5808587.html
Pieren
___
Tagg
2014-06-30 2:55 GMT+02:00 John Packer :
> I used wikipedia:operator instead of operator:wikipedia because the former
> is used way more often
I think the semantics are different. The tag operator:wikipedia seems to me
like the wikipedia page about the operator, while wikipedia:operator seems
to
2014-06-29 19:11 GMT+02:00 Lukas Sommer :
> How do I tag correct a Hamburger roundabout/throughabout/cut-through (see
> http://en.wikipedia.org/wiki/Roundabout#Hamburger_roundabout.2Fthroughabout.2Fcut-through
> for a description).
>
I would probably tag this in analogy to a "Y"-shaped junction,
but I was aware it conflicts with the language version
The best solution would be to just use Wikidata. If editors supported
that, then they could also always show the titel of the Wikidata tag to
avoid errors.
http://wiki.openstreetmap.org/wiki/Wikidata
I think part of the confusion come
On 30/06/2014 10:34, Andreas Goss wrote:
but I was aware it conflicts with the language version
The best solution would be to just use Wikidata. If editors supported
that, then they could also always show the titel of the Wikidata tag
to avoid errors.
http://wiki.openstreetmap.org/wiki/Wiki
So in this two particular cases (Bayford's head office and building, and
Buxton College with its two websites), what _actual_ tag values would
you suggest?
Cheers,
Andy
I think right now the tagging of the building is incomplete. If you want
to tag Bayford & Co on the building, then the build
On 30/06/2014 10:57, Andreas Goss wrote:
If the building is important I would tag the company as a seperate
node on the building and then there is no confusion with the basic tag
anymore.
I'd agree (that in the Bayford's HO case) having the company details on
a node within the building woul
2014-06-30 11:57 GMT+02:00 Andreas Goss :
> I think right now the tagging of the building is incomplete. If you want
> to tag Bayford & Co on the building, then the building should have a tag
> office=company. At that moment the wiki or wikidata tag clearly refers to
> them.
>
+1, the object see
2014-06-30 12:02 GMT+02:00 SomeoneElse :
> I'd agree (that in the Bayford's HO case) having the company details on a
> node within the building would be the best way to go,
yes, it will be a significant improvement, but a better solution seems to
me a multipolygon-relation for the company, cont
We're presumably suggesting "wikidata=$something" but what is "$something"?
Every Wikidata entry has an ID. You can find it in the URL and behind
the title:
OpenStreetMap: Q936
https://www.wikidata.org/wiki/Q936
So you would use wikidata=Q936
__
openstreetmap.org/user/AndiG88
wiki.op
On 30/06/2014 11:12, Andreas Goss wrote:
We're presumably suggesting "wikidata=$something" but what is
"$something"?
Every Wikidata entry has an ID. You can find it in the URL and behind
the title:
OpenStreetMap: Q936
https://www.wikidata.org/wiki/Q936
So you would use wikidata=Q936
That'
The University of Derby would be:
wikidata:operator=Q3183295
Devonshire Royal Hospital
wikidata:operator=Q5267877
Does the building itself also have wikipedia page?
Polyglot
2014-06-30 12:12 GMT+02:00 Andreas Goss :
> We're presumably suggesting "wikidata=$something" but what is "$something
Bayford:
operator:wikidata=Q4874513
The ones of my previous mail should also have been operator:wikidata
Polyglot
2014-06-30 12:27 GMT+02:00 Jo :
> The University of Derby would be:
>
> wikidata:operator=Q3183295
>
> Devonshire Royal Hospital
>
> wikidata:operator=Q5267877
>
> Does the buildi
2014-06-30 12:27 GMT+02:00 Jo :
> The University of Derby would be:
>
> wikidata:operator=Q3183295
>
> Devonshire Royal Hospital
>
> wikidata:operator=Q5267877
>
wouldn't operator:wikidata make more sense?
___
Tagging mailing list
Tagging@openstreetma
Indeed, sorry about that.
2014-06-30 12:46 GMT+02:00 Martin Koppenhoefer :
>
> 2014-06-30 12:27 GMT+02:00 Jo :
>
>> The University of Derby would be:
>>
>>
>> wikidata:operator=Q3183295
>>
>> Devonshire Royal Hospital
>>
>> wikidata:operator=Q5267877
>>
>
>
>
> wouldn't operator:wikidata make mo
To clarify: wikipedia:operator is exactly the same thing as
operator:wikipedia.
Historically, the key wikipedia has the same order as the key source.
It might seem strange since this conflicts with the language version, but
that's simply the result of an "organic" growth of the tag's definition.
On 30 June 2014 10:34, Andreas Goss wrote:
>> but I was aware it conflicts with the language version
>
>
> The best solution would be to just use Wikidata. If editors supported that,
> then they could also always show the titel of the Wikidata tag to avoid
> errors.
>
> http://wiki.openstreetmap.o
I'm strongly in favour of having the order as described here:
http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
The advantage is that they sort near to what they apply to,
name:etymology:wikidata is near to name, operator:wikidata is near to
operator and so on.
I'm not sure why we ha
I would advise to be cautious with adding wikidata tags with a bot, because
a wikipedia article could have been moved and the wikidata tag would point
to a wrong page. (i.e. the bot should also perform the standard checks even
in this case)
I believe leaving the wikipedia tag in place while adding
Hi everyone,
I've just added a new section in the man_made=street_cabinet proposal.
It gives a list of values which should be replaced with caution if the
proposal is accepted.
https://wiki.openstreetmap.org/wiki/Proposed_features/Street_cabinet#Values_to_be_replaced
User who introduced utility=
On Mon, Jun 30, 2014 at 1:36 PM, John Packer wrote:
> The main reason is that the wikipedia key is well established and supported
> in some sites, which either point a link to it or use some image from the
> page.
No, the main reason is that the wikipedia key is still human readable
where the wi
2014-06-30 13:18 GMT+02:00 John Packer :
> To clarify: wikipedia:operator is exactly the same thing as
> operator:wikipedia.
that's presumably how (most/all) people intended to use it, yes, but there
is no guarantee, and there is indeed room for different interpretations as
well. You'd also oft
Hi,
Let us notice that, unlike my message, your replies do not comment the
*reasons* for source tags location.
I say:
* the wiki instructions say to put sources in the objects
* it needs fumbling to see changeset sources (is it fair to the author?)
* only source in objects can be used in ov
Thanks for the clarification!
2014-06-30 9:11 GMT, Martin Koppenhoefer :
> 2014-06-29 19:11 GMT+02:00 Lukas Sommer :
>
>> How do I tag correct a Hamburger roundabout/throughabout/cut-through (see
>> http://en.wikipedia.org/wiki/Roundabout#Hamburger_roundabout.2Fthroughabout.2Fcut-through
>> for a
Am 6/30/14 15:30 , schrieb Pieren:
And one of the mentionned
example is providing the building operator only through the
"wikipedia:operator" where most of the data consumers are simply
looking for the "operator" tag.
I agree this should not happen, but can also be easily fixed by either a
bot
Hello,
I've recently reviewed some aerodromes in southern Brazil and,
following some advice in the wiki [1], I've replaced the "type" tag
with an "aerodrome" tag [2]. Do you agree that this is correct? Should
we update tagging recommendations for aerodromes [3] and aeroways [4]
in the wiki?
[1] h
Just like everybody else I started several years ago by adding source tags
on the objects themselves.
The whole reason why the imports list says source tags belong on the
changeset has something to do with an import of millions of buildings in
France, each and every one with:
source=cadastre-dgi-
On Mon, Jun 30, 2014 at 06:40:47PM +0200, Jo wrote:
> Just like everybody else I started several years ago by adding source tags
> on the objects themselves.
I changed to putting the source on to change sets, but hit a problem
with armchair-mappers.
I found armchair mappers overwriting carefully
At least in JOSM if you do a ctrl-h on a selected object it shows you the
source entry text that given on the change set (if it exists which it usually
doesn't on older change sets). If the other editors don't show that, then they
should be fixed.
So the argument that it is not feasible for arm
We have just rolled out version 2.16.0 of openstreetmap-carto, the main
Openstreetmap rendering. This version includes a change in rendering which
might make current incorrect tagging of some highway areas more noticeable.
Buildings will now be rendered behind highways areas, rather than on top of
If the tagging of the object is tricky or not obvious, or it is prone to be
miscorrected by armchair mappers, it's useful to add a note in the
appropriate language with the key note=*.
For example, I have added it to part of a street that is used only for
parking, and doesn't legally lead anywhere.
On Mon, Jun 30, 2014 at 2:36 PM, Matthijs Melissen wrote:
> Buildings will now be rendered behind highways areas, rather than on top
> of them. The new rendering might cause issues with areas with buildings in
> the middle. The correct way to tag such areas is as a multipolygon, with
> the buildi
On 30/06/2014 22:17, Tod Fitch wrote:
At least in JOSM if you do a ctrl-h on a selected object it shows you the
source entry text that given on the change set (if it exists which it usually
doesn't on older change sets). If the other editors don't show that, then they
should be fixed.
For in
> Can you help me understand what exactly should be tagged as a multipolygon?
Highway areas - see https://www.openstreetmap.org/changeset/23399879 that
created https://www.openstreetmap.org/relation/3278602
Tunnels and in general roads tagged as ways are unaffected.
> Also, it would be nice to s
> I'm not sure if OSM Messaging is built-in in JOSM, but it could be useful
for quick messaging in this kind of case
No, due to missing API features. All that could be done is checking for unread
messages.
___
Tagging mailing list
Tagging@openstreetma
35 matches
Mail list logo
