Re: [Talk-it] Violazione Licenza - FoodChain-Lab

[Fra Mauro]

Grazie mille Martin!

Il 9 Novembre 2019 01:18:33 CET, Martin Koppenhoefer  
ha scritto:
>
>
>sent from a phone
>
>> On 7. Nov 2019, at 15:51, Marco Minghini 
>wrote:
>> 
>> Si potrebbe cominciare aprendo una issue nella repo del progetto:
>https://github.com/SiLeBAT/BfROpenLab/issues
>> o commentando questa issue, che forse si riferisce proprio alla
>mancata attribuzione (ma non c'è descrizione per capirlo):
>https://github.com/SiLeBAT/BfROpenLab/issues/459
>
>
>l’ho fatto. Vediamo se reagiscono...
>
>Ciao Martin 

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-at] name:suffix & name:prefix (de)

[andreas wecer]

Am Sa., 9. Nov. 2019 um 00:54 Uhr schrieb PPete :

> Erstere ist bisher durch den Tag "ref:at:gkz" erfasst, zweitere finde
> ich gar keine. Die Bezirke sind derzeit mit mit dem GKZ getaggt,
> erhalten aber zumindest die richtige Nummer.
>

Der Bezirk wird (wie auch das Land) vom GKZ abgeleitet und entspricht den
ersten drei Ziffern.
Laut verstaubtem Wiki soll das beim Bezirk entsprechend auch als
dreistelliges GKZ abgegeben werden. Statutarstädte sind bzgl. GKZ nicht
explizit angegeben, aber nachdem das auch Gemeinden sind, würde ich es auch
fünfstellig für die Gemeinde angeben.
https://wiki.openstreetmap.org/wiki/WikiProject_Austria/Gebietsk%C3%B6rperschaften

Am Sa., 9. Nov. 2019 um 03:39 Uhr schrieb Robert Kaiser :

> IMHO ist diese Relation sowieso falsch (und ev. alle Statutarstädte).
> Der Bezirk heißt "Steyr-Stadt", die Gemeinde heißt "Steyr".


 Laut Wikipedia ist der Name "Steyr". Bei manchen Statutarstädten wie St.
Pölten und Wiener Neustadt gibt es nicht einmal (mehr) die Unterscheidung
mit "-Land/Umgebung", d.h. ohne die Präzisierung mit "Bezirk" oder anderen
Zusatzinformationen bzw. Abweichung vom offiziellen Namen sind die nicht
einmal unterscheidbar.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] name:suffix & name:prefix (de)

[Robert Kaiser]

PPete schrieb:

z.b. Stadt Steyr: https://www.openstreetmap.org/relation/90143 
(BKZ=402, GKZ=40201). derzeit ist nur die BKZ aber im Tag "ref:at:gkz" 
erfasst.


IMHO ist diese Relation sowieso falsch (und ev. alle Statutarstädte). 
Der Bezirk heißt "Steyr-Stadt", die Gemeinde heißt "Steyr". Das sollten 
IMHO zwei relationen mit zwei verschiedenen Namen und admin_levels sein, 
aber mit gleichen members.


KaiRo


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-vi] MapRoulette challenges in Vietnam - find road network problems

[Vũ Phạm Minh Tuấn]

Hi Andrew,

Thanks for the tools. They make editing the map much more easily and
conveniently. I’ll def have a look at those tools later today to see how I
can do.

Just a quick question: what do the Apple map team think about the map
coverage of Vietnam:l? what are the challenges and shortcomings? And what
should be done to make Apple maps in Vietnam more useful to the public?

Tuan,

Openstreetmap ID: TuanIfan

On Fri, 8 Nov 2019 at 12:29 pm, Andrew Wiseman via Talk-vi <
talk-vi@openstreetmap.org> wrote:

> Hello OSM Vietnam,
>
> Xem bên dưới để dịch tiếng Việt.
>
> This is Andrew again from the Apple Maps team. We recently used our Atlas
> data analysis tool (https://github.com/osmlab/atlas) to look at a few
> types of potential issues related to roads and routing, such as roads that
> have overly sharp angles, roads that cross but don't connect, routing
> problems, turn restrictions, places where navigation is impossible due to
> missing connections or potentially incorrect one-way roads, and other
> similar issues.
>
> I've posted the results of those checks on MapRoulette, a tool that lets
> you go through potential issues one by one and either correct them or
> indicate they are not a problem. I wanted to let you know they are
> available in case others wanted to try fixing some of them — I also plan to
> go through some of them myself.
>
> In MapRoulette you can either pick a random task to fix or click on a
> specific one. If you want to do tasks around a certain location, such
> as somewhere you are familiar with, you can click on one from the map view,
> and then click Next task: Nearby when you finish it.
>
> Here they are:
>
>
>- Vietnam Sharp Angle Roads: https://maproulette.org/challenge/7986
>- Vietnam Floating Ways & Disconnected Roads:
>https://maproulette.org/challenge/9830
>- Vietnam Sink Islands & Impossible Routing:
>https://maproulette.org/challenge/9826
>- Vietnam Overlapping Lines: https://maproulette.org/challenge/9827
>- Vietnam Invalid Turn Restrictions:
>https://maproulette.org/challenge/9836
>- Vietnam Malformed Roundabouts: https://maproulette.org/challenge/9834
>- Vietnam Road Link Check: https://maproulette.org/challenge/9832
>
> Here is the message auto-translated into Vietnamese:
>
> ///
>
> Xin chào OSM Việt Nam,
>
> Đây là Andrew một lần nữa từ nhóm Apple Maps. Gần đây, chúng tôi đã sử
> dụng công cụ phân tích dữ liệu Atlas của mình (
> https://github.com/osmlab/atlas) để xem xét một số loại vấn đề tiềm ẩn
> liên quan đến đường và định tuyến, chẳng hạn như đường có góc quá nhọn,
> đường giao nhau nhưng không Không kết nối, sự cố định tuyến, hạn chế rẽ,
> những nơi không thể điều hướng do thiếu kết nối hoặc đường một chiều có thể
> không chính xác và các vấn đề tương tự khác.
>
> Tôi đã đăng kết quả của những kiểm tra đó trên MapRoulette, một công cụ
> cho phép bạn lần lượt khắc phục các sự cố tiềm ẩn và sửa chúng hoặc cho
> biết chúng không phải là vấn đề. Tôi muốn cho bạn biết rằng chúng có sẵn
> trong trường hợp những người khác muốn thử sửa một số trong số họ - tôi
> cũng có kế hoạch tự mình trải qua một số trong số họ.
>
> Trong MapRoulette, bạn có thể chọn một tác vụ ngẫu nhiên để sửa hoặc nhấp
> vào một tác vụ cụ thể. Nếu bạn muốn thực hiện các tác vụ xung quanh một vị
> trí nhất định, chẳng hạn như nơi nào đó bạn quen thuộc, bạn có thể nhấp vào
> một từ chế độ xem bản đồ, sau đó nhấp vào Tác vụ tiếp theo: Gần đó khi bạn
> hoàn thành nó.
>
> Họ đây rồi:
>
> Đường góc nhọn Việt Nam: https://maproulette.org/challenge/7986
> Việt Nam Cách nổi & Đường bị ngắt kết nối:
> https://maproulette.org/challenge/9830
> Quần đảo chìm Việt Nam & định tuyến bất khả thi:
> https://maproulette.org/challenge/9826
> Đường chồng chéo Việt Nam: https://maproulette.org/challenge/9827
> Giới hạn rẽ không hợp lệ tại Việt Nam:
> https://maproulette.org/challenge/9836
> Vòng xuyến dị dạng Việt Nam: https://maproulette.org/challenge/9834
> Kiểm tra liên kết đường bộ Việt Nam:
> https://maproulette.org/challenge/9832
>
>
> Thanks!
>
> Andrew
>
>
>
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 |
> andrew_wise...@apple.com
>
> ___
> Talk-vi mailing list
> Talk-vi@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-vi
>
-- 

*Tuan* • Vu, Pham Minh Tuan

Springvale, VIC 3171, Australia • +61 412 401 380

vutuan...@gmail.com • *FB  *•* LinkedIn
 *•* OpenStreetMap
*
___
Talk-vi mailing list
Talk-vi@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-vi

Re: [talk-au] local traffic only

[Andrew Harvey]

On Sat, 9 Nov 2019 at 02:24, Mateusz Konieczny 
wrote:

> Why it would be irrelevant?
>

> access tag family is for legal access (with some space for officially
> discouraged access),
> access=destination is for "transit is illegal", not "local residents
> dislike transit traffic".
>
> OSM is not a place to add a nonexisting ban on transit traffic
>

Yeah realised this later, see my other post in this thread at
https://lists.openstreetmap.org/pipermail/talk-au/2019-November/013188.html,
which I suggested motor_vehicle:advisory=destination to tag a suggested or
advised but maybe not legally enforceable destination only restriction.

On Sat, 9 Nov 2019 at 01:55, Mateusz Konieczny 
wrote:

> Is it "local traffic only" as in "resident only" or "no transit"?
>
> Is permission required to enter this area?
>
> AFAIK there is no tagging scheme for distinguishing "only with permission
> of
> homeowner" and "available to all residents of closed community".
>

It just means this road is indented to be used if you're traveling to
somewhere along this road, but not if you're just driving through as a
shortcut.

It's still public land, not private property.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] Violazione Licenza - FoodChain-Lab

[Martin Koppenhoefer]

sent from a phone

> On 7. Nov 2019, at 15:51, Marco Minghini  wrote:
> 
> Si potrebbe cominciare aprendo una issue nella repo del progetto: 
> https://github.com/SiLeBAT/BfROpenLab/issues
> o commentando questa issue, che forse si riferisce proprio alla mancata 
> attribuzione (ma non c'è descrizione per capirlo): 
> https://github.com/SiLeBAT/BfROpenLab/issues/459


l’ho fatto. Vediamo se reagiscono...

Ciao Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Addressing SIG

[stevea]

Nicely answered, I appreciate that!
SteveA

> On Nov 8, 2019, at 4:02 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 9. Nov 2019, at 00:48, stevea  wrote:
>> 
>> I wouldn't say "all" addresses, as Facebook isn't "all" of us.  
> 
> 
> of course, I apologize if this came along like a campaign just with facebook, 
> it was just an example that facebook was mentioned, because they are our 
> biggest data user (Apple as well, but they don’t use OpenStreetMap data in 
> their most  important markets, AFAIK). Collecting _all_ addresses is a 
> project goal (it’s part of mapping the whole world), and was not referring 
> specifically to facebook, nor had I imagined a campaign just with facebook 
> (if they are interested in this anyway), making such an announcement could be 
> an occasion for the media in general for featuring OpenStreetMap. The people 
> vs. Big Tech etc.
> 
> Cheers Martin


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Addressing SIG

[Martin Koppenhoefer]

sent from a phone

> On 9. Nov 2019, at 00:48, stevea  wrote:
> 
> I wouldn't say "all" addresses, as Facebook isn't "all" of us.  


of course, I apologize if this came along like a campaign just with facebook, 
it was just an example that facebook was mentioned, because they are our 
biggest data user (Apple as well, but they don’t use OpenStreetMap data in 
their most  important markets, AFAIK). Collecting _all_ addresses is a project 
goal (it’s part of mapping the whole world), and was not referring specifically 
to facebook, nor had I imagined a campaign just with facebook (if they are 
interested in this anyway), making such an announcement could be an occasion 
for the media in general for featuring OpenStreetMap. The people vs. Big Tech 
etc.

Cheers Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-at] name:suffix & name:prefix (de)

[PPete]

Wegen einer Note https://www.openstreetmap.org/note/1989028 eine 
dazugehörige Frage die man bei einem zukünftigen Konsens bei den 
Präfixen und entsprechendem Umtagging gleich mitberücksichtigen könnte 
ist jene nach der Gemeindekennzahl GKZ und der Bezirkskennzahl BKZ. 
Erstere ist bisher durch den Tag "ref:at:gkz" erfasst, zweitere finde 
ich gar keine. Die Bezirke sind derzeit mit mit dem GKZ getaggt, 
erhalten aber zumindest die richtige Nummer.


z.b. Bezirk Braunau: https://www.openstreetmap.org/relation/417294 (BKZ=404)

Etwas komplizierter wird die Sache bei Statutarstädten, die sowohl eine 
GKZ als auch BKZ haben:


z.b. Stadt Steyr: https://www.openstreetmap.org/relation/90143 (BKZ=402, 
GKZ=40201). derzeit ist nur die BKZ aber im Tag "ref:at:gkz" erfasst.


Was wären hier Vorschläge? Bleiben bei dem jetzigen einen Tag 
"ref:at:gkz" und einsetzen der richtigen Nummer je nach 
Verwaltungsebene? Wie aber dann anwenden bei Statutarstädten? Oder ein 
zusätzlicher Tag "ref:at:bkz" für Bezirke und für Statutatstädte 
verwendet man dann gleichzeitig beide Tags?


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] Addressing SIG

