Re: [Talk-us] Washington DC place node cleanup

[Minh Nguyen]

Vào lúc 03:01 2020-12-04, Frederik Ramm đã viết:

Hi,

when reverting an edit this morning I noticed that the node for
Washington (https://www.openstreetmap.org/node/158368533) has myriad
name:xx tags, many of which seem to be some variant of "Washington D.C."
(with or without commas or dots), whereas the "local" name seems to be
just Washington, without the D.C.

As a native speaker of German I can assure you that we don't call the US
capital "Washington D.C." as the name:de tag claims; I would assume that
it is similar for most other languages. The German-language OSM map at
https://www.openstreetmap.de/karte.html?zoom=10=38.70174=-76.93764
has a mechanism where it displays the German name and then, if the local
name is different, the local name below; since the German name
"Washington D.C." and the local name "Washington" are different, this
leads to a somewhat funny display (whereas the logic works ok for other
US cities).

I could of course fix the German name but I think that it might need a
more thorough review and I don't feel competent for that.

Two name tags (and this is checking only those that use Roman letters)
look like they might be entirely wrong and refer to the District of
Columbia only:

name:lfn=Distrito de Columbia
name:mi=Takiwā o Columbia


Most of these localized names were added in changeset 76520412 [1] based 
on labels on the associated Wikidata item. [2] So this time it was not a 
case of promoting a particular minority language. In fact, I don't think 
much attention was paid to the names being added, or perhaps the Tajik 
name would've remained to the effect of "Washington District of 
Columbia" instead of being changed to "Washington (city)".


This same changeset changed the name of the District of Columbia 
relation to "Washington, D.C." in many languages, including English. [3] 
This results in Nominatim returning results like "Washington, D.C., 
Washington, D.C." I think it was inappropriate to rename the district 
this way. I think it was another oversight on the part of the 
changeset's author, because Wikidata has a distinct entity for the 
district. [4]


[1] https://www.openstreetmap.org/changeset/76520412
[2] https://www.wikidata.org/entity/Q61
[3] https://www.openstreetmap.org/relation/162069
[4] https://www.wikidata.org/wiki/Q3551781


Then again, I've heard people say "I was in D.C." and mean the city, so
perhaps that *is* a legitimate name for the city? Maybe someone in the
US community wants to have a look and do this right.

It is a bit of a conundrum in OSM - we usually say that local knowledge
tops everything, but then again for many of the languages there might
not even *be* a local Washington mapper in OSM ;)


As others have pointed out, a local would refer to the city as "D.C." 
even while acknowledging that the city's formal written name is 
"Washington" or "Washington, D.C." I think common sense would require us 
to relegate "D.C." to loc_name or short_name, just as a general-purpose, 
global map would only shorten San Francisco to the local shorthand 
"S.F." and Salt Lake City to "SLC" when space is at a premium.


Thanks in part to the D.C.-based Voice of America, I'm sure you could 
find a local to get the translated name of Washington, D.C., for many 
languages, but I'm not confident they would choose the same names as 
Wikidata.


For example, both VOA and the local Vietnamese media still generally 
call the city "Hoa Thịnh Đốn", a relic of the early 20th century when 
Vietnamese still borrowed Chinese characters for world-class cities. 
"Hoa Thịnh Đốn" is easy for a Vietnamese speaker to pronounce, but it 
only kind of sounds like "Washington" in the way that an eggcorn sounds 
like its original phrase. It's archaic and probably unknown to the 
younger generation in Vietnam. The Vietnamese government prefers the 
phonetic respelling "Oa-sinh-tơn", which conversely is unknown to older 
Vietnamese Americans.


When I originally tagged the D.C. node with Vietnamese names in 
changeset 5439052, I intended for the fallback to be "Washington", as a 
compromise between the traditional and more modern names. But I 
hesitated to explicitly tag name:vi=Washington because it's incompatible 
with the Vietnamese alphabet. I guess I should've added it as a bulwark 
against armchair linguistics. Changeset 76520412 set name:vi to 
"Washington, D.C.", which to a Vietnamese speaker is rather like 
labeling New Orleans as "New Orleans, LA" on a map.


Long story short, I find changeset 76520412 to be problematic in the 
languages I know, let alone the many languages I don't. Thanks for 
bringing it to our attention.


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk-fr] Élections :: Assemblée générale de l'OSMF :: Deux formulaires

[Georges Dutreix via Talk-fr]

Le 05/12/2020 à 21:31, Jacques Lavignotte a écrit :

