<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am 01.09.2014 12:20, schrieb Severin Menard:<br>
> How should we map the livestock pens in farmyards?<br>
barrier = fence<br>
And (IMHO): it should be a permanet installation and no temporary thing...<br></blockquote><div><br></div><div>Thanks for your answer. Sure for barrier=fence, but it does not say what is inside the fence. The houses have a fence for the people and those ones are for the animals. When it deals with potential epizootics, it is not the same thing. What about pen=yes or run=yes? (I do not find any occurrence in taginfo, though). livestocks=* would serve to mention the kind of penned animals. <br><br></div><div>Regarding the temporary aspect, it is permanent as anything can be permanent there when the houses are made of traditional materials (straw, mud or non heated bricks) and last only a few years, when they are not regularly wiped out when flooding (I am mapping in flood prone areas). <br><br></div><div>Sincerely,<br><br>Severin<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 1 Sep 2014 10:50:17 -0400<br>
From: Bryan Housel <<a href="mailto:bryan@7thposition.com">bryan@7thposition.com</a>><br>
To: "Tag discussion, strategy and related tools"<br>
        <<a href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>><br>
Subject: Re: [Tagging] include smoothness=* in JOSM presets?<br>
Message-ID: <<a href="mailto:5FA26A84-0A46-4D89-906B-06DE69EC6A54@7thposition.com">5FA26A84-0A46-4D89-906B-06DE69EC6A54@7thposition.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
So I have some thoughts on smoothness…<br>
<br>
It’s not a terrible tag.  I think if we just replace “usable by” with “suitable for” on the wiki, it would be a bit better.  We all know that it’s certainly *possible* to take a road bike or inline skates down a pile of rocks, (I do it myself too).  That doesn’t mean the map should suggest a person actually try it just because we insist on sticking to a very *literal* definition of “usable by".  Try to think of people with wheelchairs, strollers, little kids on a bike with training wheels, etc.<br>
<br>
The text descriptions make sense to me.  The pictures can be improved, and I’m happy to help with that — I have good pictures of all the different smoothness types.   How should I proceed with this, just make the change?<br>
<br>
Thanks, Bryan<br>
<br>
<br>
<br>
On Sep 1, 2014, at 8:51 AM, Pieren <<a href="mailto:pieren3@gmail.com">pieren3@gmail.com</a>> wrote:<br>
<br>
> First, most of the people using presets (JOSM or ID) don't read the<br>
> wiki. Tags have to be self-explanatory as much as possible.<br>
> And even if you explain that "smoothness=excellent" is for roller<br>
> blade, I know skaters that could use "smoothness=good" ways easily.<br>
> And I'm still waiting some clarifications between "very_bad" and<br>
> "horrible"... We also had long discussions about reducing/simplifying<br>
> the list of values...<br>
> I would also like to see at least one application using it, if any.<br>
><br>
>> I am not really happy about it, but I was unable to invent something better and it<br>
>> not as bad as say maxspeed:practical.<br>
> Do we have to choose between bad and worse ?<br>
> As already mentionned, the skater, biker or car driver will have a<br>
> totally different idea/view of what a "good" or "bad" smoothness is<br>
> for his means of transport.<br>
><br>
> Pieren<br>
><br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 01 Sep 2014 22:27:43 +0200<br>
From: fly <<a href="mailto:lowflight66@googlemail.com">lowflight66@googlemail.com</a>><br>
To: "Tag discussion, strategy and related tools"<br>
        <<a href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>><br>