[stevea]

I wouldn't say "all" addresses, as Facebook isn't "all" of us.  Also, it's an 
ambition, a gleam in a collective eye, a vision, something ahead in the future 
as a goal.  There will be, rightly, many paths to get there, rather than a 
single one.  This is true of any major goal in OSM.

SteveA

> On Nov 8, 2019, at 3:44 PM, Martin Koppenhoefer  
> wrote:
> We could announce a campaign, “citizen mapping project collects all the 
> addresses in the world and provides them freely to everybody” or similar.


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Addressing SIG

[Martin Koppenhoefer]

sent from a phone

> On 8. Nov 2019, at 13:59, Simon Poole  wrote:
> 
> Just imagine that we increase the number of new OSM contributors by an
> order of magnitude, to ~2'000'000 per year, and just as magically we get
> them to make the single edit they typically make to be adding an
> address


imagine every facebook user would put their home address, or every business 
owner their business address. To make this happen, the procedure must be dead 
simple, and not require you understand an editor, or use a complex website with 
bells and whistles, but so overwhelming to my grand aunt that she will close 
the page as soon as she finds the button to do so.

We could announce a campaign, “citizen mapping project collects all the 
addresses in the world and provides them freely to everybody” or similar.

Cheers Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Addressing SIG

[marc marc]

Simon Poole:
>> how can the new contributor wishing to add an address find this tool?

> That doesn't make the slightest difference, because the only people
> adding addresses in any meaningful way are those 1% of contributors.

it's the problem of the egg and the chicken :
if effective tools were accessible to 2% 3% 10% of contributors,
then the speed would be multiplied by 2, 3 or 10

A more effective contribution would be to consider 3 types
of location/contributor:

- those where the opendata is of quality: we should talk about import

- those where the opendata exists but where the import has not been 
accepted and/or not yet done and/or new address exist: the "normal" 
contributor (99%) should be able to easily access the opendata in
an editor and validate in one click if it is correct. or correct
the position easily. osmose opendata-fork allow that but it'sn't
a editor that newbies find when surfing on osm.org.
and only a very few location are listed for addr.

- those where the opendata does not exist: a drop-down list
to avoid having to rewrite the street name is a minimum.
It also avoid typo and letter case.

Thinking about the time spent on the addresses I added,
I think I could have been much more efficient for both those
added by survey and those from opendata.
so by spending the same amount of time on it, I could have added
a lot more. And it would have been much more motivating to do it
often.

Regards,
Marc
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Élections au board de la Fondation OSM

[Christian Rogel]

> Le 8 nov. 2019 à 22:59, thevenon.jul...@free.fr a écrit :
> 
> Guillaume Rischard, Eugene Alvin Villar le nomm evoque quelque chose mais je 
> me rappelle pas de lien non plus
> Allan Mustard ca me dit rien

Rischard est membre du board et francophone.
E. Alvin Villar, philippin, est très actif aux Philippines, mais, excellent 
anglophone.
Allan Mustard est le seul ambassadeur qui cartographiait à ses heures perdues 
quand il représentait les E. U. au Turkménistan (capitale : Achgabad).
Maintenant à la retraite, il semble vouloir s’impliquer dans une action 
internationale.
J’avais suivi sa conf au SOtM de Bruxelles et il savait y ajouter de l’humour.

Christian R.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] OSMF-Mitgliederversammlung: Beschlussanträge | Aufruf zur Mitgliedschaft

[Frederik Ramm]

Hallo,

On 11/8/19 23:38, Michael Reichert wrote:
> Es gibt eine Reihe an Anträgen, über die abgestimmt werden soll
> (Nummerierung von mir).

Ja, das wird jetzt etwas verwirrend, weil die Nummerierung in dem
offiziellen Wahlzettel anders sein wird.

Der Punkt 4:

> 4. Feste Amtszeitbegrenzungen und -beschränkungen

wird nämlich aus drei Abstimmungen bestehen, grob umschrieben so:

4. Festlegung der Amtszeit auf 2 Perioden (1 Peride = Abstand zwischen
zwei Vorstandswahlen, also normal 1 Jahr), man kann beliebig oft zur
Wahl stehen

5. Einschränkung von 4. auf "man kann nur zur Wahl stehen, wenn man
innerhalb der letzten 8 Vorstandswahlen nicht schon dreimal gewählt
wurde" - praktisch also eine Amtszeitbeschränkung auf 6 Jahre, die durch
eine 2jährige Pause zurückgesetzt wird

6. weitere Einschränkung von 5 durch Streichung der "innerhalb der
letzten 8 Vorstandswahlen", d.h. eine harte Amtszeitbeschränkung auf 6 Jahre

Ferner wird es einen bisher nicht diskutierten Punkt 7 geben, das ist
eine kosmetische Änderung am §81 (ersetze "Annual General Meeting" durch
"General Meeting").

Die von Michael als Nr. 5 geführte Beitragsbefreiung ist dann Abstimmung
Nr. 8; für "associate members" ist das die einzige Abstimmung, an der
sie teilnehmen dürfen.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



signature.asc
Description: OpenPGP digital signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-GB] Poly Tunnels vs Greenhouses

[Mark Goodge]

On 08/11/2019 20:50, Philip Barnes wrote:

No problem with boats and greenhouses that don't move.

But these are probably seasonal and certainly shouldn't be mapped
from aerial imagery alone as they may have long gone. They certainly
need a recent survey.


I don't think polytunnels in open fields should be mapped, for this 
reason. They are seasonal and transient. They will be there for part of 
the year, and then removed after the growing season, and may not be used 
again on the same field the following year.


However, there are some permanent polytunnels that are, effectively, 
plastic greenhouses. Those can, and should, be mapped. But it needs 
local knowledge to map them. You can't do it from imagery.



It reminds me of the time an armchair mapper carefully traced a Maize
Maze that had existed for a short time in a field near me a couple of
years earlier.


I'm pleased to see that we do have the Hampton Court Maze mapped, though :-)

Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-at] OSMF-Mitgliederversammlung: Beschlussanträge | Aufruf zur Mitgliedschaft

[Michael Reichert]

Hallo,

der Termin für die Mitgliederversammlung steht fest und somit auch der
Termin, bis zu dem sich Neumitglieder angemeldet haben müssen, um
wahlberechtigt zu sein.

Stichtag Anmeldung Neumitglieder: 13. November 2019
Mitgliederversammlung: 14. Dezember 2019 16:00 UTC (17:00 MEZ)

Bestehende Mitglieder sollte dringend ihre Mitgliedschaft erneuern, um
wahlberechtigt zu sein.

Außerdem werden noch Kandidaten gesucht, da die Auswahl derzeit sehr
englischlastig ist. Deadline ist hierfür Sonntagmorgen 00:01 UTC, also
Sonntag, der 10. November 2019 01:01 MEZ.
Die Liste der Kandidaten findet ihr im Wiki
https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board#Candidates