Vous l'avez noté : Vous avez reçu deux mails pour deux scrutins.
Ben non. Je me suis fait éjecter sans préavis pour un pb avec paypal. Je 
suis déçu :-(
Pourtant j'ai eu plusieurs échanges emails avec la fondation, et je 
pensais que c'était réglé...


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

Re: [OSM-talk-fr] Élections :: Assemblée générale de l'OSMF :: Deux formulaires

[Jacques Lavignotte]

Le 05/12/2020 à 19:17, leni a écrit :


je pense donc que je vais passer mon tour et ne pas voter


Dommage.

Vous l'avez noté : Vous avez reçu deux mails pour deux scrutins.


Prenez le temps de lire les professions de foi. Et les réponses aux 
questions. Deepl aide bien.


Hint : utilisez l'outil 'Recherche' avec les mots clés qui font peur.


Jacques : A voté pour les deux scrutins.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Élections pour la fondation OSM / l'enjeu de la présence des AFAM ...

[Christian Quest]

Le 05/12/2020 à 19:34, Vincent Bergeot a écrit :
Le 5 décembre 2020 19:17:59 GMT+01:00, leni  a 
écrit :


Déjà que lorsque c'est en français, il m'est difficile de pouvoir
appréhender ce que chacun des candidats peut apporter, en anglais ... je
pense donc que je vais passer mon tour et ne pas voter

bon we

leni

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


Bonjour,
Je comprends cette difficulté (deepl est souvent mon ami). D'où ma 
demande d'avoir des retours ici, des avis, des impressions pour aider.
Je sais que pour ma part j'ai envie de voter pour des candidats qui ne 
sont pas AFAM... et parmi les autres, complexe ! Un français pour 
pouvoir causer plus facilement, un hors 'occident' pour diversifier, 
Roland pour overpass, tobias pour la 'continuité', ...

My2cents, mes2sous



Vu le système de vote, on peut très bien se contenter d'un nom ou deux 
(ce qui en plus renforce le vote pour eux).


Voter est important pour conserver l'esprit du projet et son 
indépendance vis à vis des grands entreprises du numériques, de plus en 
plus envahissants.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Élections pour la fondation OSM / l'enjeu de la présence des AFAM ...

[Vincent Bergeot]

Le 5 décembre 2020 19:17:59 GMT+01:00, leni  a écrit :
>Déjà que lorsque c'est en français, il m'est difficile de pouvoir 
>appréhender ce que chacun des candidats peut apporter, en anglais ...
>je 
>pense donc que je vais passer mon tour et ne pas voter
>
>bon we
>
>leni
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

Bonjour,
Je comprends cette difficulté (deepl est souvent mon ami). D'où ma demande 
d'avoir des retours ici, des avis, des impressions pour aider.
Je sais que pour ma part j'ai envie de voter pour des candidats qui ne sont pas 
AFAM... et parmi les autres, complexe ! Un français pour pouvoir causer plus 
facilement, un hors 'occident' pour diversifier, Roland pour overpass, tobias 
pour la 'continuité', ...
My2cents, mes2sous

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

Re: [OSM-talk] Please review "Community attribution advice” wiki page

[Joseph Eisenberg]

The text of the first section previously ended with this sentence:

"To what extent you might practically get away with lesser attribution -
either legally or socially - is outside the scope of this document."

Probably such a sentence is acceptable in some cultures, but it sounds odd
in the Anglo-American legal context so I removed it.

However, perhaps there is a more polite way to say the same sort of thing,
without seeming to invite "getting away with it?"

-- Joseph Eisenberg

On Sat, Dec 5, 2020 at 12:36 AM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> One thing that is missing to me is explicit mention that it is not
> overriding ODBL or related laws and is not adding any legal
> requirements.
>
> If someone follows ODBL license or is in situation where following license
> is not needed for some reason, they can legally do this.
>
> Maybe also mention that it is may be recommending more attribution than
> bare minimum that is required by ODBL, so it is a safe solution that should
> be also fine for any typical[1] project that is not hostile to OSM?
>
> [1] "typical" - especially for very small objects things gets trickier,
> if you are making some special purpose map (tactile map for blind)
> then attribution also needs to be adapted, if map is going to be used
> in place where English is not understood in general you will definitely
> need to translate attribution etc etc.
>
> https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline claim
> that smartphone has not enough space for attribution is clearly untrue.
> But if you show OSM map on screen of size 1cm x 1 cm or similarly tiny
> physical object then alternative attribution methods - that still comply
> with
> ODBL - may be preferable.
>
> Dec 4, 2020, 21:41 by joseph.eisenb...@gmail.com:
>
> I appreciate the wik page "Community attribution advice" which was made
> by another community member. It seems to give good advice about how
> database users can comply with the attribution guidelines in a way that
> everybody* in this community can support.
>
> Please review the page and make any comments for improvement if needed:
>
> https://wiki.openstreetmap.org/wiki/Community_attribution_advice
>
> -- Joseph Eisenberg
>
> (*Note that "everybody" does not include the interests of corporations,
> which are not persons, but rather the interests of individual mappers and
> database users)
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Élections pour la fondation OSM / l'enjeu de la présence des AFAM ...

[leni]

Déjà que lorsque c'est en français, il m'est difficile de pouvoir 
appréhender ce que chacun des candidats peut apporter, en anglais ... je 
pense donc que je vais passer mon tour et ne pas voter


bon we

leni


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

Re: [talk-cz] Moderní komunikační kanál?

[Jirka Sedláček]

Jo, a to je přesně ono.

Já třeba (a myslím, že i mnoho ostatních) mají email poměrně dost
zahlcenej. Jednou za čas na to sednu a čistím, jinak se pohybuju u několika
stovek nepřečtených e-mailů. A notifikace mám zapnutý cíleně jen na
počítači a i tam je profesně přehlížím a do e-mailu lezu fakt jen občasně.
I protože to je shluk náhodných bezcílných informací.

Ale discord mi přijde jako totální peklo, za mě by vyhovoval Slack – jen
tam je ta free podmínka, kterou zmiňoval Marián. Uchovává se tuším jen
1 posledních zpráv - a to je pekelně málo. Dalo by se to asi hacknout
přes nějakej na to napojenej archivátor, ale … ale proč.

Tj. tohle podle mě nemá snadné řešení. Hlavně ať to není nějaký fórum kdesi
bez notifikací … to na to pak zapomene valná většina lidí.

J.

-- 
Jirka Sedláček

Dne 3. prosince 2020 v 10:39:40, Jan Dudík (jan.du...@gmail.com) napsal/a:

Ještě tu nepadla jedna věc - pokud člověk používá jeden mail (více mailů
stahovaných do stejného klienta), obvykle si všimne nové zprávy relativně
rychle (pokud není ve skluzu s vyřizováním konkrétní složky). Věřím, že
většina lidí se na mail podívá alespoň několikrát za týden.

Oproti tomu jakákoliv jiná aplikace, ať už webová nebo na mobil vyžaduje,
aby se na ní člověk díval - buď chodl na nějakou stránku nebo zapínal
aplikaci (nebo ji nechal běžet na pozadí a pak mu pořád chodily notifikace).
Sleduju určitá fóra a nebýt toho, že mám dotčenou stránku neustále
připnutou v prohlížeči, asi bych se tam nedíval ani jednou týdně.

Pokud by komunikace probíhala na platformě, kterou dotyčný často používá i
pro jiné účely (pro někoho to může být facebook, pro jiného discord, pro
třetího třeba irc), pak to pro dotyčného má obdobnou výhodu jako mail.
Problém je, že touto platformou je pro každého něco jiného.

JAnD


st 2. 12. 2020 v 19:40 odesílatel gebylist via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Dne 02.12.2020 v 16:14 Jiri Vlasak napsal(a):
> > komunikace přes email *je standardní* (nikoli poměrně.) OSM (nejen cz)
> komunita
> > mailing listy používá s úspěchem po celém světě [1].
>
> Já bych navíc dodal, že email má opravdu každý! Už jen proto, že
> registrace na kdejakých jiných komunikačních platformách email vyžaduje.
> Ergo, email je komunikačí nástroj s nejširším záběrem.
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] Idea - OSMUK walkers' map application