Subject: Re: [Tagging] separator for addr:housenumber=*<br>
Message-ID: <<a href="mailto:5404D6BF.8070606@googlemail.com">5404D6BF.8070606@googlemail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Am <a href="tel:24.08.2014%2017" value="+12408201417">24.08.2014 17</a>:10, schrieb Friedrich Volkmann:<br>
> On <a href="tel:24.08.2014%2013" value="+12408201413">24.08.2014 13</a>:31, Christian Quest wrote:<br>
>> In that case, how should application resolve housenumbers ?<br>
>> What tagging do you propose to allow it ?<br>
><br>
> I wrote down some thoughts here:<br>
> <a href="http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses" target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses</a><br>
> ...although I do now prefer addr2:* instead of addr[2]:*, because the former<br>
> is more widely used and easier to understand.<br>
<br>
The easiest way for me still seems to place two nodes each with one<br>
address with in the building polygon (or on its perimeter with entrance=*)<br>
<br>
<br>
> Concerning number ranges, I think that they should be mapped as they are<br>
> (i.e. ranges), because that's how they are used in the real world (number<br>
> plates, addresses in letters, etc.).<br>
<br>
Well, I had a closer look at my city and found all combinations:<br>
<br>
1. two separate buildings with one entrance in common.<br>
2. one housenumber as range (probably former two buildings/lots)<br>
3. one housenumber as range on bigger polygons with single buildings<br>
with simple housenumber inside<br>
4. one housenumber as range for multiple single housenumbers<br>
<br>
>> I'm working on the BANO project who aims to create a nationwide address<br>
>> database, using in part OSM data.<br>
>> I already have to deal with this kind of addr:housenumber=*<br>
>><br>
>> For the moment, 265-269 is transformed into 265 and 269 only, but having<br>
>> some tag based clue that we have an odd number range meaning that 267 is<br>
>> located at the same place would be a real benefit.<br>
<br>
As the discussion shows a range should be treated literally without<br>
addr:interpolation=*.<br>
<br>
> Applications need to incorporate country-specific rules. The wiki already<br>
> contains lists of country-specific maxspeeds and access restrictions for<br>
> routing, and we probably need a list of country-specific rules for house<br>
> numbers as well. E.g. house number ranges mean either either odd oder even<br>
> numbers in Austria. In other coutries, a range may stand for both odd and<br>
> even numbers.<br>
<br>
In Germany I find both variants within the same cities.<br>
<br>
> Given that the BANO project aims for a nationwide database only, your task<br>
> seems easy. You probably already know the rules for your country.<br>
<br>
cu fly<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 1 Sep 2014 23:16:57 +0200<br>
From: Mateusz Konieczny <<a href="mailto:matkoniecz@gmail.com">matkoniecz@gmail.com</a>><br>
To: "Tag discussion, strategy and related tools"<br>
        <<a href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>><br>
Subject: Re: [Tagging] include smoothness=* in JOSM presets?<br>
Message-ID:<br>
        <<a href="mailto:CALDvra4XA-a%2Bpz87xFD7chxKdL42PHM9xKhHqR9vEAmZ6fXmBw@mail.gmail.com">CALDvra4XA-a+pz87xFD7chxKdL42PHM9xKhHqR9vEAmZ6fXmBw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2014-09-01 14:51 GMT+02:00 Pieren <<a href="mailto:pieren3@gmail.com">pieren3@gmail.com</a>>:<br>
<br>
> I would also like to see at least one application using it, if any.<br>
><br>
<br>
For example I use it in my small project -<br>
<a href="https://github.com/mkoniecz/bicycle_map_of_Krakow" target="_blank">https://github.com/mkoniecz/bicycle_map_of_Krakow</a><br>
There are some sidewalks with allowed cycling but completely decayed paving<br>
stones and there<br>
is no better way to tag this. There are also some asphalt roads with really<br>
bad surface. etc etc.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstreetmap.org/pipermail/tagging/attachments/20140901/2ba58826/attachment-0001.html" target="_blank">http://lists.openstreetmap.org/pipermail/tagging/attachments/20140901/2ba58826/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 2 Sep 2014 13:50:51 +0900<br>
From: Satoshi IIDA <<a href="mailto:nyampire@gmail.com">nyampire@gmail.com</a>><br>
To: "Tag discussion, strategy and related tools"<br>
        <<a href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>><br>
Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex<br>
        junctions or traffic signals that are named<br>
Message-ID:<br>
        <CAGexURDon59DKNB8D=UkP=A=<a href="mailto:R%2BUTNosvmzvG3Yy5aXiy6npj1A@mail.gmail.com">R+UTNosvmzvG3Yy5aXiy6npj1A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello from Japan,<br>