Es gibt eine Reihe an Anträgen, über die abgestimmt werden soll
(Nummerierung von mir). Anträge 1 bis 4 sind Satzungsänderungen. Darüber
können *ausschließlich normale Mitglieder* abstimmen. Wenn ihr ein
assoziiertes Mitglied seid, müsst ihr euren Status ändern lassen. Da
nach britischem Recht jeder die Mitgliederliste einsehen darf, hat dann
jeder Zugriff auf Antrag auf euren Namen und eure Anschrift. Für
Satzungsänderungen ist eine Dreiviertelmehrheit erforderlich. Über
Antrag 5 dürfen alle Mitglieder abstimmen, die 50-Prozent-Mehrheit genügt.


1. Änderung des Zeitraums, in dem der OSMF-Vorstand einen
Mitgliedsantrag zurückweisen kann

Bislang kann der Vorstand laut § 15 der Satzung einen Mitgliedsantrag
binnen 7 Tagen zurückweisen. Diese Frist wird auf 30 Tage erhöht.


2. Änderung der Voraussetzungen für aktives Wahlrecht bei Vorstandswahlen

Künftig muss man mindestens 90 statt mindestens 30 Tage lang aktives
Mitglied gewesen sein, um wahlberechtigt zu sein. Außerdem darf man in
den 7 Tagen vor der Mitgliederversammlung keine Beitragsschulden gehabt
haben (das Erneuern einer erloschenen Mitgliedschaft in diesem Zeitraum
stellt die Wahlberechtigung nicht wieder her). Zudem legt der Antrag
fest, dass Tage volle Kalendertage in UTC sind und zur Bestimmung des
Kalendertags die Zeitzone UTC verwendet wird.


3. Mindestmitgliedschaft für Vorstände

Wer durch Wahl durch die Mitglieder oder durch Entscheidung des
Vorstands in den Vorstand aufgenommen wird, muss in den 180 Tagen vor
der Aufnahme Mitglied gewesen sein.


4. Feste Amtszeitbegrenzungen und -beschränkungen

Derzeit muss stets das älteste Drittel (gerundet) der Vorstände neu
gewählt werden (es zählt die Zeit seit der letzten Wahl des jeweiligen
Vorstandsmitglieds). Damit ist die Dauer der Amtszeit zu Beginn nicht
vorhersehbar. Künftig sollen alle Vorstandsposten zur Wahl stehen, deren
Inhaber mindestens 18 Monate seit ihr letzten Wahl im Amt sind. Zudem
soll niemand mehr als dreimal oder häufiger zum Vorstand (wieder)gewählt
worden sein.


5. Änderung des Mitgliederbeschlusses über die Beitragsbefreiung

Der Vorstand kann auf Antrag assoziierten Mitgliedern den Beitrag
erlassen, wenn sie sich diesen nicht leisten können oder es keine
geeignete Bezahlungsmöglichkeit gibt (z.B. Land ohne Paypal und horrende
Überweisungsgebühren nach Großbritannien). Künftig fallen diese zwei
Gründe weg. Stattdessen kann der Mitgliedsbeitrag erlassen werden, wenn
die Person durchgängig erhebliche Beiträge zu OSM, z.B. durch Mapping,
geleistet hat. Die Festlegung der Erheblichkeit erfolgt durch die
Membership Working Group gemeinsam mit dem Vorstand.

Viele Grüße

Michael


 Weitergeleitete Nachricht 
Betreff: [Talk-at] Erinnerung: OSMF-Mitgliedschaft erneuern bzw.
normales Mitglied werden
Datum: Fri, 6 Sep 2019 19:43:29 +0200
Von: Michael Reichert 
Antwort an: OpenStreetMap AT 
An: talk-at@openstreetmap.org



Hallo,

zwar hat der Vorstand der OpenStreetMap Foundation noch nicht den Termin
für die nächste Mitgliederversammlung bekanntgegeben, dennoch ist es
langsam an der Zeit, die jährliche Überweisung des Mitgliedsbeitrags an
die OpenStreetMap Foundation zu tätigen bzw. ihr beizutreten.

Beitritt als normales Mitglied:
https://join.osmfoundation.org/normal-membership/

Wenn ihr per Banküberweisung bezahlt, füllt bitte das folgende Formular
ausfüllen, da die Foundation nur die ersten 14 (?) Zeichen des
Verwendungszwecks von ihrer Bank erhält. Das erleichtert die Zuordnung
der Zahlungseingänge sehr
https://join.osmfoundation.org/alternative-payment-options/
Paypal-Zahlungen werden automatisch verbucht und erfordern keine
Handarbeit auf Seiten der Membership Working Group.

Die Mitgliedschaft in der OSMF sollte für jeden, der für OSM brennt,
eine Ehrensache sein. Die 15 Pfund (ca. 16,50 Euro) [1] pro Jahr sind
für die meisten Deutschen finanziell verkraftbar. Ich denke, dass die
Mitglieder der Foundation und somit Herren über die Rechte an den Daten
auch diejenigen sein sollten, die sie auch sammeln.

Die Mitgliederversammlung findet online statt, die Stimmen können in den
7 Tagen vor der Versammlung abgegeben werden. Schlechte
Englischkenntnisse sollten keine Hürde sein, es wird sicherlich genügend
deutschsprachige Zusammenfassungen/Empfehlungen geben.

Auf der kommenden 

Re: [OSM-talk] Changing OSM Username is easy | Re: Maintaining privacy as a casual mapper

[Martin Koppenhoefer]

sent from a phone

> On 8. Nov 2019, at 17:57, Paul Johnson  wrote:
> 
> Wow, that's cool.  I did not know that.  Well, made that change largely for 
> aesthetic reasons, might change it back later.


there’s also a third party service to keep track of these changes:

http://whosthat.osmz.ru/


Cheers Martin 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Élections au board de la Fondation OSM

[osm . sanspourriel]

Le 08/11/2019 à 22:58, thevenon.jul...@free.fr a écrit :


Pour Geofrabik j avoue ne pas avoir d a priori negatifs car j ai toujours eu l 
impression qu ils aidaient OSM


+1, si toutes les boîtes de l'écosystème se comportaient comme Geofabrik
ce serait bien. D'ailleurs je connais des boîtes françaises qui, si
elles posaient des candidats, ça ne me poserait pas de problème non
plus. Et d'autres par contre si.

Le 08/11/2019 à 22:58, thevenon.jul...@free.fr a écrit :

Guillaume Rischard, Eugene Alvin Villar le nomm evoque quelque chose mais je me 
rappelle pas de lien non plus


Pour Guillaume, HOT ou pas, côté DWG il fait son boulot. Même si j'ai
des réticences avec certains comportements de certain•e•s de HOT, là je
n'ai pas vu de soucis.

> Reste qu un representant de la communaute francaise se serait bien je
suis daccord

Un, une, des...

Mais il faut des candidat•e•s.

Si tu peux nous donner explicitement les personnes travaillant pour
MapBox, ça permettra de ne pas voter pour par erreur^^.

Jean-Yvon, non candidat.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Élections à l'OSMF - dates butoirs

[Jacques Lavignotte]

Le 08/11/2019 à 23:05, severin.menard via Talk-fr a écrit :

Par ailleurs, pour pouvoir voter il faut adhérer ou renouveler sa 
cotisation à l'OSMF


J'ai reçu un rappel.

[X] Payé


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Élections à l'OSMF - dates butoirs

[severin.menard via Talk-fr]

Bonsoir à tou-te-s,