[Robert Whittaker (OSM lists)]

On Sat, 5 Dec 2020 at 15:29, Nick Whitelegg via Talk-GB
 wrote:
> A shame really, an open, standard API - and accompanying open source clients 
> to the API - adopted by all councils for problem reporting would be a great 
> thing to have.

It would indeed be great. An open standard for this already exists --
it's called Open311. I don't think there's very much adoption of it
though. See https://www.open311.org/ and
https://www.mysociety.org/2013/01/10/open311-introduced/ . Fix
MyStreet can make use of it where it is available, and some of the
councils they have collaborated with may well support it.

If anyone is looking to create some sort of reporting tool for PRoW
faults, I'd suggest a system that will use Open311 if the council
supports it, and otherwise send the report through FixMyStreet.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] No U-turn on a long stretch of road

[Robert Skedgell]

This probably won't help routers much, but you could at least tag the
positions of the signs as nodes on the highway with
traffic_sign=GB:614 + direction=forward|backward

On 05/12/2020 14:27, Edward Bainton wrote:
> Sorry I should have made clear 
> 
> Rather than seeking to capture a subjective jmt in the map, I'm trying
> to capture "no U-turn" signs that are shopping this long stretch, . 
> 
> I agree a driver should use their discretion. Equally where it's
> actually prohibited do we want to capture that?
> 
> On Sat, 5 Dec 2020, 12:57 David Woolley,  > wrote:
> 
> On 05/12/2020 12:39, Edward Bainton wrote:
> > Any established tagging system?
> >
> > The turn restriction wiki
> >  > envisages
> > turn restrictions at junctions only; my case is along the length of a
> > major road (~3km). There's no barrier to prevent it, but presumably
> > routing engines ought to know that route correction after a wrong
> turn
> > will have to wait until the next roundabout.
> >
> 
> That's a subjective judgement, so would be tagging for the renderer.
> The renderer (in this case a router) should be using some sort of
> heuristic like only  permitting U turns on residential or service
> roads,
> and giving a heavy weighting to the use of formal junctions at the the
> expense of distance travelled.  A real human would consider actual
> traffic levels and sight distances but they would be difficult to
> capture on the map and time and season dependent.
> 
> I think No U Turn signs tend only to be used where traffic volumes or
> junction structures, might otherwise suggest U turns were acceptable.
> 
> I don't think any driver (or autonomous vehicle) should be making U
> Turns based solely on the instructions of an automated router.

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

Re: [Talk-hr] Import ZET ID-ova od stanica iz GTFS-a

[Janko Mihelić]

On Sat, Dec 5, 2020, 16:25 Ivan Habunek  wrote:

> Je li gtfs:stop_id:ref nužan za import? Čini mi se da nam inače taj tag
> nije potreban, ili barem ne znam za što bi se koristio. Ako je nužan,
> možda bi ga mogli obrisati nakon što import završi?
>