<br>
> @Lukas are the names of the traffic signals/junctions actually used in<br>
> addresses (and in principal would be a suitable value for addr:place in<br>
an address)?<br>
No.<br>
We realize the name of traffic signal only for routing and navigation on<br>
local district.<br>
It is very separated concept from "place" (residence of human kind) tag or<br>
"addr:*" (postal delivery) tag.<br>
<br>
The name of traffic signal is not used as addressing system.<br>
And if there are very dense traffic signals, occasionally the names are<br>
like...<br>
"XZY Conter(Chuo)", "XZY North", "XZY West", or so.<br>
<br>
# "XZY" is the name of place or district, like Roppongi or Akihabara.<br>
<br>
<br>
Following maybe off topic...<br>
Hence, some JP mappers had proposed "place=locality" for old/famous name<br>
for mountain path crossing.<br>
e.g. "XZY tsuji (辻, crossing)" or "XZY Touge (峠, peak)".<br>
<br>
They may be acceptable, because we realize them as old/famous place name.<br>
But I do not feel that it would not suite for modern traffic_signal system.<br>
<br>
<br>
<br>
<br>
2014-08-26 6:34 GMT+09:00 Jean-Marc Liotier <<a href="mailto:jm@liotier.org">jm@liotier.org</a>>:<br>
<br>
> On 08/25/2014 11:09 PM, Lukas Sommer wrote:<br>
><br>
>> In Ivory Coast, you have addresses like “in front of the XYZ crossroad”<br>
>> or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort<br>
>> of instructions for getting somewhere than an address in the european<br>
>> sense. Obviously “from XYZ crossroad 50 m towards the big fueling station”<br>
>> will be applied to various houses (usually, when you have arrived, you make<br>
>> a phone call to the person that you want to meet, and the person comes to<br>
>> the road to search you and help you with the last part of the way – I can<br>
>> guarantee you that this is very time-consuming ;-)<br>
>><br>
><br>
> That said, people in quite a few African countries have a postal address<br>
> (PO box in most cases) distinct from the address of their residence, so the<br>
> problem of shoehorning directions in the standard address fields of<br>
> European-designed software is side-stepped more often than not.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
><br>
<br>
<br>
<br>
--<br>
Satoshi IIDA<br>
mail: <a href="mailto:nyampire@gmail.com">nyampire@gmail.com</a><br>
twitter: @nyampire<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstreetmap.org/pipermail/tagging/attachments/20140902/c2110b9c/attachment-0001.html" target="_blank">http://lists.openstreetmap.org/pipermail/tagging/attachments/20140902/c2110b9c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 2 Sep 2014 10:11:27 +0200<br>
From: Pieren <<a href="mailto:pieren3@gmail.com">pieren3@gmail.com</a>><br>
To: "Tag discussion, strategy and related tools"<br>
        <<a href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>><br>
Subject: Re: [Tagging] include smoothness=* in JOSM presets?<br>
Message-ID:<br>
        <<a href="mailto:CAPT3zJp-oy1Q0J%2B_Qaxzxu91rXSfw1wJvYh-ZV_emQ1TqOnj1w@mail.gmail.com">CAPT3zJp-oy1Q0J+_Qaxzxu91rXSfw1wJvYh-ZV_emQ1TqOnj1w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Mon, Sep 1, 2014 at 11:16 PM, Mateusz Konieczny <<a href="mailto:matkoniecz@gmail.com">matkoniecz@gmail.com</a>> wrote:<br>
<br>
> There are some sidewalks with allowed cycling but completely decayed paving<br>
> stones and there<br>
> is no better way to tag this. There are also some asphalt roads with really<br>
> bad surface. etc etc.<br>
<br>
I didn't check your application but the smoothness tags in Krakow.<br>
This way for instance is a good example:<br>
<a href="http://www.openstreetmap.org/way/37702408" target="_blank">http://www.openstreetmap.org/way/37702408</a><br>
smoothness=good on a pedestrian highway (also with a "bicycle=yes").<br>
You added this tag in changeset 24356171 . I guess your intention was<br>
to specify a good smoothness for bicycles but others could interpret<br>
this tag as simply good enough for pedestrians...<br>
<br>
Pieren<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Tagging Digest, Vol 60, Issue 3<br>
**************************************<br>
</blockquote></div><br></div></div>