La période de candidatures pour l'élection au bureau de la Fondation OSM se 
termine demain dimanche à 00:01 UTC (une heure de moins qu'en France) où il y a 
cette fois pas moins de 4 places vacantes sur 7, soit la majorité. Comme on 
peut le voir sur la page wiki qui y est dédiée[1], un gros contingent des 
États-Unis (4/8 à l’heure où j'écris) et des personnes de Singapour, des 
Philippines, d'Allemagne et du Luxembourg. Une seule femme et un seul 
francophone. Jusqu'au 13 novembre, il est possible de leur poser des questions.
Par ailleurs, pour pouvoir voter il faut adhérer ou renouveler sa cotisation à 
l'OSMF [2] avant le 13 également, soit 30 jours avant l’assemblée générale 
annuelle qui aura le lieu le 14 décembre. Toutes les infos dans ce message [3] 
transmis par Dorothea, qui gère les actes administratifs pour la Fondation.

Séverin

[1] https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board
[2] https://join.osmfoundation.org/
[3] 
https://lists.openstreetmap.org/pipermail/osmf-talk/2019-November/006343.html___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[EeBie]

I have a problem with a kind of exaggerated detailed mapping that makes 
the map difficult to read and use.
That is by giving fields and meadows their cadastral name by mapping 
them as place=locality and name=*.
You can find this in some parts of Wallonie as 
https://www.openstreetmap.org/#map=16/50.5175/5.4718
When using an OSM map, these fields look similar to villages. It 
happened that I couldn't find the name of a village between a lot of 
such names of  fields and meadows.
Unfortunately it is even more used in France: try to find the villages 
in this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
I hope that it will not end like this in Wallonie nor Flandres. I guess 
nobody is waiting to see all the cadastral names on an OSM maps. That is 
for dedicated cadastral maps.


Eebie



Op 5/11/19 om 09:26 schreef Lionel Giard:
@Marc These parking along street are indeed often not 
"amenity=parking" but probably more related to parking:lane tag 
 (tagged on the 
highway itself). Technically it is suggested to only map these kind of 
roadside parking with the parking:lane tag on the street.
But yes, it could be mapped with amenity=parking_space (without 
amenity=parking around it). and we could maybe use the 
"type=site"+"site=parking" relation to group them (as it is suggested 
for complex parking lot already) and allow people to understand that 
it is linked to the road (including the street line in the relation) 
and that it is roadside parking. But it is undocumented to use it that 
way. ^^


Le mar. 5 nov. 2019 à 08:42, Marc Gemis > a écrit :


Ik map soms ook parkeerplaatsen in een straat met enkel
amenity=parking_space, omdat er geen parking (in de betekenis van
parkeerterrein) is.
Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
wiki niet moet aangepast worden voor zulke gevallen ?

m.

On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
mailto:talk-be@openstreetmap.org>> wrote:
>
> Even terug naar de aanpassingen van Jakka en ook wat aansluitend
op onderstaande opmerking van Marc. En ook omdat ik in alle stilte
al wel wat werk van Jakka heb verbeterd (en dan bedoel ik
effectief: fouten corrigeren):
> - parkeerplaatsen: Jakka heeft daar de individuele
parkeerplaatsen gemapt; op zich OK. Maar waarom een aantal wel en
de andere niet? En vergeet dan niet de amenity=parking (toegevoegd
door Anakil): m.a.w. zorg er op z'n minst voor dan eerst de grote
lijnen in orde zijn, voeg pas daarna de details toe (wiki: Mapping
parking spaces is an addition, not a replacement, to mapping a
whole parking lot with amenity=parking.) Jakka had trouwens een
paar parkeerplaatsen foutief gemapt met amenity= parking. Daarna
heeft ene philippec binnen de amenity=parking van Anakil nog eens
2 keer een amenity =parking toegevoegd (zoals deze
https://www.openstreetmap.org/way/741861188)...? Waarom?
> - nog parkeerplaatsen: daar
(https://www.openstreetmap.org/way/731154048) 3 brede
parkeerplaatsen getekend terwijl het er 5 smalle zijn...
> - https://www.openstreetmap.org/way/118797990: lanes=2 -->
lanes=1, maar turn:lanes=none|merge_to_left vergeten te
verwijderen en ook cycleway:right=lane vergeten te verwijderen
> - het gebruik van traffic_calming=island (volgens wiki: A
structure separating at least two lanes of a highway from each
other for a short distance.). Dan lijkt dat daar (aan het stukje
Zemstbaan dat aansluit op de Brusselsesteenweg) heel veel verkeerd
gebruikt. Alleen al omdat die 'dingen' daar niks met traffic
calming te maken hebben, volgens mij.
> - een aantal fietspaden zijn apart bijgetekend (OK), maar waarom
niet het stukje langs de Zemstbaan van Zemstsesteenweg naar
Brusselsesteenweg? De oneway-tag lijkt mij ook een aantal keer te
ontbreken. En ook de bicycle=use_sidepath op de highways is niet
toegevoegd...
>
> Dat dingen in osm van jaren oud verbeterd, verfijnd of geüpdatet
moeten worden, is logisch. Maar dat recente veranderingen nog
hopen extra werk vragen omdat ze zeer onvolledig of ronduit fout
zijn, vind ik behoorlijk frustrerend. En met zo'n aanpassingen
wordt de databank er ook echt niet bruikbaarder op. Soit, 't is
ook mijn eigen schuld omdat ik er anderen zelden op aanspreek. En
Jakka, jij bent zeker de ergste nog niet, verre van.
>
> StijnRR
>
>
> Op maandag 4 november 2019 13:08:24 CET schreef Marc Gemis
mailto:marc.ge...@gmail.com>>:
>
>
> > Wel pleit ik er voor een zeker 'gebiedje' dan wel op een
gelijke maatstaf te behandelen. Als je het doet, zorg dan dat je
consequent bent, voor de wijk of als het even kan je kleine gemeente.
>
> er is ook zoiets als 

Re: [OSM-talk-fr] Élections au board de la Fondation OSM

[thevenon . julien]

- Mail original -
De: "JB" 
À: "Discussions sur OSM en français" 
Envoyé: Vendredi 8 Novembre 2019 13:32:59
Objet: [OSM-talk-fr] Élections au board de la Fondation OSM

> Hello,
> Je ne sais pas quelle proportion de personnes suivent la liste OSMF-talk, 
> mais les élections du board de la fondation OSM arrivent bientôt, et cette 
> année il y a 4 postes à pourvoir sur sept. Les candidatures sont attendues 
> dans deux jours au plus tard…
> Et il faut dire que je suis un peu triste du choix qu'il y a pour 
l'instant : 
> https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board#Candidates
> Combien de représentants de la communauté de contributeurs, plutôt que 
> d'intérêts financiers/entrepreneuriaux/politiques ou autres.Si vous ne savez 
> pas quoi faire d'une partie de votre temps libre ces deux prochaines années, 
> lancez-vous !

Merci JB, j ai beau etre abonne a OSMF-talk j avais rate ca, notamment le grand 
retour de Steve C aux affaires ( peut etre en lien avec sa demande de mettre l 
accent sur les adresses ? )
Pour ce qui est des candidats autant certains je vois bien le lien avec  Mapbox 
ou des entreprises: Steve C, Mikel Maron, Jinal Foflia, Rory Mc Cann Geofrabrik 
)
Pour HOT: Mikel Maron, Guillaume Rischard 
Pour Geofrabik j avoue ne pas avoir d a priori negatifs car j ai toujours eu l 
impression qu ils aidaient OSM
Par contre pour ce qui est de Clifford Snow j ai lu beaucoup de ces 
interventions mais je ne me rappelle pas de liens evidents ?
Guillaume Rischard, Eugene Alvin Villar le nomm evoque quelque chose mais je me 
rappelle pas de lien non plus
Allan Mustard ca me dit rien

Reste qu un representant de la communaute francaise se serait bien je suis 
daccord

Julien

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] The Range - looking for tagging consensus

[Devonshire]

Added a new Range store a couple of weeks ago as shop=houseware although 
shop=homeware would be fine as well. I think department store has some Grace 
Brothers style connotations regarding layout that The Range doesn't have at all.

Kevin

On Fri, Nov 8, 2019, at 1:00 PM, Silent Spike wrote:
> ...
> I'm actually leaning towards department store, but feel like OSM needs a new 
> tag to specify which departments a department store has so that we can 
> distinguish the huge ones from smaller ones like The Range or Laura Ashley 
> (another brand I've struggled with categorising).
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Poly Tunnels vs Greenhouses

[Philip Barnes]

No problem with boats and greenhouses that don't move. 

But these are probably seasonal and certainly shouldn't be mapped from aerial 
imagery alone as they may have long gone. They certainly need a recent survey.

It reminds me of the time an armchair mapper carefully traced a Maize Maze that 
had existed for a short time in a field near me a couple of years earlier. 

Phil (trigpoint)

On Friday, 8 November 2019, Mateusz Konieczny wrote:
> We have over 1800 building=tent and over 14 000 building=houseboat.
> 
> I feel comfortable with tagging them as building=greenhouse.
> 
> https://taginfo.openstreetmap.org/keys/building#values
> 
> disclaimer: not from UK, but have plenty of objects matching this description
> 
> 8 Nov 2019, 20:18 by bpran...@gmail.com:
> 
> > Hi Everyone
> >
> > Large areas of farmland are being covered with poly tunnels which are 
> > readily apparent from aerial imagery which are sometimes tagged as 
> > building=greenhouse. I've always hesitated from tagging them at all as they 
> > are not to me really buildings: they are more temporarily constructed,  
> > using cheap materials akin to a transparent tent or marquee and certainly 
> > without permanent foundations.
> > They could certainly be tagged as man_made= ( but what? ). No great 
> > preferences here from me but it would be good to have a UK tagging guideline
> >
> > Regards
> >
> > Brian
> >
> 
>

-- 
Sent from my Sailfish device
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Poly Tunnels vs Greenhouses

[Martin Wynne]

Large areas of farmland are being covered with poly tunnels which are
readily apparent from aerial imagery which are sometimes tagged as
building=greenhouse.


Hi Brian,

OS call them "glasshouse" rather than "greenhouse". But if they are 
plastic...


Martin.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-be] Mapillary tip bij lage zon

[Philippe Casteleyn]

Ik steek de zon weg achter een boomstam of gebladerte.
https://www.mapillary.com/app/?lat=50.980139499972225=4.50776209997=17=uploads=lVWEqR3yxBUOXE0leVlfYw=photo=OpenStreetMap=0.5023161344997851=0.3421429954822642=0
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-GB] Poly Tunnels vs Greenhouses

[Mateusz Konieczny]

We have over 1800 building=tent and over 14 000 building=houseboat.

I feel comfortable with tagging them as building=greenhouse.

https://taginfo.openstreetmap.org/keys/building#values

disclaimer: not from UK, but have plenty of objects matching this description

8 Nov 2019, 20:18 by bpran...@gmail.com:

> Hi Everyone
>
> Large areas of farmland are being covered with poly tunnels which are readily 
> apparent from aerial imagery which are sometimes tagged as 
> building=greenhouse. I've always hesitated from tagging them at all as they 
> are not to me really buildings: they are more temporarily constructed,  using 
> cheap materials akin to a transparent tent or marquee and certainly without 
> permanent foundations.
> They could certainly be tagged as man_made= ( but what? ). No great 
> preferences here from me but it would be good to have a UK tagging guideline
>
> Regards
>
> Brian
>

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-se] SCBs öppna geodata är CC-BY :(

[pangoSE]

Hej

Jag skulle vilja rita in polygonen för Sundsvall men den är CC-BY.

Hur gör vi?

Är det nån här som jobbar på SCB eller som är van att förklara för 
myndighetspersoner varför CC-BY inte funkar för oss? Alternativt är det 
nån som har en brevmall liggande jag kan skicka ifall ingen annan vill 
dra i detta?


https://www.scb.se/vara-tjanster/oppna-data/

Mvh

pangoSE



___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[Talk-GB] Poly Tunnels vs Greenhouses

[Brian Prangle]

Hi Everyone

Large areas of farmland are being covered with poly tunnels which are
readily apparent from aerial imagery which are sometimes tagged as
building=greenhouse. I've always hesitated from tagging them at all as they
are not to me really buildings: they are more temporarily constructed,
using cheap materials akin to a transparent tent or marquee and certainly
without permanent foundations.
They could certainly be tagged as man_made= ( but what? ). No great
preferences here from me but it would be good to have a UK tagging guideline

Regards

Brian
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-bd] Talk-bd Digest, Vol 36, Issue 4

[Aftabuzzaman Ullah]

 it? To maintain a