Nije nužan ni za import. Imao sam osjećaj da bi možda olakšao daljnje
održavanje importa, ali zapravo, sad kad gledam, bolje da ga ne uvodimo.

Gledam wiki gdje na Buses stranici [1] predlažu da se broj perona
> unutar stanice obilježava `local_ref` tagom, dok na dokumentaciji tog
> taga [2] kaže da je češća praksa da se koristi samo `ref`.
>

E to bi mogli početi koristiti. Možda radije local_ref jer su manje šanse
da će netko imati drugu ideju za što služi ref tag. Ali to nema veze sa
importom ako odustanemo od dodavanja toga. Evo, budem obrisao taj tag sa
wikija.

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

Re: [Talk-GB] Idea - OSMUK walkers' map application

[Nick Whitelegg via Talk-GB]

>Some councils insist that problem reports only come through their own
>web sites, or reluctantly, by phone, and will ignore emails (which is
>the default presentation for FixMyStreet).

>The web sites generally provide structured input, whereas FixMyStreet is
>generally free text, and also, the web site sometimes bypasses the
>council contact centre, and goes direct to the out sourced contractor.

A while back I did build an app to send problem reports to Hampshire county 
council specifically, as Hampshire had a very keen and enthusiastic staff 
member. However I contacted other local councils asking for details on whether 
they had any APIs to send the data to, but either heard nothing or a response 
(as you said) that they were not so keen on input from other sources.

A shame really, an open, standard API - and accompanying open source clients to 
the API - adopted by all councils for problem reporting would be a great thing 
to have.

Nick



From: David Woolley 
Sent: 04 December 2020 16:49
To: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] Idea - OSMUK walkers' map application

On 04/12/2020 16:38, Nick Whitelegg via Talk-GB wrote:
> However as you say council take up could be problematic. Maybe we could
> provide a link to FixMyStreet?

Some councils insist that problem reports only come through their own
web sites, or reluctantly, by phone, and will ignore emails (which is
the default presentation for FixMyStreet).

The web sites generally provide structured input, whereas FixMyStreet is
generally free text, and also, the web site sometimes bypasses the
council contact centre, and goes direct to the out sourced contractor.

___
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-hr] Import ZET ID-ova od stanica iz GTFS-a

[Ivan Habunek]

On Sat, Dec 05, 2020 at 03:46:19PM +0100, Janko Mihelić wrote:
> Sada kad imamo podatke, pokrenuo sam wiki u kojem sam predložio kako da
> obavimo taj import:
> https://wiki.openstreetmap.org/wiki/Zagreb/Import_ZET_GTFS

Super što si ovo pokrenuo.
 
> Javite jel se ne slažete sa nečime. Recimo, nisam baš siguran da je
> gtfs:stop_id:ref=* tag koji želimo za redni broj stanice unutar grupe
> stanica istih imena.

Je li gtfs:stop_id:ref nužan za import? Čini mi se da nam inače taj tag
nije potreban, ili barem ne znam za što bi se koristio. Ako je nužan,
možda bi ga mogli obrisati nakon što import završi?

Gledam wiki gdje na Buses stranici [1] predlažu da se broj perona
unutar stanice obilježava `local_ref` tagom, dok na dokumentaciji tog
taga [2] kaže da je češća praksa da se koristi samo `ref`.

[1] 
https://wiki.openstreetmap.org/wiki/Buses#Step_1_-_Make_sure_that_each_bus_stop_in_the_route_has_been_added_to_OpenStreetMap
[2] https://wiki.openstreetmap.org/wiki/Key:local_ref

-- Ivan




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

Re: [OSM-talk-fr] osmose + BANO = dégommer du rouge en mode turbo !

[Jacques Lavignotte]

Le 05/12/2020 à 15:47, Christian Quest a écrit :


Cette analyse est une aide, mais nécessite une vérification et parfois 
des corrections


C'est bien comme ça que je pratique.


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] osmose + BANO = dégommer du rouge en mode turbo !

[Christian Quest]

Le 05/12/2020 à 09:38, Jacques Lavignotte a écrit :

Bonjour,

Probable effet de bord :

pour https://www.openstreetmap.org/way/173195516

Osmose/Bano proposait : « Impasse du Logis Le Bourg »

en s'accaparant le texte « Le Bourg » présent à moins de 100 m de la 
voie rapprochée.


Un ou deux autres dans le coin.

A suivre.

J.


C'est que ce libellé est présent dans FANTOIR et n'a pas de rapport avec 
la proximité géographique d'un autre toponyme, au moins au niveau du 
code de BANO et de l'analyse osmose qui en découle.


Cela arrive aussi avec les hameaux ou les communes fusionnées où leur 
nom peut se retrouver en suffixe.


Cette analyse est une aide, mais nécessite une vérification et parfois 
des corrections comme les accents incorrects, les traits d'union 
manquants dans les prénoms composés ou les saints/saintes...



--
Christian Quest - OpenStreetMap France


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

[Talk-hr] Import ZET ID-ova od stanica iz GTFS-a

[Janko Mihelić]

Pozdrav,