>> more transient conversion we requested to use English in changeset
>> comments
>> which was ignored altogether. We are strongly recommending that the
>> language of the communication should be in English for better
>> transparency.
>>
>> Today we are inviting you all to take part here in this discussion in
>> shaping the tagging policy of Bangladesh. We also have a close
>> communication about this issue with OSMF data working group and will also
>> follow up with them about it.
>>
>> On State of the Map Asia 2019 (SotM Asia 2019), the Bangladesh community
>> has made a decision that, in the true spirit of openness, everything
>> related to OSM in Bangladesh should be discussed in this mailing list.
>> Anything without prior discussion in the mailing list would be treated as
>> vandalism and strict actions would follow.
>>
>> We will request you all to invite other contributes and stakeholders to
>> subscribe to the mailing list and, for instant messaging, join our
>> Telegram
>> group <https://t.me/OpenStreetMapBD>.
>>
>>
>> Thank you!
>>
>> Regards
>>
>> Fazle Rabbi
>> On behalf of,
>> OpenStreetMap Bangladesh Foundation (OSMBDF)
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstreetmap.org/pipermail/talk-bd/attachments/20191107/23d7b226/attachment-0001.html
>> >
>>
>> --
>>
>> Message: 2
>> Date: Fri, 8 Nov 2019 00:31:46 +
>> From: Aftabuzzaman Ullah 
>> To: talk-bd@openstreetmap.org
>> Subject: Re: [Talk-bd] Discussion: Issues with name localization for
>> Bangladesh
>> Message-ID:
>> <
>> cangy_jygau7ymajslznjq+9cotycwu-scc9+n632pe6btcu...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello. Thanks for mail.
>> I respectfully disagree that we should use default/primary "name" tag in
>> English instead of Bangla. If i understand correctly, OSM policy/general
>> community guideline is that default/primary "name" tag should be in
>> whatever language is used locally (for Bangladesh it is Bangla). (
>> https://wiki.openstreetmap.org/wiki/Names#Localization
>> https://wiki.openstreetmap.org/wiki/Multilingual_names ) It is common
>> practice and it is followed by most countries e.g Japan, China, Russia,
>> all
>> arabic, cyrillic speaking countries etc countries.
>>
>> We should use English because some software doesn't render Bangla
>> correctly
>> isn't acceptable reason. It's may be true but By now the majority of
>> rendering systems/software can deal with unicode characters, supports
>> Bangla characters. Just because some software/site doesn't support Bangla
>> so we should use English, is like you have headache so cut the head like
>> solution. Like you said openstreetmap-carto was unable to render Bangla
>> but
>> it was fixed now. Same thing can be done with others, if an app doesn't
>> support Bangla, we need to submit bug report, reach out the developer for
>> adding Bangla font. Thats will be correct solution. It is not true that in
>> order to fix Bangla rendering problem, developer needs to learn Bangla.
>> They will just need to specify/include a Bangla font. we should need to
>> take necessary step to fix rendering problem in the apps/site that don't
>> render Bangla correctly e.g. submiting bug report (for exemple, to fix HOT
>> rendering problem we need to ask developer to add a Bangla font here
>> https://github.com/hotosm/HDM-CartoCSS/tree/master/fonts . i can see they
>> already added arabic, tamil, thai, lao etc font) I will be happy to help
>> with this & others.
>>
>> It is also not true that English names were deleted altogether, i can see
>> it just moved to "name:en" field (e.g "name = Road 1" became "name = সড়ক
>> ১"
>> & "name:en = Road 1"). If any software/site doesn't want to show local
>> language but english, they easily fallback to name:en.
>>
>> Per OSM policy/general community guideline, We should use default/primary
>> "name" tag in Bangla, any other name language in their code e.g name:en
>> for
>> English, name:it for Italian etc. That's should be our general
>> guideline. Yes, If for some reason someone cannot/don't do this, thats
>> fine, no one going to yell / block them. But in general, our broad nameing
>> guideline should be same as OSM general guideline, use default/primary
>> "name" tag in Bangla.
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstreetmap.org/pipermail/talk-bd/attachments/20191108/9ad51103/attachment-0001.html
>> >
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> Talk-bd mailing list
>> Talk-bd@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-bd
>>
>>
>> --
>>
>> End of Talk-bd Digest, Vol 36, Issue 4
>> **
>>
>
>
> --
>
> *Md. Solaiman Shaikh*
> *YouthMappers Dhaka College*
>
>
> ___
> Talk-bd mailing list
> Talk-bd@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-bd
>
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

Re: [Talk-vi] MapRoulette challenges in Vietnam - find road network problems

[Andrew Wiseman via Talk-vi]

:) Sure thing, glad it was helpful!

Andrew 

> On Nov 7, 2019, at 10:28 PM, Rihards  wrote:
> 
> On 08.11.19 03:28, Andrew Wiseman via Talk-vi wrote:
>> Hello OSM Vietnam,
>> 
>> Xem bên dưới để dịch tiếng Việt.
>> 
>> This is Andrew again from the Apple Maps team. We recently used our
>> Atlas data analysis tool (https://github.com/osmlab/atlas) to look at a
>> few types of potential issues related to roads and routing, such as
>> roads that have overly sharp angles, roads that cross but don't connect,
>> routing problems, turn restrictions, places where navigation is
>> impossible due to missing connections or potentially incorrect one-way
>> roads, and other similar issues.
>> 
>> I've posted the results of those checks on MapRoulette, a tool that lets
>> you go through potential issues one by one and either correct them or
>> indicate they are not a problem. I wanted to let you know they are
>> available in case others wanted to try fixing some of them — I also plan
>> to go through some of them myself.
> 
> Damn you Andrew, ended up tracing some extra data just from a couple of
> MR tasks :)
> But more seriously, this is a great initiative, thank you.
> 
>> In MapRoulette you can either pick a random task to fix or click on a
>> specific one. If you want to do tasks around a certain location, such
>> as somewhere you are familiar with, you can click on one from the map
>> view, and then click Next task: Nearby when you finish it.
>> 
>> Here they are: 
>> 
>>  * Vietnam Sharp Angle Roads: https://maproulette.org/challenge 
>> /7986
>>> >
>>  * Vietnam Floating Ways & Disconnected
>>Roads: https://maproulette.org/challenge/9830
>>  * Vietnam Sink Islands & Impossible
>>Routing: https://maproulette.org/challenge/9826
>>  * Vietnam Overlapping Lines: https://maproulette.org/challenge/9827
>>  * Vietnam Invalid Turn
>>Restrictions: https://maproulette.org/challenge/9836
>>  * Vietnam Malformed Roundabouts: https://maproulette.org/challenge/9834
>>  * Vietnam Road Link Check: https://maproulette.org/challenge/9832
>> 
>> Here is the message auto-translated into Vietnamese: 
>> 
>> ///
>> 
>> Xin chào OSM Việt Nam,
>> 
>> Đây là Andrew một lần nữa từ nhóm Apple Maps. Gần đây, chúng tôi đã sử
>> dụng công cụ phân tích dữ liệu Atlas của mình
>> (https://github.com/osmlab/atlas) để xem xét một số loại vấn đề tiềm ẩn
>> liên quan đến đường và định tuyến, chẳng hạn như đường có góc quá nhọn,
>> đường giao nhau nhưng không Không kết nối, sự cố định tuyến, hạn chế rẽ,
>> những nơi không thể điều hướng do thiếu kết nối hoặc đường một chiều có
>> thể không chính xác và các vấn đề tương tự khác.
>> 
>> Tôi đã đăng kết quả của những kiểm tra đó trên MapRoulette, một công cụ
>> cho phép bạn lần lượt khắc phục các sự cố tiềm ẩn và sửa chúng hoặc cho
>> biết chúng không phải là vấn đề. Tôi muốn cho bạn biết rằng chúng có sẵn
>> trong trường hợp những người khác muốn thử sửa một số trong số họ - tôi
>> cũng có kế hoạch tự mình trải qua một số trong số họ.
>> 
>> Trong MapRoulette, bạn có thể chọn một tác vụ ngẫu nhiên để sửa hoặc
>> nhấp vào một tác vụ cụ thể. Nếu bạn muốn thực hiện các tác vụ xung quanh
>> một vị trí nhất định, chẳng hạn như nơi nào đó bạn quen thuộc, bạn có
>> thể nhấp vào một từ chế độ xem bản đồ, sau đó nhấp vào Tác vụ tiếp theo:
>> Gần đó khi bạn hoàn thành nó.
>> 
>> Họ đây rồi:
>> 
>> Đường góc nhọn Việt Nam: https://maproulette.org/challenge/7986
>> Việt Nam Cách nổi & Đường bị ngắt kết nối:
>> https://maproulette.org/challenge/9830
>> Quần đảo chìm Việt Nam & định tuyến bất khả thi:
>> https://maproulette.org/challenge/9826
>> Đường chồng chéo Việt Nam: https://maproulette.org/challenge/9827
>> Giới hạn rẽ không hợp lệ tại Việt Nam:
>> https://maproulette.org/challenge/9836
>> Vòng xuyến dị dạng Việt Nam: https://maproulette.org/challenge/9834
>> Kiểm tra liên kết đường bộ Việt Nam: https://maproulette.org/challenge/9832
>> 
>> 
>> Thanks! 
>> 
>> Andrew
>> 
>> 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464
>> | andrew_wise...@apple.com  
>> >
> -- 
> Rihards
> 
> ___
> Talk-vi mailing list
> Talk-vi@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-vi 
> 
___
Talk-vi mailing list
Talk-vi@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-vi

Re: [OSM-talk] Changing OSM Username is easy | Re: Maintaining privacy as a casual mapper

[Paul Johnson]

On Mon, Nov 4, 2019 at 9:58 AM Rory McCann  wrote:

> On 03/11/2019 19:19, Blake Girardot wrote:
> > I am not happy about it and I could get my osm username changed
>  > ...
>  > If you have a username that is tied to a public or other used name of
>  > some sort, my advice is to ask the user name to be changed.
>
> Just for anyone who wants to do this, changing your OSM username is very
> easy, it's the in the “My Settings” page when you log in and click on
> the drop down in the top right, and is the “Display Name” field. You'll
> have to re-log into all apps. You don't have to ask anyone. It happens
> immediately.


 Wow, that's cool.  I did not know that.  Well, made that change largely
for aesthetic reasons, might change it back later.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-bd] Talk-bd Digest, Vol 36, Issue 4

[Solaiman Shaikh]

> Subject: Re: [Talk-bd] Discussion: Issues with name localization for
> Bangladesh
> Message-ID:
> <
> cangy_jygau7ymajslznjq+9cotycwu-scc9+n632pe6btcu...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello. Thanks for mail.
> I respectfully disagree that we should use default/primary "name" tag in
> English instead of Bangla. If i understand correctly, OSM policy/general
> community guideline is that default/primary "name" tag should be in
> whatever language is used locally (for Bangladesh it is Bangla). (
> https://wiki.openstreetmap.org/wiki/Names#Localization
> https://wiki.openstreetmap.org/wiki/Multilingual_names ) It is common
> practice and it is followed by most countries e.g Japan, China, Russia, all
> arabic, cyrillic speaking countries etc countries.
>
> We should use English because some software doesn't render Bangla correctly
> isn't acceptable reason. It's may be true but By now the majority of
> rendering systems/software can deal with unicode characters, supports
> Bangla characters. Just because some software/site doesn't support Bangla
> so we should use English, is like you have headache so cut the head like
> solution. Like you said openstreetmap-carto was unable to render Bangla but
> it was fixed now. Same thing can be done with others, if an app doesn't
> support Bangla, we need to submit bug report, reach out the developer for
> adding Bangla font. Thats will be correct solution. It is not true that in
> order to fix Bangla rendering problem, developer needs to learn Bangla.
> They will just need to specify/include a Bangla font. we should need to
> take necessary step to fix rendering problem in the apps/site that don't
> render Bangla correctly e.g. submiting bug report (for exemple, to fix HOT
> rendering problem we need to ask developer to add a Bangla font here
> https://github.com/hotosm/HDM-CartoCSS/tree/master/fonts . i can see they
> already added arabic, tamil, thai, lao etc font) I will be happy to help
> with this & others.
>
> It is also not true that English names were deleted altogether, i can see
> it just moved to "name:en" field (e.g "name = Road 1" became "name = সড়ক ১"
> & "name:en = Road 1"). If any software/site doesn't want to show local
> language but english, they easily fallback to name:en.
>
> Per OSM policy/general community guideline, We should use default/primary
> "name" tag in Bangla, any other name language in their code e.g name:en for
> English, name:it for Italian etc. That's should be our general
> guideline. Yes, If for some reason someone cannot/don't do this, thats
> fine, no one going to yell / block them. But in general, our broad nameing
> guideline should be same as OSM general guideline, use default/primary
> "name" tag in Bangla.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-bd/attachments/20191108/9ad51103/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-bd mailing list
> Talk-bd@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-bd
>
>
> --
>
> End of Talk-bd Digest, Vol 36, Issue 4
> **
>


-- 

*Md. Solaiman Shaikh*
*YouthMappers Dhaka College*
___
Talk-bd mailing list
Talk-bd@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bd

[Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[pangoSE]

Hej

Håller helt med Essin. Se min kommentar här 
https://www.openstreetmap.org/changeset/70936570


Jag förslår att vi sätter stop för import tills att vi sett att nån 
tagit åt sig den enorma uppgift att städa upp det som redan importerats.


Tills dess får vi leva med en "vit" karta i några områden.

Nån emot?

Mvh

pangoSE


___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [talk-au] local traffic only

[Mateusz Konieczny]

Why it would be irrelevant?

access tag family is for legal access (with some space for officially 
discouraged access),
access=destination is for "transit is illegal", not "local residents dislike 
transit traffic".

OSM is not a place to add a nonexisting ban on transit traffic

8 Nov 2019, 00:24 by andrew.harv...@gmail.com:

> The fact that they are not legally enforceable I think is irrelevant, after 
> all you can always tell your router to ignore access=destination if you like. 
> Rather this tagging accurately reflects the officially signposted 
> "recommendation".
>
> I agree they are targeted at vehicles, so that's why I'd recommend 
> motor_vehicle=destination rather than a blanket access=destination.
>
> On Fri, 8 Nov 2019 at 10:05, Ian Sergeant <> inas66+...@gmail.com 
> > > wrote:
>
>> I disagree with this one
>>
>> 1. I'm pretty sure they are not intended to have any effect to cyclists and 
>> pedestrians.  Who are generally encouraged to use these kinds of streets.  I 
>> wouldn't like to think we're putting access restrictions that are going to 
>> cause walking/cycling routing issues.
>>
>> 2. I'm also not sure these signs have any legal effect at all.  They aren't 
>> privately owned.  The signs are just street decorations.  I'd be inclined to 
>>
>> Ian.
>>
>>
>> On Thu, 7 Nov 2019 at 22:36, Nemanja Bračko <>> brack...@gmail.com 
>> >> > wrote:
>>
>>> I would agree with David on this.
>>> In that way you will avoid routing thru these streets unless your 
>>> destination is there.
>>>
>>> Sent from my phone
>>>
>>> On Thu, Nov 7, 2019, 12:33 David Wales <>>> daviewa...@disroot.org 
>>>  wrote:
>>>
 I would use access=destination

 On 7 November 2019 10:21:26 pm AEDT, Sebastian Spiess < 
 mapp...@consebt.de  > wrote:

> Hello List,
>
> how do you map a 'local traffic only' sign as this one? 
> https://www.mapillary.com/map/im/FkY8gmlGX2NmhUARyveMQw 
> 
>
> Following > https://wiki.openstreetmap.org/wiki/Key:access 
> >  states "...Note 
> that "access only for residents" is private..."
>
> Would this not break navigation in apps etc?
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au 
> 
>
 ___
  Talk-au mailing list
   Talk-au@openstreetmap.org 
   https://lists.openstreetmap.org/listinfo/talk-au 
 

>>> ___
>>>  Talk-au mailing list
>>>  >>> Talk-au@openstreetmap.org 
>>>  >>> https://lists.openstreetmap.org/listinfo/talk-au 
>>> 
>>>
>> ___
>>  Talk-au mailing list
>>  >> Talk-au@openstreetmap.org 
>>  >> https://lists.openstreetmap.org/listinfo/talk-au 
>> 
>>

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] local traffic only

[Mateusz Konieczny]

Is it "local traffic only" as in "resident only" or "no transit"?

Is permission required to enter this area?

AFAIK there is no tagging scheme for distinguishing "only with permission of
homeowner" and "available to all residents of closed community".

7 Nov 2019, 12:21 by mapp...@consebt.de :

> Hello List,
>
> how do you map a 'local traffic only' sign as this one? 
> https://www.mapillary.com/map/im/FkY8gmlGX2NmhUARyveMQw
>
> Following https://wiki.openstreetmap.org/wiki/Key:access states "...Note that 
> "access only for residents" is private..."
>
> Would this not break navigation in apps etc?
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] Name Suggestion Index

[Andy Robinson]

Could make them all fast food outlets? Bakewell tarts, Melton Mowbray pies, 
Cornish Pasties, and my favourite Cartmel sticky toffee puddings……

Chocolate might just be a cuisine?

 

Or is that just stirring the pot J

 

Cheers

Andy

 

From: SK53 [mailto:sk53@gmail.com] 
Sent: 08 November 2019 11:54
To: Peter Neale
Cc: Talk GB
Subject: Re: [Talk-GB] Name Suggestion Index

 

I wish there was a general rule which could be easily formulated: certainly it 
would be useful to make some useful rules-of-thumb more explicit. Below is a 
crude attempt at some considerations.

 

Broadly speaking the shop=confectionery, confectionery=chocolate is probably 
what works best. The issue is not specifically chocolate but, as DaveF pointed 
out earlier in the thread, all the other specialist sweet/cake shops selling 
local specialties such as fudge or toffee (or perhaps even Bakewell Puddings). 
There are probably lots of these special cases which is usually a good sign to 
stick with the more general tag. The other issue is that a tag has to work 
across the globe & the presence of significant numbers of South Asian sweet 
outlets in Britain also suggests sticking with the more general tag. 

 

Also confectionery is more widely used & has a much longer usage. So both sets 
of tags need to be looked at anyway if one is looking for chocolate shops. 

 

Lastly using a subtag (confectionery) always means one is adding information 
and not changing the meaning of an existing tag. shop=chocolate implies that 
shop=confectionery is a shop which sells sweet things except chocolate.

 

The archetypal shop tag where a more general value is better than a specific 
one is shop=beauty. Some will be pure nail bars, but many offer a bewildering 
array of treatments. The general tag allows one not to have to worry about all 
this detail unless one is specifically interested. 

 

For really posh chocolate shops (not Hotel Chocolat or Thorntons) one could add 
craft=chocolatier (but be careful, many years ago I remember being disappointed 
to discover that the Belgiian chocolate firm Godiva was owned by Campbells 
Soup).

 

Jerry

 

On Fri, 8 Nov 2019 at 11:01, Peter Neale via Talk-GB 
 wrote:

Hotel Chocolat could be tagged "shop=chocolate", I suppose, but chocolate is a 
sub-set of confectionery, so perhaps it should retain "shop=confectionery", so 
that users looking for a sugar high don't have to search for both 
shop=confectionery and shop=chocolate (and shop=boiled sweets and 
shop=fruit_gums and shop=seaside_rock and)?

 

Would that make it "shop=confectionery / confectionery=chocolate"?  (I am a bit 
new to the "rules" of tagging) 

 

Regards,

Peter

 

 

On Friday, 8 November 2019, 10:41:28 GMT, Silent Spike 
 wrote: 

 

 

I'm a (UK based) maintainer of the NSI repository and can push changes directly 
to it. I haven't been as active lately, but previously was working my way 
through UK brands.

 

"The Range" is one I've looked at previously but never figured out the most 
appropriate tagging which is why it still isn't in the index (for cases like 
that I'd like to consult the community for some consensus). I'll actually start 
a new thread to discuss this brand today.

 

"Hotel Chocolat" I believe is shop=confectionery in the index purely because it 
was the established tagging. If there is some community consensus it should be 
changed then that can be done (and this is why the index is so useful, because 
all existing locations matched to the brand via `brand:wikidata` could be 
automatically re-tagged with the preferred value).

 