planirali smo napraviti ovaj import, pa smo shvatili da prvo moramo
natjerati ZET da objavi otvorenu licencu uz GTFS podatke. To smo i uspjeli,
što je vidljivo na  njihovim stranicama:
https://www.zet.hr/odredbe/datoteke-u-gtfs-formatu/669

Natjerali smo ih preko sjajne stranice "Imam pravo znati":
http://imamopravoznati.org/request/dopustenje_za_unos_podataka_iz_g

Sada kad imamo podatke, pokrenuo sam wiki u kojem sam predložio kako da
obavimo taj import:
https://wiki.openstreetmap.org/wiki/Zagreb/Import_ZET_GTFS

Javite jel se ne slažete sa nečime. Recimo, nisam baš siguran da je
gtfs:stop_id:ref=* tag koji želimo za redni broj stanice unutar grupe
stanica istih imena.

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

Re: [Talk-es] Importación de usos de suelo de geoeuskadi

[Javier Gómez Pose]

Kaixo

La autorización del Gobiero Vasco ya la tenemos y hace tiempo que
muchos usuarios están usando geoeuskadi como referencia para trabajar
en OSM 
(https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_potenciales_de_Espa%C3%B1a#geoEuskadi).
Para citar la fuente, en un principio puse source=geoeuskadi, pero he
visto que solicitaron poner la fuente como "Eusko Jaurlaritza/Gobierno
Vasco. geoEuskadi" y en las últimas importaciones así lo he puesto y
lo iré corrigiendo en los que puse solo geoeukadi. La importación de
usos de suelo sería un punto de partida importante para mejorar el uso
de suelos de OSM en  Euskadi y con la metodología usada sería fácil de
modificar partes. Por ejemplo, geoeuskadi no diferencia entre zonas de
uso industrial y residencial y en los casos que ya estén asignados los
mantendré, pero en otros seguramente quedarán como
landuse=residential. Los mapeados de usos de suelos en los que se
superponen polígonos o donde los polígonos están separados entre sí
son difíciles de actualizar, por lo que en la importación procuraré
que todos los polígonos estén conectados entre sí en todos sus puntos,
excepto, como es obvio, en los multipolígonos. Explicaré en el wiki la
forma más adecuada y sencilla para actualizar las partes que se
consideran mejorables, como mayor especificación en las farmland,
precisión en el mapeado de suelos, diferenciación entre residential e
industrial, etc. Voy a reenviar la propuesta de importación a
impo...@openstreetmap.org y prepararé la página de la wiki
correspondiente a la importación antes de realizar ninguna tarea sobre
OSM.

Saludos

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

Re: [Talk-GB] No U-turn on a long stretch of road

[Edward Bainton]

Sorry I should have made clear

Rather than seeking to capture a subjective jmt in the map, I'm trying to
capture "no U-turn" signs that are shopping this long stretch, .

I agree a driver should use their discretion. Equally where it's actually
prohibited do we want to capture that?

On Sat, 5 Dec 2020, 12:57 David Woolley,  wrote:

> On 05/12/2020 12:39, Edward Bainton wrote:
> > Any established tagging system?
> >
> > The turn restriction wiki
> >  envisages
> > turn restrictions at junctions only; my case is along the length of a
> > major road (~3km). There's no barrier to prevent it, but presumably
> > routing engines ought to know that route correction after a wrong turn
> > will have to wait until the next roundabout.
> >
>
> That's a subjective judgement, so would be tagging for the renderer.
> The renderer (in this case a router) should be using some sort of
> heuristic like only  permitting U turns on residential or service roads,
> and giving a heavy weighting to the use of formal junctions at the the
> expense of distance travelled.  A real human would consider actual
> traffic levels and sight distances but they would be difficult to
> capture on the map and time and season dependent.
>
> I think No U Turn signs tend only to be used where traffic volumes or
> junction structures, might otherwise suggest U turns were acceptable.
>
> I don't think any driver (or autonomous vehicle) should be making U
> Turns based solely on the instructions of an automated router.
>
> ___
> 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-es] Importación de usos de suelo de geoeuskadi

[Lanxana]

Buenos días,

Coincido con Miguel en que aunque la carga de los datos se esté haciendo de
manera manual, se debe tratar como una importación. De hecho, actualmente
sería muy difícil hacer una importación automática sin revisión manual,
dado que ya hay muchos datos en el mapa y se tienen que combinar con los
nuevos. Y otro de los puntos que para mí implica que se trate como
importación es que la fuente de datos es una fuente oficial. Añadir esta
información al dato que se importa no tan solo le dará más calidad sino que
ayudará a su trazabilidad. Igual que ahora podemos saber que esos
manchurrones provienen de una terrible importación del Corine, en el futuro
podremos saber que esos usos de suelo más detallados lo hacen de una fuente
oficial (geoeuskadi) en un momento determinado (fecha de los datos).

Y ahí entramos en el segundo punto, con el que también coincido, para poder
usar la fuente oficial hay que asegurarse que la licencia es compatible con
la de OSM. Aún nos escuece a varios el tirón de orejas que nos llegó de la
lista de imports cuando presentamos la importación de las farmacias en
Catalunya al inicio del confinamiento. La importación se apoyó en la carta
de autorización que teníamos para usar los datos publicados como OpenData,
pero incluía un punto en el que hablaba de no desvirtuar los datos, y se
abrió el debate de qué se considera desvirtuar los datos, si se puede o
no... Por suerte al final se pudo resolver el asunto pidiendo al gestor del
opendata un cambio de licencia a CC0 y la importación se pudo realizar.

Por si te sirve de inspiración para plantear el proyecto de importación de
geoeuskadi, en Catalunya tenemos en marcha el de importación de usos del
suelo desde SIGPAC, que también se hace prácticamente manual para poder
combinar con los usos ya existentes.

Saludos!

El mar, 1 dic 2020 a las 12:15, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Estimado Javier,
>
> Muchas gracias gracias por tus esfuerzos, las ediciones y la metodologías
> que nos has enviado. Es de gran calidad y utilidad para futuros proyectos.
>
> Aunque la subida de datos la estas haciendo de manera "manual" y poco a
> poco esto no deja de ser una importación en toda regla y aunque no nos
> guste dentro de la comunidad y del proyecto desde que se realizaron
> importaciones masivas y no realmente bien hechas (véase la que se hizo en
> su día del CORINE y que mencionas en tu correo) hay que seguir los pasos y
> las condiciones que están indicadas en la wiki:
>
> https://wiki.openstreetmap.org/wiki/Import
>
> Échale un ojo, aquí se indica cómo has de proceder.
>
> Para empezar has de tener permiso para la importación de los datos que
> estás usando, que, ojo, aunque no nos guste, hay que ir más allá de que
> tengan una licencia Creative Commons. Este es el primer requisito.
>
> Desde la comunidad estaremos encantados de apoyar tu trabajo y ayudarte en
> lo que necesites. Personalmente yo no tengo grandes experiencias en el
> asunto de las importaciones pero a buen seguro más de un otro colaborador
> te podrá indicar con más detalle.
>
> Un saludo y ánimo con ese trabajo!
>
> Miguel
>
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
>
> On Mon, 30 Nov 2020 at 23:14, Javier Gómez Pose 
> wrote:
>
>> Importación de usos de suelo de geoeuskadi
>>
>> Comencé a realizar la importación de usos de suelos de geoeuskadi sin
>> consultarlo ya que no lo consideraba una importación debido que no se trata
>> de una importación automática sino que lo estoy realizando manualmente. Me
>> han corregido, así que paso a explicar el proceso que sigo y espero los
>> comentarios de la pequeña comunidad de Euskadi. Si a la comunidad no le
>> parece bien mi planteamiento no tendré reparos en dejar de realizar la
>> importación y estoy abierto a cualquier sugerencia.
>>
>> Importancia de usos de suelo:
>>
>> Mi principal interés en OSM está en las zonas no urbanas, usos de suelo,
>> cuevas, simas, pistas, senderos, ermitas, cascadas, fuentes, etc. debido a
>> que soy aficionado a la bicicleta de montaña. El uso de suelos combinado
>> con las curvas de nivel en una aplicación para móvil que haga uso de OSM,
>> como por ejemplo OsmaAnd, es muy útil para el que disfruta explorando zonas
>> poco conocidas del monte y para predecir qué tipo de paisaje se puede
>> encontrar. Mientras que Google maps, en mi opinión, es muy superior a OSM
>> en las zonas urbanas y en carreteras nacionales, OSM lo es en el monte,
>> frente a Google que se vuelve prácticamente una herramienta inútil.
>>
>> Estado actual del uso de suelos:
>>
>> En la mayor parte de España y gran parte de Euskadi, la importación de
>> usos de suelos que se hizo en el 2011 corresponde a EU CORINE land cover
>> 2006 y aunque da una idea general de las grandes masas, no tienen gran
>> utilidad, son demasiado grandes y muchas están compuestas por formas con
>> líneas no cerradas. En Euskadi casi todas las formas de esta importación
>> corresponden a la masa 

Re: [Talk-GB] River Lugg

[SK53]

I suggest mapping the parish of Kingsland in detail from aerial imagery.
This will facilitate locating the re-profiled area from features visible in
photos and videos appearing in the news. For instance at least part of the
damaged bank is on the right bank extending downstream from a bridge with a
minor power line in the fields. There are also some distinctive farm
buildings in other photos.

Unfortunately, there doesnt seem to be any data on EA Stewardship payments
for the relevant area (from Anna Powell-Smith's map
). The SSSI is Natural England Open Data,
but as it covers more or less all of the Lugg might not be useful. However,
there are a couple of more extensive areas of SSSI which might be part of
the damaged area. LR Inspire land parcels may help delineate specific
farms. I presume this is a single farmer whose land abuts the river.

Jerry

On Fri, 4 Dec 2020 at 16:46, Andy Mabbett  wrote:

> Terrible news from Herefordshire:
>
>
> https://www.ledburyreporter.co.uk/news/18920990.environment-agency-launch-probe-river-lugg-destruction/
>
>
> https://www.wildlifetrusts.org/news/horror-destruction-nationally-important-uk-river
>
> about illegal reprofiling of a mile-long stretch of the Lugg. But we
> probably still need to map the changes.
>
> Do we have anyone local?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] No U-turn on a long stretch of road