If there are brands missing or issues with the current brand tagging I'd 
suggest either:

- Open an issue on the repository (or a pull request if you're comfortable with 
git and json) and all contributors will then see it

- If you don't have a github account and don't want one, just bring things up 
on this mailing list (feel free to email me directly too) and I'll see them and 
can either open an issue or push changes

 

 

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] The Range - looking for tagging consensus

[Silent Spike]

On Fri, Nov 8, 2019 at 12:08 PM SK53  wrote:

> So I'd favour the remaining candidates & I think housewares or homewares
> is probably a better fit.
>

The issue with houseware, if we're going by the wiki (
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dhouseware), is that it also
seems overly restrictive: "A shop that focuses on small items, like
cutlery, crockery, cookware and decorative items".

I'm actually leaning towards department store, but feel like OSM needs a
new tag to specify which departments a department store has so that we can
distinguish the huge ones from smaller ones like The Range or Laura Ashley
(another brand I've struggled with categorising).
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Addressing SIG

[Simon Poole]

Am 08.11.2019 um 13:19 schrieb marc marc:
> Hello,
>
> Simon Poole :
>> The issue with addresses is definitely not due to a lack of tools 
>> for OSM contributors. For example
>> https://regio-osm.de/hausnummerauswertung/anzeige_dynamisch.html?land=Schweiz=8.71423=47.05777=8=B
> lack of tools not only mean "no tool exist",
> it also means "tool not found for the contributor"
>
> how can the new contributor wishing to add an address find this tool?
> there's no way he'll find it. it's an advanced tool for the 1%
> of the most motivated contributors of for newbie at a mapping party.
> the other clicks on edit or note. it is osm.org's ergonomics it-self 
> and/or the greeting message during registration that must be improved
> so that the new contributor can find the tool best suited to his 
> contribution

That doesn't make the slightest difference, because the only people
adding addresses in any meaningful way are those 1% of contributors.

Just imagine that we increase the number of new OSM contributors by an
order of magnitude, to ~2'000'000 per year, and just as magically we get
them to make the single edit they typically make to be adding an
address, instead of whatever they actually wanted to do. Even then, in
the as good as it gets fantasy scenario, it would only be 20% of the
current run rate. And that in turn is probably an order of magnitude or
so too low for Steve (aka 50 years or so to "complete" world wide coverage).

Simon


> Regards,
> Marc
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] vespucci crashes since yesterday

[Simon Poole]

Due to a change in the data format provided by the Osmose API, if you
have Osmose enabled (the default), you will experience a crash when
trying to download an area since yesterday.

While I've built a new version that handles the issue (this is simply a
crash avoidance measure, but doesn't address the issue of unexpected
format changes in general, which naturally shouldn't happen), this will
take a while to be available.

The simple workaround for now, and if you are stuck on an old version of
the app, is to disable Osmose downloads. In older versions this can be
found in the "Advanced Preferences" in current versions in the layer
configuration in the layer dialog.

Sorry for the trouble

Simon




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] Élections au board de la Fondation OSM

[JB]

Hello,
Je ne sais pas quelle proportion de personnes suivent la liste 
OSMF-talk, mais les élections du board de la fondation OSM arrivent 
bientôt, et cette année il y a 4 postes à pourvoir sur sept. Les 
candidatures sont attendues dans deux jours au plus tard…
Et il faut dire que je suis un peu triste du choix qu'il y a pour 
l'instant : 
https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board#Candidates
Combien de représentants de la communauté de contributeurs, plutôt que 
d'intérêts financiers/entrepreneuriaux/politiques ou autres.
Si vous ne savez pas quoi faire d'une partie de votre temps libre ces 
deux prochaines années, lancez-vous !

JB.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Addressing SIG

[marc marc]

Hello,

Simon Poole :
> The issue with addresses is definitely not due to a lack of tools 
> for OSM contributors. For example
> https://regio-osm.de/hausnummerauswertung/anzeige_dynamisch.html?land=Schweiz=8.71423=47.05777=8=B

lack of tools not only mean "no tool exist",
it also means "tool not found for the contributor"

how can the new contributor wishing to add an address find this tool?
there's no way he'll find it. it's an advanced tool for the 1%
of the most motivated contributors of for newbie at a mapping party.
the other clicks on edit or note. it is osm.org's ergonomics it-self 
and/or the greeting message during registration that must be improved
so that the new contributor can find the tool best suited to his 
contribution

Regards,
Marc
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] The Range - looking for tagging consensus

[SK53]

Thanks for doing this: I had wondered who the fairy was!

As is often the case it might be easier to say which tags look out of place.

   - Department store should be reserved for what are classically called
   department stores and larger shops of the M type, not for a shop with a
   number of different departments (think Woolies before it closed and Wilkos
   now). These latter I would characterise as variety stores (because that's
   how Woolies was described in the trade press). Clothes have always been a
   major category for department stores & the absence of a broad clothing
   offering is, I think, a straight disqualification. (Aside: this is a good
   example of where some over-generalisation of a tag meaning actually
   devalues the overall value of the tag)


   - DIY looks wrong too. Some of the items in their DIY section just look
   like house wares to me (fans, dehumidifier etc), and many ranges are
   smaller than one would find in a small neighbourhood hardware shop.


   - Furniture Garden Centre & Interior Decoration, whilst all categories
   stocked at The Range are too restrictive in meaning.

So I'd favour the remaining candidates & I think housewares or homewares is
probably a better fit.

Jerry

On Fri, 8 Nov 2019 at 10:50, Silent Spike  wrote:

> This brand was brought up in the name suggestion index thread as one that
> doesn't currently have an entry due to it being tricky to determine the
> best tagging.
>
> I'm a UK based maintainer of the project and would like to get it added,
> but am not comfortable making a tagging judgement call alone without
> consulting the UK community.
>
> It looks like currently there are:
>
>- 21 shop=department_store
>- 18 shop=doityourself
>- 15 shop=variety_store
>- 14 shop=houseware
>- 6 shop=furniture
>- 5 shop=interior_decoration
>- 3 shop=garden_centre
>
>
> Probably a few others too. Personally I'd rule out `variety_store` as per
> the wiki "a variety store or price-point retailer is a retail shop that
> sells inexpensive items" (think Poundland).
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Name Suggestion Index

[SK53]

I wish there was a general rule which could be easily formulated: certainly
it would be useful to make some useful rules-of-thumb more explicit. Below
is a crude attempt at some considerations.

Broadly speaking the shop=confectionery, confectionery=chocolate is
probably what works best. The issue is not specifically chocolate but, as
DaveF pointed out earlier in the thread, all the other specialist
sweet/cake shops selling local specialties such as fudge or toffee (or
perhaps even Bakewell Puddings). There are probably lots of these special
cases which is usually a good sign to stick with the more general tag. The
other issue is that a tag has to work across the globe & the presence of
significant numbers of South Asian sweet outlets in Britain also suggests
sticking with the more general tag.

Also confectionery is more widely used & has a much longer usage. So both
sets of tags need to be looked at anyway if one is looking for chocolate
shops.

Lastly using a subtag (confectionery) always means one is adding
information and not changing the meaning of an existing tag. shop=chocolate
implies that shop=confectionery is a shop which sells sweet things except
chocolate.

The archetypal shop tag where a more general value is better than a
specific one is shop=beauty. Some will be pure nail bars, but many offer a
bewildering array of treatments. The general tag allows one not to have to
worry about all this detail unless one is specifically interested.

For really posh chocolate shops (not Hotel Chocolat or Thorntons) one could
add craft=chocolatier (but be careful, many years ago I remember being
disappointed to discover that the Belgiian chocolate firm Godiva was owned
by Campbells Soup).

Jerry

On Fri, 8 Nov 2019 at 11:01, Peter Neale via Talk-GB <
talk-gb@openstreetmap.org> wrote:

> Hotel Chocolat could be tagged "shop=chocolate", I suppose, but chocolate
> is a sub-set of confectionery, so perhaps it should retain
> "shop=confectionery", so that users looking for a sugar high don't have to
> search for both shop=confectionery and shop=chocolate (and shop=boiled
> sweets and shop=fruit_gums and shop=seaside_rock and)?
>
> Would that make it "shop=confectionery / confectionery=chocolate"?  (I am
> a bit new to the "rules" of tagging)
>
> Regards,
> Peter
>
>
> On Friday, 8 November 2019, 10:41:28 GMT, Silent Spike <
> silentspike...@gmail.com> wrote:
>
>
> I'm a (UK based) maintainer of the NSI repository and can push changes
> directly to it. I haven't been as active lately, but previously was working
> my way through UK brands.
>
> "The Range" is one I've looked at previously but never figured out the
> most appropriate tagging which is why it still isn't in the index (for
> cases like that I'd like to consult the community for some consensus). I'll
> actually start a new thread to discuss this brand today.
>
> "Hotel Chocolat" I believe is shop=confectionery in the index purely
> because it was the established tagging. If there is some community
> consensus it should be changed then that can be done (and this is why the
> index is so useful, because all existing locations matched to the brand via
> `brand:wikidata` could be automatically re-tagged with the preferred value).
>
> If there are brands missing or issues with the current brand tagging I'd
> suggest either:
> - Open an issue on the repository (or a pull request if you're comfortable
> with git and json) and all contributors will then see it
> - If you don't have a github account and don't want one, just bring things
> up on this mailing list (feel free to email me directly too) and I'll see
> them and can either open an issue or push changes
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-ja] Google Mapsと一致するPOI

[241 bizen]

はじめまして。
岡山のbizen241といいます。

Google Mapsからの転記と思われる編集への対応に困り、投稿しました。

---

先日OSMChaを見てみると、多数の店舗のノードが追加されていました。
https://www.openstreetmap.org/changeset/76681052

そのうちの複数のPOIが既存のものと重複していたため、前後の編集も含めて確認しました。
https://www.openstreetmap.org/changeset/76572954

編集が広範囲に渡っていることなどから不思議に思い、Google Mapsと照合しました。
すると、nameタグの内容の多くがGoogle Mapsの表記の全部または一部と一致していました。