[David Woolley]

On 05/12/2020 12:39, Edward Bainton wrote:

Any established tagging system?

The turn restriction wiki 
 envisages 
turn restrictions at junctions only; my case is along the length of a 
major road (~3km). There's no barrier to prevent it, but presumably 
routing engines ought to know that route correction after a wrong turn 
will have to wait until the next roundabout.




That's a subjective judgement, so would be tagging for the renderer. 
The renderer (in this case a router) should be using some sort of 
heuristic like only  permitting U turns on residential or service roads, 
and giving a heavy weighting to the use of formal junctions at the the 
expense of distance travelled.  A real human would consider actual 
traffic levels and sight distances but they would be difficult to 
capture on the map and time and season dependent.


I think No U Turn signs tend only to be used where traffic volumes or 
junction structures, might otherwise suggest U turns were acceptable.


I don't think any driver (or autonomous vehicle) should be making U 
Turns based solely on the instructions of an automated router.


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

[Talk-GB] No U-turn on a long stretch of road

[Edward Bainton]

Any established tagging system?

The turn restriction wiki
 envisages turn
restrictions at junctions only; my case is along the length of a major road
(~3km). There's no barrier to prevent it, but presumably routing engines
ought to know that route correction after a wrong turn will have to wait
until the next roundabout.

Thanks as always.

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

Re: [OSM-talk-fr] La question des produits locaux (alimentation mais sans, doute de manière plus large également)

[Vincent Bergeot]

Le 05/12/2020 à 12:58, Bobolica a écrit :


Salut,

pour avoir travaillé sur cette question côté Creuse, on a fait le 
choix d'un gogocarto 
 car il 
répondait aussi à la problématique de l'interface de consultation mais 
je suis curieux de creuser le sujet :>.



super,

oui gogocarto c'est chouette, cela a de la gueule, mais c'est 1 
carte=1silo de donnée=1 communauté ... Échange fréquent sur le sujet 
avec le dev de gogocarto et diverses autres communautés ayant des cartes 
sur gogocarto


Travailler sur les descripteurs dans OSM c'est pouvoir imaginer plus de 
cartes diverses avec un "minimum" en commun et potentiellement plus de 
communautés autour de ces données que nous aimons tant :)


à plus

--
Vincent Bergeot

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

Re: [OSM-talk-fr] La question des produits locaux (alimentation mais sans, doute de manière plus large également)

[Bobolica]

Salut,

pour avoir travaillé sur cette question côté Creuse, on a fait le choix 
d'un gogocarto  
car il répondait aussi à la problématique de l'interface de consultation 
mais je suis curieux de creuser le sujet :>.



Quentin

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

Re: [OSM-talk-fr] Élections pour la fondation OSM / l'enjeu de la présence des AFAM ...

[Leroy Olivier]

Bonjour,

Je vote aussi (parce que j'ai pris un cotis') et ne connais pas non plus
les tenants ni les aboutissants. Je me permet donc de +1 le message de
Vincent.

Olivier

Le sam. 5 déc. 2020 à 11:38, Vincent Bergeot  a écrit :

> Bonjour,
>
> je me permets de signaler ces échanges (anglais) autour d'un des
> candidats (Michal, employé Facebook mais pas que) :
> https://lists.openstreetmap.org/pipermail/talk/2020-November/085670.html
>
> Je signale celui ci car quelques sujets relatifs à la présence
> d'entreprises comme facebook dans la communauté OSM (il y ait questions
> d’attributions pas très propre par exemple de facebook, de la dispo sur
> des horaires de bureaux, ...) et cela part en vrille avec des
> accusations de sexisme, de souhaiter détourner l'attention, ...  avec
> d'autres poids lourds de la communauté comme Frédérick Rahm, Steve
> Coast,  ... et cela semble aussi se décliner sur twitter !
>
> Je ne connais pas personnellement les diverses personnes impliquées mais
> je serais attentif aux retours de ceux qui parmi vous les connaissent ou
> les ont croisé et ont suivi ces échanges !
>
> Pour rappel les candidats sont listés ici (le vote commence aujourd'hui,
> jusqu'à l'AG de samedi prochain) :
>
> https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos#Answers_and_manifesto_per_candidate
>
> PS : je ne cache pas que je suis craintif de la présence d'un membre
> comme Facebook dans le board (indépendamment de la personne de Michal,
> que je ne connais pas, ni sa sincérité, ni son engagement, ni sa
> capacité de résistance à son employeur, ...).
>
> --
> Vincent Bergeot
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS IMU GOURAMIC
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Kandidatur für den OSMF-Vorstand

[Frederik Ramm]

Hallo,

On 12/4/20 22:04, Mark Obrembalski wrote:
> Für die anstehende Wahl ist es zwar zu spät, aber was künftige Wahlen
> angeht, könntest Du ja einfach beitreten...

Kostet jetzt ja nicht mal mehr was, wenn man "aktiver Mapper" ist ;)

Auch von mir übrigens ein "Daumen hoch" für Tobias' Agenda!

Bye
Frederik

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

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

Re: [OSM-talk] Please review "Community attribution advice” wiki page

[Frederik Ramm]

Hi,

On 12/4/20 21:41, Joseph Eisenberg wrote:
> Please review the page and make any comments for improvement if needed:

Might be worth waiting until the next OSMF board meeting (in 5 days)
which has the official attribution guidelines on its agenda; perhaps
they come to a decision on that which would likely also inform any
discussion about this advice page - either the community is happy enough
with the official guidelines which would then make this page expendable,
or at least the page could use language like "in addition/in contrast to
the official requirement, lah lah lah".

Bye
Frederik

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

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

[OSM-talk-fr] Élections pour la fondation OSM / l'enjeu de la présence des AFAM ...

[Vincent Bergeot]

Bonjour,

je me permets de signaler ces échanges (anglais) autour d'un des 
candidats (Michal, employé Facebook mais pas que) : 
https://lists.openstreetmap.org/pipermail/talk/2020-November/085670.html


Je signale celui ci car quelques sujets relatifs à la présence 
d'entreprises comme facebook dans la communauté OSM (il y ait questions 
d’attributions pas très propre par exemple de facebook, de la dispo sur 
des horaires de bureaux, ...) et cela part en vrille avec des 
accusations de sexisme, de souhaiter détourner l'attention, ...  avec 
d'autres poids lourds de la communauté comme Frédérick Rahm, Steve 
Coast,  ... et cela semble aussi se décliner sur twitter !


Je ne connais pas personnellement les diverses personnes impliquées mais 
je serais attentif aux retours de ceux qui parmi vous les connaissent ou 
les ont croisé et ont suivi ces échanges !


Pour rappel les candidats sont listés ici (le vote commence aujourd'hui, 
jusqu'à l'AG de samedi prochain) : 
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos#Answers_and_manifesto_per_candidate


PS : je ne cache pas que je suis craintif de la présence d'un membre 
comme Facebook dans le board (indépendamment de la personne de Michal, 
que je ne connais pas, ni sa sincérité, ni son engagement, ni sa 
capacité de résistance à son employeur, ...).


--
Vincent Bergeot


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

Re: [OSM-talk-fr] osmose + BANO = dégommer du rouge en mode turbo !

[Jacques Lavignotte]

Bonjour,

Probable effet de bord :

pour https://www.openstreetmap.org/way/173195516

Osmose/Bano proposait : « Impasse du Logis Le Bourg »

en s'accaparant le texte « Le Bourg » présent à moins de 100 m de la 
voie rapprochée.


Un ou deux autres dans le coin.

A suivre.

J.





Le 01/12/2020 à 18:44, Christian Quest a écrit :
J'ai remis en route l'analyse osmose comparant BANO et les noms de rues 
absents / incorrects.


http://osmose.openstreetmap.fr/fr/map/#item=7170=32=1%2C2%2C3

Petit rappel de ce qu'elle fait...

- elle recherche les groupes d'adresses pour un nom de rue dont le 
rapprochement n'a pas pu se faire (le "rouge" du rendu BANO)


- elle repère si un highway=* semble correspondre avec la zone couverte 
par ce groupe d'adresse


- elle propose d'ajouter le nom


Avec un grand écran, je met une fenêtre osmose à côté d'une fenêtre JOSM 
dans lequel je charge la couche BANO et le cadastre.


Ensuite 4 clics suffisent :

- clic sur une anomalie pour ouvrir son popup

- "josm-zone" pour charger la zone dans JOSM et vérifier que la 
proposition est cohérente


- "fix-josm" pour appliquer la correction

- "coche verte" pour valider

En général, ça vaut le coup de regarder aussi alentours, car ces manques 
volent souvent en escadrilles et ne sont pas tous repérés par l'analyse.





--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk] Please review "Community attribution advice” wiki page

[Mateusz Konieczny via talk]

One thing that is missing to me is explicit mention that it is not
overriding ODBL or related laws and is not adding any legal
requirements.

If someone follows ODBL license or is in situation where following license
is not needed for some reason, they can legally do this.

Maybe also mention that it is may be recommending more attribution than
bare minimum that is required by ODBL, so it is a safe solution that should
be also fine for any typical[1] project that is not hostile to OSM?

[1] "typical" - especially for very small objects things gets trickier,
if you are making some special purpose map (tactile map for blind)
then attribution also needs to be adapted, if map is going to be used
in place where English is not understood in general you will definitely
need to translate attribution etc etc.

https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline claim
that smartphone has not enough space for attribution is clearly untrue.
But if you show OSM map on screen of size 1cm x 1 cm or similarly tiny
physical object then alternative attribution methods - that still comply with
ODBL - may be preferable.

Dec 4, 2020, 21:41 by joseph.eisenb...@gmail.com:

> I appreciate the wik page "> Community attribution advice" which was made by 
> another community member. It seems to give good advice about how database 
> users can comply with the attribution guidelines in a way that everybody* in 
> this community can support.
>
> Please review the page and make any comments for improvement if needed:
>
> https://wiki.openstreetmap.org/wiki/Community_attribution_advice
>
> -- Joseph Eisenberg
>
> (*Note that "everybody" does not include the interests of corporations, which 
> are not persons, but rather the interests of individual mappers and database 
> users)
>

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