特に次のノードについては、臨港が臨海になっているものの、それ以外は一致しています。
そして、この機関車の正しい形式はDB102のようです。
https://www.openstreetmap.org/node/6944411394
https://goo.gl/maps/oEPykV9iPBaReund9
https://www.okarin.co.jp/museum/photo.html

ほかにも、複合商業施設内の店舗のうち、Google Mapsで表示される店舗のみが追加されていました。

以上のことから、これらの編集はGoogle Mapsをもとにしている可能性があると思いました。
しかし、各変更セットにはsourceタグの記載がありません。
すでに変更セットへコメントで質問してしまいましたが、こちらの勘違いの可能性もあると思っています。
https://www.openstreetmap.org/changeset/76738836

これはGoogle Mapsからの転記と判断すべきでしょうか?
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-GB] Name Suggestion Index

[Peter Neale via Talk-GB]

Hotel Chocolat could be tagged "shop=chocolate", I suppose, but chocolate is a 
sub-set of confectionery, so perhaps it should retain "shop=confectionery", so 
that users looking for a sugar high don't have to search for both 
shop=confectionery and shop=chocolate (and shop=boiled sweets and 
shop=fruit_gums and shop=seaside_rock and)?
Would that make it "shop=confectionery / confectionery=chocolate"?  (I am a bit 
new to the "rules" of tagging) 
Regards,Peter 

On Friday, 8 November 2019, 10:41:28 GMT, Silent Spike 
 wrote:  
 
 I'm a(UK based) maintainer of the NSI repository and can push changes directly 
to it. I haven't been as active lately, but previously was working my way 
through UK brands.
"The Range" is one I've looked at previously but never figured out the most 
appropriate tagging which is why it still isn't in the index (for cases like 
that I'd like to consult the community for some consensus). I'll actually start 
a new thread to discuss this brand today.
"Hotel Chocolat" I believe is shop=confectionery in the index purely because it 
was the established tagging. If there is some community consensus it should be 
changed then that can be done (and this is why the index is so useful, because 
all existing locations matched to the brand via `brand:wikidata` could be 
automatically re-tagged with the preferred value).

If there are brands missing or issues with the current brand tagging I'd 
suggest either:- Open an issue on the repository (or a pull request if you're 
comfortable with git and json) and all contributors will then see it- If you 
don't have a github account and don't want one, just bring things up on this 
mailing list (feel free to email me directly too) and I'll see them and can 
either open an issue or push changes

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-au] Melbourne Missing Maps/OSM rep?

[Simon Poole]

Pro tip (out of experience*): check that the MSF rep actually knows
about OSM and what missing maps is.

Simon

* aka having to listen somebody going on about google maps at such an event.

Am 08.11.2019 um 04:41 schrieb Michael Collinson:
>
> Hi Vitva,
>
> If you don't get any other volunteers, I'll be happy to come along and
> answer questions/talk ad hoc but not prepare a talk. I'm not familiar
> with Missing Maps but have previously served on the OSM Foundation board.
>
> Cheers,
>
> Mike
>
> Michael Collinson
>
> On 2019-11-08 13:13, Vilppola, Ritva wrote:
>>
>> Hi Team,
>>
>>  
>>
>> WSP is holding a Missing Maps Mapathon next Thursday 5-8pm and we’re
>> just wondering if there is anyone in Melbourne available to rep for
>> OSM/Missing Maps for the evening?
>>
>>  
>>
>> We will also be getting in a speaker from MSF to attend so it would
>> be great to have someone from OSM promote what it’s all about and
>> ways people can get involved locally!
>>
>>  
>>
>> Cheers,
>>
>>  
>>
>> *Ritva* *Vilppola*
>> Sustainability Consultant
>>
>>
>> 
>>
>> T: +7 3535 1518
>>
>> ritva.vilpp...@wsp.com
>>
>> WSP Australia Pty Limited
>> 900 Ann Street, Level 12
>> Fortitude Valley
>> 4006  Australia
>>
>> *wsp.com *
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>  
>>
>>  
>>
>>
>> 
>>
>>
>> NOTICE: This communication and any attachments ("this message") may
>> contain information which is privileged, confidential, proprietary or
>> otherwise subject to restricted disclosure under applicable law. This
>> message is for the sole use of the intended recipient(s). Any
>> unauthorized use, disclosure, viewing, copying, alteration,
>> dissemination or distribution of, or reliance on, this message is
>> strictly prohibited. If you have received this message in error, or
>> you are not an authorized or intended recipient, please notify the
>> sender immediately by replying to this message, delete this message
>> and all copies from your e-mail system and destroy any printed copies.
>>
>>
>>
>> -LAEmHhHzdJzBlTWfa4Hgs7pbKl
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


signature.asc
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] Name Suggestion Index

[Silent Spike]

I'm a (UK based) maintainer of the NSI repository and can push changes
directly to it. I haven't been as active lately, but previously was working
my way through UK brands.

"The Range" is one I've looked at previously but never figured out the most
appropriate tagging which is why it still isn't in the index (for cases
like that I'd like to consult the community for some consensus). I'll
actually start a new thread to discuss this brand today.

"Hotel Chocolat" I believe is shop=confectionery in the index purely
because it was the established tagging. If there is some community
consensus it should be changed then that can be done (and this is why the
index is so useful, because all existing locations matched to the brand via
`brand:wikidata` could be automatically re-tagged with the preferred value).

If there are brands missing or issues with the current brand tagging I'd
suggest either:
- Open an issue on the repository (or a pull request if you're comfortable
with git and json) and all contributors will then see it
- If you don't have a github account and don't want one, just bring things
up on this mailing list (feel free to email me directly too) and I'll see
them and can either open an issue or push changes
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-au] local traffic only

[Ian Sergeant]

I agree the meaning of "discouraged" is what we need here.  But motor
vehicles are only discouraged if they aren't local traffic.  Otherwise they
are perfectly fine.

So, I think the motor_vehicle:advisory=destination covers these two
concepts, and is a better representation.

Ian.

On Fri, 8 Nov 2019 at 18:58, Benjamin Ceravolo 
wrote:

> I feel, as though discourage or discouraged is already an advisory term
> (you can't advise a recommendation if advise is a synonym of recommend).
>
> So I would think "motor_vehicle=discouraged" would be most appropriate.
>
> Just my thoughts.
>
> Ben
>
> On Fri, 8 Nov 2019 at 18:12, Luke Stewart 
> wrote:
>
>> Perhaps "motor_vehicle=discouraged"?
>>
>> From the wiki:
>> A legal right of way exists (see yes
>> ) but usage is
>> officially discouraged (e.g., HGVs on narrow but passable lanes). Only if
>> marked by a traffic sign (subjective otherwise).
>>
>> Although that may be getting too far away from the meaning of the sign,
>> but the original intention is to discourage through and non-local traffic
>>
>> On Fri, 8 Nov 2019 at 15:31, Andrew Harvey 
>> wrote:
>>
>>> I guess https://wiki.openstreetmap.org/wiki/Key:access does say "Access
>>> values describe legal permissions/restrictions. What happens on the ground
>>> may be different: for instance, many footpaths are used as de facto bike
>>> paths, without a legal right to do so. (Various 'greyzone' tags have been
>>> proposed to deal with such situations, but this is controversial and is not
>>> described here.)"
>>>
>>> Similar to existing "maxspeed:advisory"
>>> https://wiki.openstreetmap.org/wiki/Key:maxspeed:advisory perhaps if
>>> these aren't legal restrictions but still signposted on the ground we could
>>> use "motor_vehicle:advisory=destination". Does that work better?
>>>
>>> On Fri, 8 Nov 2019 at 13:04, Luke Stewart 
>>> wrote:
>>>
 As far as I have read, these signs are not enforceable by councils, nor
 do they appear in the NSW (or Australian) Road Rules. So unless the road
 itself is on private property and this sign is present, the access would
 still be public and it has the same meaning as discouraging the use of the
 street in favour of main roads.
 ___
 Talk-au mailing list
 Talk-au@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-au

>>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Addressing SIG

[Simon Poole]

Just as a further data point for the discussion: we are currently adding
roughly 10'000'000 addresses per year relatively constant since 2013,
with some exceptions due to imports (mainly NL in 2014 I believe).




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] Mapillary tip bij regen

[Marc Gemis]

On Thu, Nov 7, 2019 at 9:58 AM Jo  wrote:
>
> Why would you press against the camera?

To clean the lens. Even gently wiping over it would work against the
motors of the gimbal I think. It seems that the one I have can cope
with the duration of my walks.

To be honest, I think that the pictures I made are good enough to see
plenty of things that can be mapped. The parking places discussed
earlier, a bread vending machine etc, are still visible and can be
mapped. When I cannot read a label anymore, yes, then the picture is
worthless.
The pictures might be washed out here and there, but hey, I can live
with that. I can start mapping now and do not have to wait to get back
there when it's dry. For me, Mapillary is a source to map, not a
beauty contest for taking nice pictures. And furthermore, their object
recognition algorithms should be able to cope with raindrops,
otherwise, they will be useless in many real-world situations.

So I will keep taking pictures with light rain.

m.

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [talk-au] New imageries in AU

[Bob Cameron]

I don't know how useful/relevant this will be, but I am about 3 weeks 
from starting an upload of around 1.3TB Mapillary layer dashcam images. 
(4K size, at around 2FPS road speed) These are mainly sealed country 
roads (not a lot of urban data) around the continent.


Where a town/village is small enough I usually try to cover most of it. 
(eg Mendooran NSW - already available) Some major-ish dirt roads also 
covered (like the west end of Gibb River Rd and Norseman-Hyden Rd WA. 
The latter already available)


Cheers Bob

On 8/11/19 1:55 am, Nemanja Bracko (E-Search) via Talk-au wrote:


Hi all,

Do we have any possibility to be informed once there is a new imagery 
published by other providers (Maxar, Esri, Mapbox, etc.)?


We are trying to develop the process which will involve constant 
update of AU map, but we are not sure how to focus to areas which 
might have most recent imagery?


Thank you in advance,

Nemanja


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au