date:20200117

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-17 Per discussione Philippe Verdy

Sans doute parce que ce sont leur parking qui sont tagués.

Aussi parce que la plupart des hôtels sont tagués comme des noeuds (parfois
sur le noeud d'adresse FANTOIR, en limite de propriété, ou de bâtiment dans
les rues urbaines). Noter qu'on ne peut pas toujours taguer le batiment
lui-même qui a plusieurs adresses et des services différents, parfois aussi
des résidences privées.

De plus si ce sont des équipements des hôtels eux-mêmes, ils sont sur des
parkings privés (en principe fermés la nuit par une barrière et un digicode
pour appeler le gardien, ou bien dans un garage où ce n'est pas forcément
visible et encore moins facile à taguer).

Nombre d'hôtels sont ajoutés dans OSM par des agences à partir des données
que leur fournissent les hôtels ou chaines d'hôtel, qui ont sans doute omis
de mentionner ça, ou bien l'agence n'a pas su taguer cet équipement (sur le
noeud/way/relation, sur le bâtiment ou le parking ou une relation indiquant
toute la dépendance hôtelière (autour de l'enceinte, incluant le batiment,
les jardins, cours, parkings et voies privées).

Si ce sont des équipements privés, non accessibles au public, je pense
qu'il vaut mieux ne pas taguer comme un "amenity=*" qui désigne plutôt les
bornes accessibles au public, pas forcément client de l'hôtel et qui a le
droit d'y stationner. Mais on a bien des amenity=parking avec
access=private ou permissive et cela n'indique pas clairement le droit
d'accès à la recharge, même pour les clients, ce n'est pas nécessairement
gratuit, même pour eux où la recharge sera comptée sur leur facture de
séjour en utilisant leur carte électronique d'accès qui ouvre aussi et
identifie la chambre louée.

Les recharges privées pour l'instant sont hors périmètre. Ne pas les mettre
dans OSM pour ne pas tenter des visiteurs indélicats qui viendrait occuper
le parking et recharger gratuitement. Il vaut mieux que ce soit l'hôtel qui
indique lui-même les conditions d'accès qui peuvent aussi être différentes
de celles du parking.


Le sam. 18 janv. 2020 à 02:10, Shohreh  a écrit :

> Bonjour,
>
> La requête suivante pour trouver tous les hôtels en France qui proposent
> une
> prise pour recharger une voiture électrique… ne renvoie rien :
>
> =
> [out:json][timeout:60];
>
> //France métrop : 1403916
> rel(1403916);
> map_to_area -> .searchArea;
>
> (
>   node[tourism=hotel][amenity=charging_station](area.searchArea);
>   way[tourism=hotel][amenity=charging_station](area.searchArea);
> );
>
> out center;
> =
>
> Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?
>
> Merci.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-17 Per discussione Christian Quest


Les deux tags sont sûrement sur des objets séparés.

J'ai rajouté des IRVE qui étaient parfois dans des parking d'hôtels (cas 
de Tesla) et c'est à l'emplacement des places de parking dédiées que 
c'est taggué, pas sur l'hôtel lui même.


Exemple: https://tile.openstreetmap.fr/?zoom=19=49.2=-0.13114


Le 18/01/2020 à 02:09, Shohreh a écrit :

Bonjour,

La requête suivante pour trouver tous les hôtels en France qui proposent une
prise pour recharger une voiture électrique… ne renvoie rien :

=
[out:json][timeout:60];

//France métrop : 1403916
rel(1403916);
map_to_area -> .searchArea;

(
   node[tourism=hotel][amenity=charging_station](area.searchArea);
   way[tourism=hotel][amenity=charging_station](area.searchArea);
);

out center;
=

Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?

Merci.


--
Christian Quest - OpenStreetMap France


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

[OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-17 Per discussione Shohreh

Bonjour,

La requête suivante pour trouver tous les hôtels en France qui proposent une
prise pour recharger une voiture électrique… ne renvoie rien :

=
[out:json][timeout:60];

//France métrop : 1403916
rel(1403916);
map_to_area -> .searchArea;

(
  node[tourism=hotel][amenity=charging_station](area.searchArea);
  way[tourism=hotel][amenity=charging_station](area.searchArea);
);

out center;
=

Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-legal-talk] New data source

2020-01-17 Per discussione Cj Malone

Thanks Kathleen,

I'll add attribution to the wiki tomorrow.

My current intention isn't to automatically import, but rather generate a 
report where I can see where OSM names differ, then manually change the names 
is OSM via JOSM on a per node basis. Similar to 
https://gregrs.dev.openstreetmap.org/fhrs/ for food hygiene data.

Based on my limited survey of differences in OSM data and SV data, theirs has 
been more accurate. Not really surprising, since it's there network, and most 
of the OSM data hasn't been updated since the naptan import nearly a decade ago.

I don't think I will be making the report public, although since the data is 
not unique to the local bus operator, but rather their service providers. I 
could make reports for all areas available if desired. 
https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-ahead-group/

I don't really think this is an import, but rather "machine assisted" (if 
that's a thing in OSM vocabulary) I will however message the import mailing 
list to check there opinion on this. And I'll ask them if there is any point 
moving to the newer tagging method of public_transport=platform, as well as 
(for legacy reasons) highway=bus_stop.

Thank you

On 17 January 2020 21:28:16 GMT, Kathleen Lu via legal-talk 
 wrote:
>Hi Cj,
>Easiest method would be for you to update
>https://wiki.openstreetmap.org/wiki/Contributors with this information.
>(But please do note the import guidelines if you are thinking about
>importing)
>Best,
>Kathleen
>
>On Thu, Jan 16, 2020 at 5:26 AM Cj Malone  wrote:
>
>> Hello,
>>
>> I recently saw that some bus stop names are out of date in my area. I
>> updated the one I saw (
>> https://www.openstreetmap.org/node/533814248/history)
>>
>> But the local bus operator offers this data under Open Government
>> License Version 3.0. (https://www.islandbuses.info/open-data)
>>
>> As far as I understand it OGL can be used in OSM, but needs
>> attribution. Is this correct? How can OSM add the attribution so I
>can
>> start using this dataset?
>>
>> Once someone verifies that I can use this dataset I intend to correct
>> any OSM names, add fixme tags to any this I don't think exist any
>more.
>> And possibly add naptan:AtcoCode=x to nodes that don't have it in OSM
>> but do in the Southern Vectis dataset. And add "SouthernVectis" to
>the
>> source tag which would usually mean, source=naptan_import ->
>> source=naptan_import;SouthernVectis.
>>
>> Thanks
>> Cj
>>
>>
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Warin


On 17/1/20 10:08 pm, Mateusz Konieczny wrote:




17 Jan 2020, 11:42 by andrew.harv...@gmail.com:

I'm all for using the lifecycle prefix,
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix. I agreed
that if there's still remains there use ruined or destroyed, not
sure what the difference is though.

ruined implies that ruins still remain, destroyed may mean that or 
that there is no trace at all


in practice difference is minor if any


Most of these will still have foundations in place, they may not be fit 
for reuse but they are there. Some fire places and chimneys too remain.


I'll use ruined. Unless there are other ideas?



Once it's been cleared you could use demolished, removed or raised

Probably razed, not raised. I see not real difference.

, again not sure what the difference is. While damaged is not
documented it seems the perfect fit since there is no other
suitable tag for this on the wiki.

damaged seems to me a poor fit as prefix, damaged building is still a 
building,

and I would expect building=something tag to be used.



By damaged I mean part of the building is intact but another part has 
been damaged .. e.g. a truck has run part way through the building.





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

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Warin


On 17/1/20 9:42 pm, Andrew Harvey wrote:
On Fri, 17 Jan 2020 at 19:53, Warin <61sundow...@gmail.com 
> wrote:


I have tagged some buildings that have been fire damaged to a
large degree.
I have used building=razed however I think this is wrong.

I think the lifecycle prefix should be used.

The choices are;

ruins:*

or

destroyed:*

Thoughts?

I note there is the possibility of partial damage. A new tag of
damaged:* might be of use?


I'm all for using the lifecycle prefix, 
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix. I agreed that if 
there's still remains there use ruined or destroyed, not sure what the 
difference is though. Once it's been cleared you could use demolished, 
removed or raised, again not sure what the difference is. While 
damaged is not documented it seems the perfect fit since there is no 
other suitable tag for this on the wiki.


You'd probably need local knowledge to know all this, from the Maxar 
imagery you can see houses and trace them not sure how easy it will be 
to see destroyed houses though, will need to wait for the post event 
imagery to come out.



I have used imagery from press reports. As I am not copying the image I 
think that is ok.


For tracing in NSW I used the LPI Imagery.


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

Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

2020-01-17 Per discussione Andreas Vilén

On Fri, Jan 17, 2020 at 9:36 PM Grigory Rechistov via Talk-se <
talk-se@openstreetmap.org> wrote:

> Hej Andreas, stort tack för feedback! Här är mina kommentarer.
>
> > Exempelvis förekommer Hjortseryd två gånger, med en brytlinje mellan två
> > kartblad mellan dem båda. Kommer sådana dubbletter kollas av?
> Sådan koll kan jag enkelt lägga till i skriptet. Men ditt exempel med
> Hjortseryd
> visar bara att det kan finnas två platser med samma namn på bara 1,16 km
> avstånd.
>
> Här är varför.
> Importsfilerna har tre noder med namn "Hjortseryd":
> tx_07.osm: lat="56.706179333" lon="13.412860079"
> tx_10.osm: lat="56.385103802" lon="15.291224794"
> tx_10.osm: lat="56.374758939" lon="15.292829751"
> En by ligger lång bortifrån andra, och två byar finns nära varandra.
> Här är de på Terrängkartan.
> Alla tre noder: https://i.stack.imgur.com/2hKsL.png
> De två nära: https://i.stack.imgur.com/yWzRN.png
>
> Trots att det verkligen är konstigt att man kallar två närliggande byar
> samma
> namn, är de verkligen två enstaka gårdar, men sina egna gränser osv.
> Även Ekonomiska kartan håller med detta:
> https://i.stack.imgur.com/NpZQw.png
> Nu får man kanske inte kolla på icke-öppna data... Hur som helst, andra
> källor
> tycker också att de är enstaka lika nämnda byar.
> 1. Eniro.se visar samma två byar som "Hjortseryd, ERINGSBODA".
> 2. Hitta.se visar dem som "Hjortseryd, Eringsboda" och "Hjortseryd,
> Ronneby".
>De har till och med olika postnummer.
>
> Oavsett alla bevis kan det ändå bli ett enormt fel i namn, men alla
> partier verkar
> tro på det.
>

Ditt resonemang visar tyvärr att du inte förstår vad datan visar. Det är
vanligt att ortnamn där kartblad bryts visar platsnamnen på båda
kartbladen, och dessa "ortnamn" syftar ofta på hela trakter. Det blir
missvisande att nödvändigtvis tala om dem som byar, samhällen eller
enskilda gårdar. Dessa områden sammanfaller dessutom långt ifrån alltid med
modern kommunindelning. Jag rekommenderar att du sätter dig in i
hemmansbegreppet och de olika skiftesreformer som gjorts i Sverige. Jag vet
att andra kan detta bättre än jag och hoppas de tar chansen att komma med
en mer utförlig förklaring i den här mailtråden.

>
> > Detta har jag gjort genom att rita en farmyard runt gården och sätta
> > name-tagg på denna. Dessa dubbletter måste det kontrolleras mot.
> På detta har jag redan funderat. Det är enkelt att implementera (jag
> utelämnar nu tekniska detaljer om hur), men frågan är om det verkligen
> behövs.
> Jag har sett flera exempel när t ex ett bostadsområde har sitt namn på den
> sträcka som omger det *samt* som en enstaka nod någonstans inuti. Det är
> vettigt
> när områdets logiska center inte sammanfaller med dess geometriskt center.
> Till
> exempel kan ett logiskt center finnas på ett torg medan det geometriska
> centret
> kan hamna i ett skogsparti.
>

Nej, så ska vi inte tagga. Ett objekt ska taggas en gång. Detta är en
grundläggande osm-regel:
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element. Att det
ser ut så på vissa ställen är fel och innebär inte att vi ska göra så på
fler ställen.

Några fler exempel som är fel är Skanörsgården, Falsterbo vång och
Falsterbohus. Den förstnämnda är namnet på ett bostadsområde, den andra är
knappt i allmänt bruk och den tredje syftar på ett känt före detta
badhotell: https://sv.wikipedia.org/wiki/Falsterbohus Något österut ligger
Videholm, som är ett alternativt namn för Lilla Hammar, taggat på samma
plats. Skillnaden mellan dessa yttrar sig främst i äldre
fastighetsindelning som inte är så relevant längre.

>
> > Dessa bör antagligen städas bort, då de naturligtvis inte ska
> > taggas som village eller liknande och datan troligen dubblerar sådant som
> > ligger inlagt med boundary-taggar.
>
> Jag har öppnat tx_01.osm för Stockholm och har laddat ner befintliga
> platser
> (med Overpass-API) för samma område. Här är jämförelsen.
>
> Befintliga data: https://i.stack.imgur.com/BCQ4i.jpg
> De flesta noderna är place=suburb, place=town, bara ett fåtal
> place=village.
>
> Nya data: https://i.stack.imgur.com/8DZn2.jpg
> Hela filen innehåller endast place=isolated_dwelling, place=hamlet
> (småort),
> place=locality och ett fall place=town. Inga place=village alls.
> Småort är ett officiellt begrepp vilket jag tror är rimligt att använda
> även nära
> stora städer: https://sv.wikipedia.org/wiki/Sm%C3%A5ort : "definieras som
> en
> samlad bebyggelse med 50–199 invånare, där det är högst 150 meter mellan
> husen."
> Om du kan förse mig med ett exempel där du tror etiketterna var felvalda
> då kan
> jag försöka åtgärda detta.
>

Jag har tittat i Malmö, Lund, Landskrona och Helsingborg. Samtliga
stadsdelar där är felaktigt angivna, och dessutom redan taggade på annat
sätt. Se ovan om one feature, one osm element. Jag utgår ifrån att det ser
i princip likadant ut i andra större städer. Vissa har ett namn som skiljer
sig något ifrån det namn som är taggat (Kobjärsvången vs Kobjer i Lund
exempelvis, där det

Re: [OSM-legal-talk] New data source

2020-01-17 Per discussione Kathleen Lu via legal-talk

Hi Cj,
Easiest method would be for you to update
https://wiki.openstreetmap.org/wiki/Contributors with this information.
(But please do note the import guidelines if you are thinking about
importing)
Best,
Kathleen

On Thu, Jan 16, 2020 at 5:26 AM Cj Malone  wrote:

> Hello,
>
> I recently saw that some bus stop names are out of date in my area. I
> updated the one I saw (
> https://www.openstreetmap.org/node/533814248/history)
>
> But the local bus operator offers this data under Open Government
> License Version 3.0. (https://www.islandbuses.info/open-data)
>
> As far as I understand it OGL can be used in OSM, but needs
> attribution. Is this correct? How can OSM add the attribution so I can
> start using this dataset?
>
> Once someone verifies that I can use this dataset I intend to correct
> any OSM names, add fixme tags to any this I don't think exist any more.
> And possibly add naptan:AtcoCode=x to nodes that don't have it in OSM
> but do in the Southern Vectis dataset. And add "SouthernVectis" to the
> source tag which would usually mean, source=naptan_import ->
> source=naptan_import;SouthernVectis.
>
> Thanks
> Cj
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Graeme Fitzpatrick

Thanks for putting these up Andrew.

The silly question though is how do we use them? :-)

Thanks

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

Re: [OSM-talk-fr] Trottoir traversant

2020-01-17 Per discussione Florimond Berthoux

Le ven. 17 janv. 2020 à 10:37, marc marc  a
écrit :
>
> Je trouve que tu fais compliqué :)

En bon ingénieur j'énumère toutes les possibilités pour sélectionner la
meilleure à la fin ;)

> une route et un trottoir se croise, donc un nœud d'intersection
> "passage piéton" highway=crossing + crossing=uncontrolled probablement
> pour le niveau de sécurité + crossing_ref=no probablement
> pour le type (lié au marquage en fr be ch) + kerb=no

En fait il y a bien un kerb «A kerb (American English curb) is the edge
where a road meets a sidewalk.» https://wiki.openstreetmap.org/wiki/Key:kerb
Sauf que pour le trottoir traversant c'est la voiture qui se le prend cette
fois, puisque le piéton lui reste sur le trottoir !
Après, on pourrait interpréter le tag comme étant du point de vue du
piéton, mais ce n'est pas définit comme cela.

> si tu veux maintenant ajouter du détail pour dire en linéaire
> la longueur de ce croissement pour chaque usager :
> - pour la voiture, c'est un plateau traffic_calming=table
> sur le way voiture.
> côté voiture, je vois pas de différence entre traverser
> un plateau passage piéton avec marquage (les ""anciens"" trottoir
> traversants qui existent depuis des années) et un plateau
> passe piéton trottoir traversant).
> tout autre tag me semble donc superflu ou erroné.
> est-ce qu'il y a une différence dans la loi ?

Premier point, il y a différent type de trottoir traversant plus ou moins
cassant pour une voiture, alors qu'un plateau traversant c'est bien
réglementé (en France en tout cas).
Second point, sur un plateau traversant il y a toujours une délimitation
route/trottoir même s'ils sont censés être à niveau.
Troisième point légal, en France, une voiture qui traverse un trottoir
traversant traverse un trottoir (eh eh) et doit donc cédez le passage à
tous à l'intersection (Article 415-9
https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=6ED1C96581529BBCE4CD62E5C0D68704.tplgfr41s_3?idArticle=LEGIARTI23095968=LEGITEXT06074228=20200117
)

> - pour le piéton, il y a 2 incohérences dans ce que tu dis.
> la clef crossing sert a décrire le passage piéton (le nœud même
> si certain duplique l'info du passage 3 fois).
> crossing=continuous n'est donc pas une bonne idée pour décrire
> l'étendue du cheminement de voie le composant.
> par ailleurs si tu considères qu'un trottoir traversant est un trottoir,
> alors ce n'est pas un passage piéton, c'est highway=path path=sidewalk
> si c'est pas tout a fait un trottoir (peut-on s'y arrêter pour faire
> ses lacets ou discuter avec un autre pendant 5 min ? j'en doute),
> alors highway=path path=continuous_sidewalk ou qlq chose du genre.

C'est un vrai trottoir et tu peux jouer à la marelle dessus, c'est comme
une entrée charretière, après personne n'a le droit d’empêcher l'autre de
passer ;)
Oui crossing ça veut vraiment dire passage pour traverser la grosse voie
(route, chemin de fer, rivière...).

Et le mot anglais pour intersection c'est ... junction
https://wiki.openstreetmap.org/wiki/Key:junction
«This key describes how a specific junction is constituted. »
Perfect, aujourd'hui utilisé pour les différents rond-point (à priorité à
droite ou à priorité à l'anneau par exemple) donc pour définir à la fois la
forme physique et l'aspect légal.
On peut imaginer :
junction=continuous_sidewalk/continuous_cycleway

Donc je me suis essayé à modéliser ce magnifique trottoir traversant que je
connais bien https://www.openstreetmap.org/#map=19/48.87867/2.35428

Donc deux nœuds d'intersection avec
junction=continuous_sidewalk/continuous_cycleway
https://www.openstreetmap.org/node/652025857
https://www.openstreetmap.org/node/7140053012

Un bout de rue piétonne sur trottoir :
traffic_calming=continuous_sidewalk
highway=pedestrian
pedestrian=sidewalk (cette portion de segment est sur trottoir)
kerb=no
https://www.openstreetmap.org/way/25704593

Une piste cyclable :
cycleway=continuous
highway=cycleway
kerb:left=lowered
kerb:right=flush
https://www.openstreetmap.org/way/764269695

Un chemin piéton :
highway=footway
footway=continuous_sidewalk
kerb:left=lowered
kerb:right=flush
https://www.openstreetmap.org/way/764269695

Avec ça on est blindé :D

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

Re: [Talk-es] Ediciones del usuario Verdy_p, sin consenso con la comunidad española de OSM

2020-01-17 Per discussione Diego Cruz Alonso

Buenas:

Yo también he participado en esta cuestión, como ya he comentado en el grupo de 
Telegram. En mi caso, descubrí que el usuario Verdy_p había eliminado la 
división comarcal que había en la provincia de Ávila, creada por mí y basada en 
las comarcas agrarias, y la había sustituido por el criterio de las comarcas 
turísticas de la diputación de Ávila. Le comenté por correo electrónico que en 
Castilla y León la división comarcal es un tema complejo, ya que la Junta solo 
ha declarado la comarca de El Bierzo como oficial, y que debíamos ponernos de 
acuerdo primero en un criterio de los varios posibles teniendo en cuenta a los 
usuarios locales (en mi opinión, las comarcas de la diputación son un engendro 
poco representativo). Le repetí en dos ocasiones que para ello lo mejor era 
escribir a esta lista y comentar sus intenciones de mapear las comarcas 
españolas (que me parecen fantásticas si lo da a conocer y se siguen unas 
normas consensuadas con otros usuarios), pero hizo caso omiso de todo ello y 
siguió editando a su manera y sin consultar a nadie por otras provincias al 
azar de toda España. Independientemente del criterio que siga, lo que me parece 
mal es que su actitud no es nada colaboradora.

Un saludo
Diego Cruz

El 17/01/2020, a las 19:38, Diego García  escribió:

> Buenas tardes.
> 
> En España, las comarcas son una división del territorio que agrupa a varios 
> municipios. Se intenta, me temo que a veces sin conseguirlo, que se 
> correspondan a la definición de comarca, englobando una zona geográfica que 
> comparte características naturales y humanas comunes, en una jerarquía por 
> debajo de la región. Como tal agrupación de municipios, y establecidas por 
> separado en cada comunidad, se trata de una entidad por encima del municipio 
> pero por debajo de autonomía, al margen de las provincias. Se da el caso de 
> que hay comarcas que incluyen municipios de diferentes provincias, lo que no 
> supone ningún problema a la hora de editar, siempre que dejemos de lado las 
> provincias al trabajar el tema.
> 
> Por ejemplo, la comarca de la Hoya de Huesca, o la de los Monegros (en su 
> mayor parte dentro de la provincia de Huesca), comprenden municipios de 
> Zaragoza, sin que eso suponga un problema. No es necesario fraccionar nada, 
> ni tocar las provincias, ya que son una entidad aparte, que no mantiene una 
> jerarquía con las comarcas. Simplemente establecemos la frontera de las 
> comarcas y las incluímos en la entidad superior, que es la autonomía. Esto es 
> algo que funciona, que es como debe hacerse, y que asumimos así por consenso 
> desde hace años en la comunidad española de OSM.
> 
> Desde hace un par de semanas se vienen sucediendo ediciones del usuario 
> Verdy_p que no están teniendo en cuenta la jerarquía que tienen las comarcas 
> en España. Por ejemplo, en el caso de la comarca de la Hoya de Huesca la ha 
> dividido en dos, estableciendo una "Hoya de Huesca (Zaragoza)" y otra "Hoya 
> de Huesca (Huesca)", que a su vez ha incluído como partes de la relación que 
> ya existía. A todas ellas les ha dado admin_level 7.
> 
> https://www.openstreetmap.org/changeset/79639164
> 
> Podemos decir: "bueno, es una forma de verlo, la edición es correcta". Pero 
> en realidad no lo es, por tres razones:
> 
> - En primer lugar, al establecer varias relaciones con el mismo admin_level 
> triplica la comarca
> - En segundo lugar, se está inventando el name de las relaciones creadas. 
> "Hoya de Huesca (Zaragoza)" no es algo que exista en ninguna parte.
> - En tercer lugar, es totalmente innecesario. El mapa funciona igual de cara 
> a las búsquedas o a la jerarquía de territorios. De hecho, antes funcionaba 
> mejor. Si ahora hacemos una extracción de datos con overpass obtenemos un 
> batiburrillo importante.
> 
> La cuarta razón sería que no es la forma en que la comunidad española ha 
> decidido que se haga. Este usuario ha venido para hacer las cosas a su 
> manera, sin preguntar primero, y esa no es la forma correcta de actuar.
> 
> Visto lo visto, y ya que la comarca de la Hoya de Huesca estaba correctamente 
> editada desde hace años en el mapa, y que soy un editor local conocedor del 
> tema, procedí a revertir el cambio, y a avisar al usuario Verdy_p. Con 
> cambios pequeños se suele avisar primero y esperar a que el mismo editor 
> conteste, pero ante la magnitud del cambio, que afecta a límites 
> administrativos, lo suyo es revertir antes de que el daño sea mayor.
> 
> Los distintos mensajes que fue dejando el usuario Verdy_p en el changeset, 
> subieron de nivel progresivamente. Le he tratado de explicar la situación (yo 
> y otros compañeros): que las comarcas en España existen aparte de la 
> provincias, etc, pero ha seguido a lo suyo. El final ha sido que ha vuelto a 
> editar todo en varios cambios, con lo que ahora revertir ya sería complicado, 
> aparte de que entraríamos en una guerra de ediciones que ha iniciado él.
> 
> Solo aporto el changeset que conozco

Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

2020-01-17 Per discussione Grigory Rechistov via Talk-se


Hej Andreas, stort tack för feedback! Här är mina kommentarer.
 
> Exempelvis förekommer Hjortseryd två gånger, med en brytlinje mellan två
> kartblad mellan dem båda. Kommer sådana dubbletter kollas av?
Sådan koll kan jag enkelt lägga till i skriptet. Men ditt exempel med Hjortseryd
visar bara att det kan finnas två platser med samma namn på bara 1,16 km 
avstånd.
 
Här är varför.
Importsfilerna har tre noder med namn "Hjortseryd":
tx_07.osm: lat="56.706179333" lon="13.412860079"
tx_10.osm: lat="56.385103802" lon="15.291224794"
tx_10.osm: lat="56.374758939" lon="15.292829751"
En by ligger lång bortifrån andra, och två byar finns nära varandra.
Här är de på Terrängkartan.
Alla tre noder:  https://i.stack.imgur.com/2hKsL.png
De två nära:  https://i.stack.imgur.com/yWzRN.png
 
Trots att det verkligen är konstigt att man kallar två närliggande byar samma
namn, är de verkligen två enstaka gårdar, men sina egna gränser osv.
Även Ekonomiska kartan håller med detta: https://i.stack.imgur.com/NpZQw.png
Nu får man kanske inte kolla på icke-öppna data... Hur som helst, andra källor
tycker också att de är enstaka lika nämnda byar.
1. Eniro.se visar samma två byar som "Hjortseryd, ERINGSBODA".
2. Hitta.se visar dem som "Hjortseryd, Eringsboda" och "Hjortseryd, Ronneby".
   De har till och med olika postnummer.
 
Oavsett alla bevis kan det ändå bli ett enormt fel i namn, men alla partier 
verkar
tro på det.
 
> Detta har jag gjort genom att rita en farmyard runt gården och sätta
> name-tagg på denna. Dessa dubbletter måste det kontrolleras mot.
På detta har jag redan funderat. Det är enkelt att implementera (jag
utelämnar nu tekniska detaljer om hur), men frågan är om det verkligen behövs.
Jag har sett flera exempel när t ex ett bostadsområde har sitt namn på den
sträcka som omger det *samt* som en enstaka nod någonstans inuti. Det är vettigt
när områdets logiska center inte sammanfaller med dess geometriskt center. Till
exempel kan ett logiskt center finnas på ett torg medan det geometriska centret
kan hamna i ett skogsparti.
 
> Dessa bör antagligen städas bort, då de naturligtvis inte ska
> taggas som village eller liknande och datan troligen dubblerar sådant som
> ligger inlagt med boundary-taggar.
 
Jag har öppnat tx_01.osm för Stockholm och har laddat ner befintliga platser
(med Overpass-API) för samma område. Här är jämförelsen.
 
Befintliga data:  https://i.stack.imgur.com/BCQ4i.jpg
De flesta noderna är place=suburb, place=town, bara ett fåtal place=village.
 
Nya data:  https://i.stack.imgur.com/8DZn2.jpg
Hela filen innehåller endast place=isolated_dwelling, place=hamlet (småort),
place=locality och ett fall place=town. Inga place=village alls.
Småort är ett officiellt begrepp vilket jag tror är rimligt att använda även 
nära
stora städer: https://sv.wikipedia.org/wiki/Sm%C3%A5ort : "definieras som en
samlad bebyggelse med 50–199 invånare, där det är högst 150 meter mellan husen."
Om du kan förse mig med ett exempel där du tror etiketterna var felvalda då kan
jag försöka åtgärda detta.
 
> I Lund såg jag att "Norra Fäladen" radbrutits och detta gjort att datan av
> någon anledning blivit dubblerad, med en place-tagg med namn "Norra" och en
> med namn "Fäladen".
Orsaken till detta förklarades i importplanen. Eventuell radbrytning är åtgärdad
i skriptet, jag behöver lära det känna igen fler mönster. Det kommer jag att 
göra.
 
> "Gullåkra" har inte fått träff mot "Gullåkra by", trots att noderna är
> placerade nästan på varandra.
Jag har sökt i Internet, och det verkar att "Gullåkra by" inte är byns
officiella namn, däremot är "Gullåkra" det korrekta namnet. Importen kan
inte rätta mänskliga fel i befintliga data, men den kan hjälpa med att upptäcka
dem, precis som du har gjort.
 
> efter att ha tvättat den i områden de har hyfsad lokalkännedom så
> de kan bedöma datans lämplighet.
Hela poängen i vilken import finns i att man inte behöver personligen undersöka
en plats. Istället använder man information samlad av myndigheterna (för vilket
betalar man skatt för, bland annat). Värför spendera hundratals människaår 
ideella
arbete för att kartlägga samtliga ortnamn när Lantmäteriet redan har spenderat
massor tid och pengar på detta?
 
Det kommer säkert att förekomma enstaka fel i importdatan, men fördelar
överstiger betydligt nackdelar. Låt mig illustrera det med siffror.
 
Sveriges OSM-kartan har just nu ungefär 68000 noder med ortnamn. Lantmäteriets 
data
innehåller cirka 154000 ortnamn. Om vi föreställer oss att Lantmäteriet känner
samtliga ortnamn, betyder det att OSM-kartan saknar 86000 noder,
eller har 55% fel. Då räknar jag en utebliven nod som fel. Här struntar vi i
OSM:s befintliga stavfel, positionsfel osv., annars skulle förhållandet ha 
blivit
ännu värre.
 
När vi importerar nya noder kommer vi säkert introducera nya fel:
dubbletter, felstavningar osv. Låt oss föreställa oss att importen går såpass
dåligt att vi introducerar 1% fel på nya noder. Det betyder att vi lägger till
860 nya fel in i

[talk-cz] Podcast o Mapy.cz (i OSM)

2020-01-17 Per discussione Pavel Zbytovský

Ahoj,

tip na něco k poslechu: rozhovor s Martinem Jeřábkem šéfem Mapy.cz, asi 5
minut slávy dostalo i OpenStreetMap. Zmíněna byla třeba dobrá spolupráce s
komunitou.
Zaujal mě ještě ve výhledu plán na přidání možnosti editace přímo do
Mapy.cz.

https://www.miton.cz/blog/podcast-s-mapy-cz-o-zahranicnich-ambicich-a-co-to-obnasi-delat-takto-dobry-produkt


Pavel
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk-be] Infrabel Open Data

2020-01-17 Per discussione Stijn Rombauts via Talk-be

Hi,
There is this page (1), which has a wealth of interesting information for those 
who want to waste their time updating, improving and correcting the railway 
related things in OSM. As far as I can see the licence is OK, except for point 
5.1.6 which requires us to mention the Open Data Infrabel-platform as a source, 
with the date of the last update. But does it suffice to add them to this page 
(2)? Perhaps with ... "These data are being updated continuously." ;-)
Regards,
StijnRR


(1) https://opendata.infrabel.be(2) 
https://wiki.openstreetmap.org/wiki/Contributors#Belgium





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

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Per discussione john whelan

Pierre looking at the Microsoft imports south of the border and their
process is undoubtedly sensible.

I suggest waiting until we have got some movement on the current import
rather than try to tackle to many things at once.

Cheerio John

On Fri, Jan 17, 2020, 1:47 PM Pierre Béland,  wrote:

> John,
>
> Exprime tu simplement une opinion, ou as-tu vérifié les procédures
> d'import incluant correction des données et validé la qualité des données
> importées aux États-Unis ? Considères-tu la qualité des données dans la
> base OSM aux États-Unis comparable à ce qui s'est fait au Canada l'an
> dernier ?
>
> La qualité des données Microsoft peut sans doute varier selon divers
> facteurs dont la qualité et précision des données aériennes utilisées.
>
> De mon côté, j'ai regardé du côté de Dallas, Texas. En consultant le
> gestionnaire de tâches US, il est possible d'y repérer les tâches créées
> pour cartographier des bâtiments.
>
> https://tasks.openstreetmap.us/contribute?difficulty=ALL=ARCHIVED=BUILDINGS
>
> Dans ces zones, j'ai constaté en général une bonne qualité des données.
> Je ne connais pas les procédures utilisées, ni regardé le connu des
> fichiers de données Microsoft pour ces zones, mais la tâche ci-dessous
> montre un processus de validation où il était demandé d'orthogonaliser les
> bâtiments.
> https://tasks.openstreetmap.us/project/164#bottom
>
> Pierre
>
>
> Le vendredi 17 janvier 2020 13 h 02 min 20 s UTC−5, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> > As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM.
>
> Well yes that is one opinion but we do have a range of opinions in
> OpenStreetMap and from the number of buildings that have already been
> imported into OpenStreetMap from Microsoft, there seems to be a large
> number in the US for example, it would appear there are those who disagree
> with you which is not surprising given the number of mappers.
>
> To me the buildings are of more interest once they get enriched with more
> tags and the place that happens is in OpenStreetMap.  Streetcomplete I
> think is either the most popular editor these days or very close to it.
> You can't add tags if the buildings are not in OpenStreetMap.  Yes you can
> display the outlines by using the Microsoft data but that does not show
> tags such as building type, building levels, etc etc. and streetcomplete is
> a tool that can be used to introduce OpenStreetMap to many people.
>
> I think perhaps we should concentrate our efforts on the current import
> for the moment but I suspect that some Microsoft buildings will start to be
> imported in Canada even if they don't have an official import plan.
>
> Cheerio John
>
>
> On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:
>
> Hi John,
>
> As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM. If you just want to display buildings, you can
> download the MS dataset and use it right away - no need to import into
> OSM. I think, the MS dataset has value as proof of concept and to count
> the number of buildings in a given area (e.g. to estimate market size
> for roofers, estimate number of persons living there for desaster
> relief, etc.). I also think, when Microsoft feeds its algorithm with
> higher resolution data than they did (I don't recall, but I think they
> only used the regular Bing data) they will probably end up with building
> footprints that will meet our/my quality requirements for import into
> OSM one day.
>
> For me, the value of OSM is having accurate information in terms of tags
> and geometry. Otherwise, we could join Wikimapia; they don't care too
> much about geometry accuracy but emphasize on content/tags of objects.
> Pretty interesting project, but different from OSM.
>
> Cheers,
> Tim
>
> On 2020-01-17 10:40, john whelan wrote:
>   >first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset)
>
> I can't resist.  Does this infer that for parts of the country without
> Stat Can data we are happy to import Microsoft dataset buildings as is?
> Or would we wish to wait until we have some more imports done before
> looking at preprocessing them in some way first.
>
> Thanks John
>
>
>
> On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  > wrote:
>
>  I would assume in most cases the imported building footprint will be
>  more precise than existing data. For me, this would be a reason to
>  replace already existing objects. However, I think this is a case by
>  case decision. However, I think it is important to keep tags and
>  history
>  of buildings already existent in OSM. This is how I would
>  read/interpret
>  the import guideline stated by Nate: "If you are importing data where
>

Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

2020-01-17 Per discussione Micke via Talk-se

Hej!

För herrgårdar kanske man kan passa på att lägga till historic=manor samtidigt.
Det finns nog en del sådana herrgårdar inlagda redan. Men då ligger nog taggen 
på huset eller på gården, inte på en nod. Bara så att det inte blir dubbletter 
där.

Vi har ju även en hel del ställen som har ett namn, men där det är ödehus eller 
sommarstugor eller fäbodar. Dessa borde även de klassas som locality.

Stadsdelar bör väl inte vara hamlet, utan neighbourhood?


Mvh

Anders Andersson

Från: Grigory Rechistov 
Skickat: den 16 januari 2020 18:19
Till: talk-se 
Ämne: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

Hej!
Jag har extraherat de ortnamn som nu saknas på Sveriges OSM-karta ifrån 
Lantmäteriets öppna data, daterade januari 2020. Det finns ungefär 95 tusen nya 
noder med namn och "place=*"-etiketter vilka jag så småningom hoppas ladda upp 
till OSM.

En såpass stor mängd nya data kräver att man följer vissa procedurer och 
förbereder vissa dokument. Jag hoppas att få er feedback och eventuell hjälp 
med valideringen, uppladdningen och med andra eventuella uppdrag.

Här finns importplan för projektet [1] på OSM-wikin. Den beskriver 
informationens härkomst, licens och format. Sedan beskriver jag hur de 
ursprungliga filerna bearbetas, hur nya punkter filtreras mot den befintliga 
OSM-databasen, hur ortnamn rensas och jämföras, vilka skript och program 
används vid alla steg osv. Till sist uppger jag vilka problem kvarstår att lösa 
under manuell bearbetning.

Importplanens bitar med viktigaste sektioner bifogar jag längst ner. Här är 
också en mindre bit av hela datasetet om du vill se hur det ska se ut: [2] [3]. 
Andra länkar till Lantmäteriets dokumentation, mina utvecklade skript, samtliga 
OSM-filer, kalkylblad osv finns på importplanens sida.

Tack!

[1] 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Lantm%C3%A4teriet_GSD-Terr%C3%A4ngkartans_ortnamnsimport
[2] https://drive.google.com/open?id=1np1TEDlEBWx1kt-u7A4Z_ZpkMOwOp80l
[3] https://drive.google.com/open?id=1pERx-U4rdOjhXmePoSxcbKRZsr-preh8

Importplanens utdrag följer.

===Goal===
To improve OSM completeness for toponymical dataset on territory Sweden using
an official map supplied by Swedish mapping, cadastral and land registration 
authority.
This import considers OSM data representable as nodes tagged with usual
key/value pairs: "place=city", "place=town", "place=village", "place=hamlet",
"place=isolated_dwelling", and "place=locality". However, it is not planned
(but not fully excluded either) to add/modify any nodes with "city" and "town"
values. They are expected to be already fully mapped.

 Data processing diagram 
See the diagram below. The conflation stage is described later in more details.
+---++--+
|   ||  |
|Lantmäteriet's SHP ||Geofabrik country |
|files  ||extract   |
|   ||  |
+-+-+++-+
  |   |
  |ogr2osm|osmconvert
  |   |osmfilter
  v   v
 ++-+ +---+-+
 |  | | |
 |OSM file with | |OSM fiele with   |
 |settlements   | |settlements  |
 |  | | |
 +-++ +---+-+
   |  |
   |  |
   | conflate-places.py   |
   +<--
   v
  +++
  | |
  |OSM file with|
  |only ready nodes |
  | |
  +++
   |
   | Manual corrections
   |
   v
Upload to JOSM


The employed algorithm operates on a set of old nodes marked with "place=*"
(from the OSM-extract, around 68 000 nodes for the country) and new nodes
(from SHP-extract). It produces ready nodes — a strict subset of new nodes.
No old nodes are modified in any way during the process. This means that 
existing
data has absolute priority, even in cases it is likely of lower quality than
new data.
The sequence of steps is as following.
1. Create a spatial index structure with old nodes to have fast spatial lookup.
2. For all new nodes validation/correction of the "name" tag is performed.
3. For each new node, find old nodes close enough to it to be candidate for 
duplicates.
4. For each candidate node, compare its name against the current new node name.
   Comparison is fuzzy to allow for some text variation typical for names.
   Alternative old names are also checked if present.
5. If a name match is found, the current new node is marked as "duplicate" and
   is excluded from further analysis and results.
6. An OSM file with ready data is generated.
7. The OSM file is

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Per discussione Pierre Béland via Talk-ca

John,
Exprime tu simplement une opinion, ou as-tu vérifié les procédures d'import 
incluant correction des données et validé la qualité des données importées aux 
États-Unis ? Considères-tu la qualité des données dans la base OSM aux 
États-Unis comparable à ce qui s'est fait au Canada l'an dernier ? 

La qualité des données Microsoft peut sans doute varier selon divers facteurs 
dont la qualité et précision des données aériennes utilisées.
De mon côté, j'ai regardé du côté de Dallas, Texas. En consultant le 
gestionnaire de tâches US, il est possible d'y repérer les tâches créées pour 
cartographier des bâtiments.
https://tasks.openstreetmap.us/contribute?difficulty=ALL=ARCHIVED=BUILDINGS
Dans ces zones, j'ai constaté en général une bonne qualité des données.  Je ne 
connais pas les procédures utilisées, ni regardé le connu des fichiers de 
données Microsoft pour ces zones, mais la tâche ci-dessous montre un processus 
de validation où il était demandé d'orthogonaliser les 
bâtiments.https://tasks.openstreetmap.us/project/164#bottom 
Pierre 

Le vendredi 17 janvier 2020 13 h 02 min 20 s UTC−5, john whelan 
 a écrit :  

 > As stated before, I don't consider the Microsoft dataset being close tothe 
 >minimum quality requirements I would expect from any automated
building entry into OSM.
Well yes that is one opinion but we do have a range of opinions in 
OpenStreetMap and from the number of buildings that have already been imported 
into OpenStreetMap from Microsoft, there seems to be a large number in the US 
for example, it would appear there are those who disagree with you which is not 
surprising given the number of mappers.
To me the buildings are of more interest once they get enriched with more tags 
and the place that happens is in OpenStreetMap.  Streetcomplete I think is 
either the most popular editor these days or very close to it.  You can't add 
tags if the buildings are not in OpenStreetMap.  Yes you can display the 
outlines by using the Microsoft data but that does not show tags such as 
building type, building levels, etc etc. and streetcomplete is a tool that can 
be used to introduce OpenStreetMap to many people.
I think perhaps we should concentrate our efforts on the current import for the 
moment but I suspect that some Microsoft buildings will start to be imported in 
Canada even if they don't have an official import plan.
Cheerio John 

On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:

Hi John,

As stated before, I don't consider the Microsoft dataset being close to 
the minimum quality requirements I would expect from any automated 
building entry into OSM. If you just want to display buildings, you can 
download the MS dataset and use it right away - no need to import into 
OSM. I think, the MS dataset has value as proof of concept and to count 
the number of buildings in a given area (e.g. to estimate market size 
for roofers, estimate number of persons living there for desaster 
relief, etc.). I also think, when Microsoft feeds its algorithm with 
higher resolution data than they did (I don't recall, but I think they 
only used the regular Bing data) they will probably end up with building 
footprints that will meet our/my quality requirements for import into 
OSM one day.

For me, the value of OSM is having accurate information in terms of tags 
and geometry. Otherwise, we could join Wikimapia; they don't care too 
much about geometry accuracy but emphasize on content/tags of objects. 
Pretty interesting project, but different from OSM.

Cheers,
Tim

On 2020-01-17 10:40, john whelan wrote:
  >first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without
Stat Can data we are happy to import Microsoft dataset buildings as is?
Or would we wish to wait until we have some more imports done before
looking at preprocessing them in some way first.

Thanks John

On Thu, Jan 16, 2020, 10:11 PM Tim Elrick, mailto:o...@elrick.de>> wrote:

     I would assume in most cases the imported building footprint will be
     more precise than existing data. For me, this would be a reason to
     replace already existing objects. However, I think this is a case by
     case decision. However, I think it is important to keep tags and
     history
     of buildings already existent in OSM. This is how I would
     read/interpret
     the import guideline stated by Nate: "If you are importing data where
     there is already some data in OSM, then *you need to combine this data*
     in an appropriate way or suppress the import of features with overlap
     with existing data." (emphasis added by me)

     However, that just means, the import, hence, is nothing easy and could
     not be achieve quickly, I would assume. One way of making sure that
     this
     is dealt with diligently, would be setting the tasking manager to
     'experienced mappers only'. We

[Talk-es] Ediciones del usuario Verdy_p, sin consenso con la comunidad española de OSM

2020-01-17 Per discussione Diego García

Buenas tardes.

En España, las comarcas son una división del territorio que agrupa a varios
municipios. Se intenta, me temo que a veces sin conseguirlo, que se
correspondan a la definición de comarca, englobando una zona geográfica que
comparte características naturales y humanas comunes, en una jerarquía por
debajo de la región. Como tal agrupación de municipios, y establecidas por
separado en cada comunidad, se trata de una entidad por encima del
municipio pero por debajo de autonomía, al margen de las provincias. Se da
el caso de que hay comarcas que incluyen municipios de diferentes
provincias, lo que no supone ningún problema a la hora de editar, siempre
que dejemos de lado las provincias al trabajar el tema.

Por ejemplo, la comarca de la Hoya de Huesca, o la de los Monegros (en su
mayor parte dentro de la provincia de Huesca), comprenden municipios de
Zaragoza, sin que eso suponga un problema. No es necesario fraccionar nada,
ni tocar las provincias, ya que son una entidad aparte, que no mantiene una
jerarquía con las comarcas. Simplemente establecemos la frontera de las
comarcas y las incluímos en la entidad superior, que es la autonomía. Esto
es algo que funciona, que es como debe hacerse, y que asumimos así por
consenso desde hace años en la comunidad española de OSM.

Desde hace un par de semanas se vienen sucediendo ediciones del usuario
Verdy_p que no están teniendo en cuenta la jerarquía que tienen las
comarcas en España. Por ejemplo, en el caso de la comarca de la Hoya de
Huesca la ha dividido en dos, estableciendo una "Hoya de Huesca (Zaragoza)"
y otra "Hoya de Huesca (Huesca)", que a su vez ha incluído como partes de
la relación que ya existía. A todas ellas les ha dado admin_level 7.

https://www.openstreetmap.org/changeset/79639164

Podemos decir: "bueno, es una forma de verlo, la edición es correcta". Pero
en realidad no lo es, por tres razones:

- En primer lugar, al establecer varias relaciones con el mismo admin_level
triplica la comarca
- En segundo lugar, se está inventando el name de las relaciones creadas.
"Hoya de Huesca (Zaragoza)" no es algo que exista en ninguna parte.
- En tercer lugar, es totalmente innecesario. El mapa funciona igual de
cara a las búsquedas o a la jerarquía de territorios. De hecho, antes
funcionaba mejor. Si ahora hacemos una extracción de datos con overpass
obtenemos un batiburrillo importante.

La cuarta razón sería que no es la forma en que la comunidad española ha
decidido que se haga. Este usuario ha venido para hacer las cosas a su
manera, sin preguntar primero, y esa no es la forma correcta de actuar.

Visto lo visto, y ya que la comarca de la Hoya de Huesca estaba
correctamente editada desde hace años en el mapa, y que soy un editor local
conocedor del tema, procedí a revertir el cambio, y a avisar al usuario
Verdy_p. Con cambios pequeños se suele avisar primero y esperar a que el
mismo editor conteste, pero ante la magnitud del cambio, que afecta a
límites administrativos, lo suyo es revertir antes de que el daño sea mayor.

Los distintos mensajes que fue dejando el usuario Verdy_p en el changeset,
subieron de nivel progresivamente. Le he tratado de explicar la situación
(yo y otros compañeros): que las comarcas en España existen aparte de la
provincias, etc, pero ha seguido a lo suyo. El final ha sido que ha vuelto
a editar todo en varios cambios, con lo que ahora revertir ya sería
complicado, aparte de que entraríamos en una guerra de ediciones que ha
iniciado él.

Solo aporto el changeset que conozco de primera mano. Me consta que el
usuario lleva varios días haciendo cambios semejantes por toda España,
siendo apercibido por ello, y haciendo caso omiso a la comunidad española.
Hay autonomías en las que la comarcalización no funciona, y que por tanto
decidieron en su día no trasladar algo que en la práctica no existe al
mapa. Los demás pensamos que están en su derecho y que son soberanos en
ello, no veo porqué tiene que venir alguien que no pertenece a nuestra
comunidad a imponer otro criterio, cuando el nuestro no contraviene ninguna
norma.

Me parece una pena que un editor tan activo como Verdy_p, y con cierta
antigüedad, se dedique a entrar en estas guerras, a destruir en vez de
aportar. En el caso de Aragón, tenemos una buena parte de Zaragoza y Teruel
sin crear sus comarcas, por lo que si se hubiera limitado a terminar el
trabajo, siguiendo las reglas locales, ahora mismo le estaría aplaudiendo.
Si haces algo mal, y te lo dicen, lo siguiente es escuchar lo que te dicen,
y esto no ha ocurrido. Como podeis ver por el changeset, no escucha, sólo
vale su criterio. Y si nos asomamos por otros lugares, la wiki por ejemplo,
vemos que su comportamiento viene de lejos.
https://wiki.openstreetmap.org/wiki/User_talk:Verdy_p#Blocked

Escribo a la lista para que mis compañeros puedan aportar algo más sobre el
tema, y para decidir qué acciones tomar, en caso de que lo estimemos
necesario, de cara a que el usuario Verdy_p desista en su comportamiento.

[OSM-talk] Fw: Tag:man_made=embankment

2020-01-17 Per discussione 80hnhtv4agou--- via talk


https://images.mapillary.com/OR647SzuJq0jLdhjh11NPQ/thumb-2048.jpg
 
https://images.mapillary.com/8AJ7o4ghSn0bbbirzyGDjQ/thumb-2048.jpg
 
https://www.mapillary.com/app/?menu=false=42.10351713533632=-87.80883149331984=19=Mapillary+satellite=P77555uCkIouYUyCgAFrBQ=photo=0.4865837394142641=0.4173783325586562=0
 
From: Janko Mihelić
Sent: Friday, January 17, 2020 11:27 AM
To: 80hnhtv4a...@bk.ru
Cc: Talk Openstreetmap
Subject: Re: [OSM-talk] Tag:man_made=embankment
 
On Fri, Jan 17, 2020, 16:12 < 80hnhtv4a...@bk.ru > wrote:
>yes the flat, but at the top is a golf coarse and or a sports field and there 
>are several flats on the way up.
> 
>but in the case of a hole in the ground, storm water dry pound ???
 
I didn't quite understand the first sentence. Could you show a photo of the 
place?
 
As for a hole in the ground, it would look like this:
https://www.openstreetmap.org/#map=18/45.49430/15.55295
 
A circle with v's pointing inside.
> 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Postal areas (was Too subjective & problematic Re: no-go-areas)

2020-01-17 Per discussione Martin Trautmann via talk

On 20-01-14 01:34, Joseph Eisenberg wrote:
> In the USA a postal code is not actually an area, but a set of
> addresses. Often they are all in one area, but sometimes the area is
> not clearly defined. This is partially why postal codes are usually
> just added to the POI directly in the USA. Trying to make a sensible
> set of areas or boundaries will not work for all USPS postal codes.

In Austria you may have postal areas and different single postal codes
within.

That's due to the alpine surface: certain houses can not be reached
directly, but from certain roads and paths only. The houses have
different postal codes to the area around.

Thus the Austrian post office very early had an online system where you
could check for the postal code of a certain address.

Maybe this will change with drones some day :-)
Martin

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

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Per discussione john whelan

> As stated before, I don't consider the Microsoft dataset being close to
the minimum quality requirements I would expect from any automated
building entry into OSM.

Well yes that is one opinion but we do have a range of opinions in
OpenStreetMap and from the number of buildings that have already been
imported into OpenStreetMap from Microsoft, there seems to be a large
number in the US for example, it would appear there are those who disagree
with you which is not surprising given the number of mappers.

To me the buildings are of more interest once they get enriched with more
tags and the place that happens is in OpenStreetMap.  Streetcomplete I
think is either the most popular editor these days or very close to it.
You can't add tags if the buildings are not in OpenStreetMap.  Yes you can
display the outlines by using the Microsoft data but that does not show
tags such as building type, building levels, etc etc. and streetcomplete is
a tool that can be used to introduce OpenStreetMap to many people.

I think perhaps we should concentrate our efforts on the current import for
the moment but I suspect that some Microsoft buildings will start to be
imported in Canada even if they don't have an official import plan.

Cheerio John


On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:

> Hi John,
>
> As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM. If you just want to display buildings, you can
> download the MS dataset and use it right away - no need to import into
> OSM. I think, the MS dataset has value as proof of concept and to count
> the number of buildings in a given area (e.g. to estimate market size
> for roofers, estimate number of persons living there for desaster
> relief, etc.). I also think, when Microsoft feeds its algorithm with
> higher resolution data than they did (I don't recall, but I think they
> only used the regular Bing data) they will probably end up with building
> footprints that will meet our/my quality requirements for import into
> OSM one day.
>
> For me, the value of OSM is having accurate information in terms of tags
> and geometry. Otherwise, we could join Wikimapia; they don't care too
> much about geometry accuracy but emphasize on content/tags of objects.
> Pretty interesting project, but different from OSM.
>
> Cheers,
> Tim
>
> On 2020-01-17 10:40, john whelan wrote:
>   >first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset)
>
> I can't resist.  Does this infer that for parts of the country without
> Stat Can data we are happy to import Microsoft dataset buildings as is?
> Or would we wish to wait until we have some more imports done before
> looking at preprocessing them in some way first.
>
> Thanks John
>
>
>
> On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  > wrote:
>
>  I would assume in most cases the imported building footprint will be
>  more precise than existing data. For me, this would be a reason to
>  replace already existing objects. However, I think this is a case by
>  case decision. However, I think it is important to keep tags and
>  history
>  of buildings already existent in OSM. This is how I would
>  read/interpret
>  the import guideline stated by Nate: "If you are importing data where
>  there is already some data in OSM, then *you need to combine this
> data*
>  in an appropriate way or suppress the import of features with overlap
>  with existing data." (emphasis added by me)
>
>  However, that just means, the import, hence, is nothing easy and could
>  not be achieve quickly, I would assume. One way of making sure that
>  this
>  is dealt with diligently, would be setting the tasking manager to
>  'experienced mappers only'. We would have to ask James, who is in
>  charge
>  of the Canada Tasking Manager, how to edit/set up the 'experienced
>  mapper role' in the TM. It might be possible to feed in a list of
>  mappers manually or to set a threshold of objects/changesets that they
>  must have entered in OSM. However, maybe only mappers who feel
>  experienced enough to handle the import would contribute to the TM
>  project anyway and we let everyone judge on their own and don't
>  restrict
>  access.
>
>  If we were to separate the new and overlapping buildings, I am also
>  leaning towards Daniel's assessment. I would be afraid to cause more
>  issues than by doing it all at once (with a reasonable tile size, of
>  course).
>
>  In the end, the main point of importing this specific dataset fulfils
>  two purposes, in my opinion: first, to add missing buildings (if it
>  were
>  just for this purpose we could also use the much bigger Microsoft
>  dataset), second, to get the best geospatial representation

Re: [OSM-talk-fr] Live HS - lié au lag de osm108 ? lui même lié aux modifs de nombreuses relations communales ?

2020-01-17 Per discussione Cédric Frayssinet


Merci Jocelyn pour avoir remis à temps le serveur en fonctionnement.

Ce matin, j'ai eu droit à des wouahh, tout ça (en voyant le nombre de
contributeurs en quelques dizaines de minutes), mais ils sont payés tous
ces contributeurs ?

Bref, c'est un service indispensable pour une présentation rapide sur OSM.

Cédric

Le 17/01/2020 à 13:08, Jocelyn Jaubert a écrit :
> Bonjour,
>
> On Wed, Jan 15, 2020 at 05:38:51PM +0100, Cédric Frayssinet wrote:
 Je voulais présenter le live à mes élèves aujourd'hui mais cela semble
 casser. Ce matin, c'était très lent, actuellement, il ne fonctionne
 pas.

 https://live.openstreetmap.fr/
>>> il y a du lag dans la generation des diffs dans l'infra osm-fr
>>> http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html
>>> qui semble caussé par le traitement des modifs des relations communales.
> En fait, je crois que c'était plutôt causé à un souci sur la VM, qui saturait
> en mémoire. Je l'ai redémarré, et c'est reparti correctement.
>
>>> De mémoire, live utilise les diffs depuis le serveur ci-dessus.
>>> Jocelyn avait prévu un moyen de les contourner en cas de lag
>>> Je le prévient.
> live pointait déjà sur les diffs d'osm.org. J'ai quand même modifié la config 
> du serveur pour:
>   - prendre les diffs par défaut depuis osm-fr
>   - si le dernier diff est <= au précédent, alors récupérer les diffs depuis 
> osm.org
>
>
> Ça devrait corriger tout souci futur dans le cas de délai sur la génération 
> des diffs d'osm-fr.
>
>
> Merci,
> Jocelyn
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [Talk-it] Corso di formazione OpenStreetMap per docenti (e non)

2020-01-17 Per discussione Alessandro Sarretta


Grazie Canfe,

puoi spiegare in modo più esteso per favore? Non ho presente di cosa si 
parla e come vorresti applicarlo a OSM.


Ale

On 17/01/20 17:35, canfe wrote:

Ne approfitto per un suggerimento:
da tempo suggerisco al mondo OSM di fare dei corsi simili in campo medico.
Ormai "bisogna" fare dei corsi, detti ECM, ed acquisire dei punti...
Se ci si potesse aprire al mondo ospedaliero si avrebbe sicuramente un ampio
uditorio.

Per chi volesse approfondire posso rendermi disponibile anche
telefonicamente.



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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


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

Re: [OSM-talk] Tag:man_made=embankment

2020-01-17 Per discussione Janko Mihelić

On Fri, Jan 17, 2020, 16:12 <80hnhtv4a...@bk.ru> wrote:

> yes the flat, but at the top is a golf coarse and or a sports field and
> there are several flats on the way up.
>
> but in the case of a hole in the ground, storm water dry pound ???
>

I didn't quite understand the first sentence. Could you show a photo of the
place?

As for a hole in the ground, it would look like this:
https://www.openstreetmap.org/#map=18/45.49430/15.55295

A circle with v's pointing inside.

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

Re: [Talk-se] Ortnamnsimport från Lantmäte?=riets =?utf-8?Q?GSD-Terr =?utf-8?Q?=C3=A4ngkarta?=n

2020-01-17 Per discussione Johan

Jag har också kollat i "mitt" område och det verkar som ett användbart dataset, 
även om jag själv hade föredragit en adress-import. Gissar att merparten av de 
nya namnen inte längre används i vardagen. Vissa platser ser mer ut som 
"locality" medan några namn har helt klart felakigt blivit "hamlet" fast det 
bara är en gård, om ens det. Men sådant gårt fort att städa.

Jag ser att platser som redan finns i OSM har sorterats bort, och på den 
fronten ser allt väldigt bra ut.
Efter lite bearbetning så kan det importeras i OSM (i "mitt" område) efter min 
bedöming. Måste bara avklaras med mina "grannar" eftersom tiles-filerna 
överlappar lite.

Alternativt kan man importera från hela kommunfilen. Är det i såna fall möjligt 
att genereras nya filer efterhand, så man ser vad som blir till övers på slutet?

Jag har i alla fall satt mitt namn på de tiles i spreadsheetet som jag har för 
avsikt att ansvara för. Jag väntar dock tills importen når allmän acceptans här 
innan jag börjar.

mvh
Johan / 

On 16 January 2020 at 22:17:08 +01:00, Andreas Vilén  
wrote:

> Tack!
> 
> Jag har granskat lite till och har lite kommentarer.
> 
> *I Skåne har jag taggat gårdar med de namn som finns på Ekonomiska kartan. 
> Detta har jag gjort genom att rita en farmyard runt gården och sätta 
> name-tagg på denna. Dessa dubbletter måste det kontrolleras mot.
> *I städerna ser det ut som att det gjorts ett slumpmässigt urval av 
> stadsdelar. Dessa bör antagligen städas bort, då de naturligtvis inte ska 
> taggas som village eller liknande och datan troligen dubblerar sådant som 
> ligger inlagt med boundary-taggar.
> *I Lund såg jag att "Norra Fäladen" radbrutits och detta gjort att datan av 
> någon anledning blivit dubblerad, med en place-tagg med namn "Norra" och en 
> med namn "Fäladen".
> *"Gullåkra" har inte fått träff mot "Gullåkra by", trots att noderna är 
> placerade nästan på varandra.
> 
> Jag tror det kan finnas en poäng att arbeta med den här datan, men att den 
> tillgängliggörs för nerladdning för användare som med eget omdöme laddar upp 
> datan efter att ha tvättat den i områden de har hyfsad lokalkännedom så de 
> kan bedöma datans lämplighet.
> 
> Jag tror inte det är lämpligt att importera det här datasetet.
> 
> 
> On Thu, Jan 16, 2020 at 9:18 PM Grigory Rechistov via Talk-se 
> <> wrote:
> 
> > Här är länken till samtliga filer, version 
> > 9:
> > Mappen "regions" innehåller OSM-filer som motsvarar till Lantmäteriets 
> > områdeskoder, i mappen "tiles" blev de delade i mindre rutor.
> > 
> > 
> > I versionen 9 åtgärdade jag även ytterligare förkortningar som träffades, t 
> > ex "V Kroken" blir till "Västra Kroken".
> > 
> > 
> > 
> > 
> > 
> > Med vänliga hälsningar,
> > Grigory Rechistov
> > With best regards,
> > Grigory Rechistov
> > 
> > ___
> > Talk-se mailing list
> > 
> > 
> > 
> > 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> 
> 

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

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Per discussione Tim Elrick


Hi John,

As stated before, I don't consider the Microsoft dataset being close to 
the minimum quality requirements I would expect from any automated 
building entry into OSM. If you just want to display buildings, you can 
download the MS dataset and use it right away - no need to import into 
OSM. I think, the MS dataset has value as proof of concept and to count 
the number of buildings in a given area (e.g. to estimate market size 
for roofers, estimate number of persons living there for desaster 
relief, etc.). I also think, when Microsoft feeds its algorithm with 
higher resolution data than they did (I don't recall, but I think they 
only used the regular Bing data) they will probably end up with building 
footprints that will meet our/my quality requirements for import into 
OSM one day.


For me, the value of OSM is having accurate information in terms of tags 
and geometry. Otherwise, we could join Wikimapia; they don't care too 
much about geometry accuracy but emphasize on content/tags of objects. 
Pretty interesting project, but different from OSM.


Cheers,
Tim

On 2020-01-17 10:40, john whelan wrote:
 >first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without
Stat Can data we are happy to import Microsoft dataset buildings as is?
Or would we wish to wait until we have some more imports done before
looking at preprocessing them in some way first.

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick, mailto:o...@elrick.de>> wrote:

I would assume in most cases the imported building footprint will be
more precise than existing data. For me, this would be a reason to
replace already existing objects. However, I think this is a case by
case decision. However, I think it is important to keep tags and
history
of buildings already existent in OSM. This is how I would
read/interpret
the import guideline stated by Nate: "If you are importing data where
there is already some data in OSM, then *you need to combine this data*
in an appropriate way or suppress the import of features with overlap
with existing data." (emphasis added by me)

However, that just means, the import, hence, is nothing easy and could
not be achieve quickly, I would assume. One way of making sure that
this
is dealt with diligently, would be setting the tasking manager to
'experienced mappers only'. We would have to ask James, who is in
charge
of the Canada Tasking Manager, how to edit/set up the 'experienced
mapper role' in the TM. It might be possible to feed in a list of
mappers manually or to set a threshold of objects/changesets that they
must have entered in OSM. However, maybe only mappers who feel
experienced enough to handle the import would contribute to the TM
project anyway and we let everyone judge on their own and don't
restrict
access.

If we were to separate the new and overlapping buildings, I am also
leaning towards Daniel's assessment. I would be afraid to cause more
issues than by doing it all at once (with a reasonable tile size, of
course).

In the end, the main point of importing this specific dataset fulfils
two purposes, in my opinion: first, to add missing buildings (if it
were
just for this purpose we could also use the much bigger Microsoft
dataset), second, to get the best geospatial representation possible in
our OSM database. That means, we defer from using the Microsoft dataset
and use the much higher quality data from the ODB. This also means that
we should replace already existing buildings (yet keeping tags and
history) wherever the ODB footprint is more precise than the
existing one.

Just my two cents here,
Tim

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


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

[Talk-it] Decidiamo insieme il programma di OSMit (Torino, sabato 22 febbraio)

2020-01-17 Per discussione mbranco2

Buonasera Lista,

La bozza dei contenuti della giornata di sabato del convegno FOSS4G è qui
[1] e si può ancora modificare.
Vorrei che ci sentissimo in una call la prossima settimana per definire il
dettaglio e gli orari degli interventi; oltre naturalmente ai relatori,
l'invito è aperto anche a tutti coloro che sono interessati.
Per decidere in che giorno/ora fare la call in Jitsi (tra martedì e venerdì
della prossima settimana) ho predisposto il sondaggio [2], lunedì sera
chiuderemo il sondaggio e vedremo qual è il giorno/ora con più voti.

A presto,
Marco

[1] https://wiki.openstreetmap.org/wiki/Italy/Events/OSMit_2020_-_draft/

[2] https://framadate.org/mB77IddPulVDBzH7
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Corso di formazione OpenStreetMap per docenti (e non)

2020-01-17 Per discussione Matteo Zaffonato


Il 17/01/2020 17:35, canfe ha scritto:

Ne approfitto per un suggerimento:
da tempo suggerisco al mondo OSM di fare dei corsi simili in campo medico.
Ormai "bisogna" fare dei corsi, detti ECM, ed acquisire dei punti...
Se ci si potesse aprire al mondo ospedaliero si avrebbe sicuramente un ampio
uditorio.

Per chi volesse approfondire posso rendermi disponibile anche
telefonicamente.



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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


Grazie mille per la segnalazione, penso se ne possa ragionare durante la 
prossima riunione dei Coordinatori di Wikimedia Italia. :-)


Matteo


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

Re: [OSM-talk-fr] adresse mail rejetée - premières modifs

2020-01-17 Per discussione leni



Le 16/01/2020 à 23:48, Florian_G a écrit :

Hello,

Le 16/01/2020 à 18:49, Sébastien Dinot a écrit :

marc marc a écrit :

J'ai fait quelques modifs pour rendre la liste temporairement "plus
relax" au niveau des bounces

À la bonne heure ! Depuis décembre, je dois me faire virer de la liste
2 à 3 fois par semaine. Je réactive mon abonnement dès que je reçois le
message de notification, mais c'est pénible.

Pareil pour moi, et ça fait 2-3 mois que ça dure, à vue de nez (je n'ai
pas conservé les traces).

Et plus d'un an que je ne reçois plus les messages de Philippe Verdy (je
pensais qu'il avait quitté la liste
Je pensais aussi la même chose et après avoir été jeté x fois j'ai 
changé mon adresse (mais pénible d'avoir été obligé de le faire)

) : le dernier que j'ai reçu avec son
adresse Wanadoo date du 30/10/2018 puis 02/03/2019 et plus rien jusqu'au
08/01/2020 mais avec son adresse Gmail cette fois-ci. Et puis c'est tout.

++



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

Re: [Talk-it] Corso di formazione OpenStreetMap per docenti (e non)

2020-01-17 Per discussione canfe

Ne approfitto per un suggerimento:
da tempo suggerisco al mondo OSM di fare dei corsi simili in campo medico.
Ormai "bisogna" fare dei corsi, detti ECM, ed acquisire dei punti...
Se ci si potesse aprire al mondo ospedaliero si avrebbe sicuramente un ampio
uditorio.

Per chi volesse approfondire posso rendermi disponibile anche
telefonicamente.



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Il est partout, quelle énergie (à faire parfois quand même !)

2020-01-17 Per discussione François Lacombe

Bonjour et merci Vincent,

On a eu un bon échange avec la journaliste. Et le propos dans l'émission a
plutôt bien traduit tout ca donc c'est super.

Je sais que le profit n'est pas ce qui nous anime ici, et que la
rétribution prend bien d'autres formes que la rentabilité financière.
Par contre c'est un indicateur intéressant que de savoir quelle quantité
d'énergie des institutions est économisée par les contributions sur OSM.
Le chiffre donné par Gabriel Attal sur les bénévoles des restos du cœur
donne déjà une idée (bien que sûrement imparfait)

On verra si à l'avenir des progrès sont fait pour l'évaluer.

François

Le ven. 17 janv. 2020 à 16:17, Jacques Lavignotte 
a écrit :

>
>
> Le 17/01/2020 à 15:27, Vincent Bergeot a écrit :
>
> > François Lacombe a réussi à placer OpenStreetMap :)
>
> Oui ! En live ce matin.
>
> Bravo !
>
> Vraie question que la valorisation du bénévolat...
>
> J.
>
> --
> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
> On mangera ? (c) (tm)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Deleting template parameters copied to data items

2020-01-17 Per discussione François Lacombe

Hi Frederik

Le ven. 17 janv. 2020 à 16:05, Frederik Ramm  a écrit :

> Over the years, a couple of people have time and time again suggested
> that we get down and make a nice, curated, text-based catalogue of tags
> maintained by a team, potentially on a git-like system where pull
> requests can be submitted by everyone, but maintainers have to approve
> them.
>
> I was always on the fence about this, because it would install a
> maintainer team with more powers than the average user. But in the face
> of a wiki that is more and more moving into a direction where you need
> to have a degree in Wikidata to even participate, and where anything you
> contribute will be mowed over three times by this bot and that bot in
> order to fit into some structure that someone else has devised with
> practically zero community oversight, I think I'll prefer the git-based
> human-readable "tag atlas".
>

Could you please elaborate a bit more on why by human for human is the only
thing that exists in our landscape?
Don't we have tools that actually rely on that documentation to work and we
should take care of this as well?

In a really practical approach, I'm fed up to maintain sync in dozen of
translated pages containing the exact same template with the exact same
information.
DataItems would keep anyone able to document the tag as we do now instead
of a centralised git system with pull requests.
It's ok to say that as any brand new thing it will require further
development to be perfect. IMHO my contributions are more usable and
efficient on items than on many-same-wikitemplates.

OSM semantics and tagging model are also a thing and delivering it in a
structured database could make it usable at a really larger scale than now.
It's more about organizing knowledge than human readable documentation.
Time is short to make both in separates repositories.

Best regards

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

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Per discussione john whelan

>first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without Stat
Can data we are happy to import Microsoft dataset buildings as is?  Or
would we wish to wait until we have some more imports done before looking
at preprocessing them in some way first.

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  wrote:

> I would assume in most cases the imported building footprint will be
> more precise than existing data. For me, this would be a reason to
> replace already existing objects. However, I think this is a case by
> case decision. However, I think it is important to keep tags and history
> of buildings already existent in OSM. This is how I would read/interpret
> the import guideline stated by Nate: "If you are importing data where
> there is already some data in OSM, then *you need to combine this data*
> in an appropriate way or suppress the import of features with overlap
> with existing data." (emphasis added by me)
>
> However, that just means, the import, hence, is nothing easy and could
> not be achieve quickly, I would assume. One way of making sure that this
> is dealt with diligently, would be setting the tasking manager to
> 'experienced mappers only'. We would have to ask James, who is in charge
> of the Canada Tasking Manager, how to edit/set up the 'experienced
> mapper role' in the TM. It might be possible to feed in a list of
> mappers manually or to set a threshold of objects/changesets that they
> must have entered in OSM. However, maybe only mappers who feel
> experienced enough to handle the import would contribute to the TM
> project anyway and we let everyone judge on their own and don't restrict
> access.
>
> If we were to separate the new and overlapping buildings, I am also
> leaning towards Daniel's assessment. I would be afraid to cause more
> issues than by doing it all at once (with a reasonable tile size, of
> course).
>
> In the end, the main point of importing this specific dataset fulfils
> two purposes, in my opinion: first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset), second, to get the best geospatial representation possible in
> our OSM database. That means, we defer from using the Microsoft dataset
> and use the much higher quality data from the ODB. This also means that
> we should replace already existing buildings (yet keeping tags and
> history) wherever the ODB footprint is more precise than the existing one.
>
> Just my two cents here,
> Tim
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Il est partout, quelle énergie (à faire parfois quand même !)

2020-01-17 Per discussione Jacques Lavignotte




Le 17/01/2020 à 15:27, Vincent Bergeot a écrit :


François Lacombe a réussi à placer OpenStreetMap :)


Oui ! En live ce matin.

Bravo !

Vraie question que la valorisation du bénévolat...

J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
On mangera ? (c) (tm)

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

Re: [OSM-talk] Tag:man_made=embankment

2020-01-17 Per discussione 80hnhtv4agou--- via talk

yes the flat, but at the top is a golf coarse and or a sports field and there 
are several flats on the way up.

but in the case of a hole in the ground, storm water dry pound ???

From: Janko Mihelić
Sent: Friday, January 17, 2020 2:04 AM
To: 80hnhtv4a...@bk.ru
Cc: Volker Schmidt ;  Talk Openstreetmap
Subject: Re: [OSM-talk] Tag:man_made=embankment

On Thu, Jan 16, 2020, 23:47 80hnhtv4agou--- via talk < talk@openstreetmap.org > 
wrote:
>OK !
> 
>but where do i draw the line and which way do the v’s point ?
> 

The line is drawn next to the road, on the top of the embankment. The v's point 
down.

The thing I don't know, is if I draw the detailed embankment with it's own way, 
do I add embankment=yes to the road? In my opinion, it should be on the road as 
well, because it's an attribute of the road.

--
___
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] Deleting template parameters copied to data items

2020-01-17 Per discussione Frederik Ramm

Hi,

On 15.01.20 14:03, Christoph Hormann wrote:
> This is a move that has been a long time coming as part of a piecemeal 
> effort by some to establish a technocratic rule on the OSM wiki by 
> moving central content out of the control of the mappers into the 
> domain of data items with higher hurdles of participation due to poor 
> ergonomics (the whole concept of requiring human editors to deal with 
> numerical IDs for features that already have a unique identifier in OSM 
> by design never ceases to amaze me) and with an established ability of 
> the technocrats to control the crowd sourced editing work with bots.

I agree with this sentiment whole-heartedly and have commented the wiki
discussion accordingly.

> The real discussion that needs to be done is how we can get to a better
> documentation of the actual use of tags by humans for humans.  We have
> had some useful discussion on this at SotM last year and in a follow-up
> here:

Over the years, a couple of people have time and time again suggested
that we get down and make a nice, curated, text-based catalogue of tags
maintained by a team, potentially on a git-like system where pull
requests can be submitted by everyone, but maintainers have to approve
them.

I was always on the fence about this, because it would install a
maintainer team with more powers than the average user. But in the face
of a wiki that is more and more moving into a direction where you need
to have a degree in Wikidata to even participate, and where anything you
contribute will be mowed over three times by this bot and that bot in
order to fit into some structure that someone else has devised with
practically zero community oversight, I think I'll prefer the git-based
human-readable "tag atlas".

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] Il est partout, quelle énergie (à faire parfois quand même !)

2020-01-17 Per discussione Vincent Bergeot


François Lacombe a réussi à placer OpenStreetMap :)

Travail invisible, travail gratuit : à qui profitent nos activités non 
rémunérées ?


https://www.franceculture.fr/emissions/hashtag/hashtag-chronique-du-vendredi-17-janvier-2020

Cela dure 5'

Bonne écoute

--
Vincent Bergeot


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

Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Per discussione Eric

Bonjour,

Je pense que c'est bien de garder les OK sur la même page pour vérif
périodique de "non rechute". Par exemple,
https://carto.cdata.cerema.fr/1/pnb_action7_ff_2019.map
qui était dans les sujets clos ne me semble toujours pas correct.

Eric [Blueberry]

Le ven. 17 janv. 2020 à 13:43, Donat ROBAUX  a écrit :

> Je suis de l'avis de Marc: restons KISS
> A la limite réservons le Githut aux cas problématiques et récalcitrants.
>
> Donat
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Per discussione emeric Prouteau

Merci pour vos réponses.

J'utilise le fichier propre à la nouvelle aquitaine :
https://www.data.gouv.fr/fr/datasets/infrastructures-de-recharge-pour-vehicules-electriques-mobive-1/

Merci pour la correspondance des tags.

Pour mon process d'intégration, j'utilise FME en entrée je mets le fichier
en opendata et en sortie je fais un geojson avec les bons tags OSM d'ou ma
question :) pour le type.

Une partie des données à déjà été intégré du coup c'est plus un complément
et une MAJ.



Le ven. 17 janv. 2020 à 13:35, Noémie Lehuby via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello,
>
> je suis en train de bosser sur l'intégration osmose (en prévision d'un
> projet du mois) :)
>
> Voici une page de wiki avec le mapping entre l'open data et OSM :
> https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Bornes_de_Recharge_pour_V%C3%A9hicules_%C3%89lectriques
>
> Pour les prises :
>
>- EF correspond à socket:typee
>=*
>- T2 - EF veut dire qu'il y a deux prises sur le point de recharge
>(une T2 et une EF)
>
> --
> Noémie Lehuby
> Jungle Bus - http://junglebus.io
>
> Le 17/01/2020 à 13:08, PanierAvide via Talk-fr a écrit :
>
> Bonjour,
>
> IRVE = Infrastructure de recharge de véhicule électrique
>
> Cordialement,
>
> Adrien P.
>
> Le 17/01/2020 à 12:46, marc marc a écrit :
>
> Bonjour,
>
> Le 17.01.20 à 12:29, emeric Prouteau a écrit :
>
> Je souhaite intégrer les IRVE
>
> VE ok mais IRVE c'est quoi ?
> wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE
>
> manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.
>
> de combien d'objet parle-t-on ?
> ayant corrigé des horreurs de précédent import un peu partout
> cela serrait sûrement profitable de faire une conversion propre via
> osmose une fois pour toute.
>
> Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
>* CHADEMO (Ca c'est Ok)
>
> socket:chademo :)
>
>* COMBO
>
> socket:type2_combo
>
>* EF
>* T2 - EF
>
> je ne connait pas, une photo ?
> dans la base osm, il y a UN socket=EF-T3 (justement
> un import qui ne respecte pas la syntaxe courante)
>
>* T2
>
> socket:type2
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
*Emeric PROUTEAU*



*emeric.prout...@gmail.com Avant d'imprimer.
Pensons à l'environnement.Save paper. Do you really need to print this
e-mail?*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Per discussione Donat ROBAUX

Je suis de l'avis de Marc: restons KISS
A la limite réservons le Githut aux cas problématiques et récalcitrants.

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Per discussione Noémie Lehuby via Talk-fr


Hello,

je suis en train de bosser sur l'intégration osmose (en prévision d'un 
projet du mois) :)


Voici une page de wiki avec le mapping entre l'open data et OSM : 
https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Bornes_de_Recharge_pour_V%C3%A9hicules_%C3%89lectriques


Pour les prises :

 * EF correspond à socket:typee
   =*
 * T2 - EF veut dire qu'il y a deux prises sur le point de recharge
   (une T2 et une EF)

--
Noémie Lehuby
Jungle Bus - http://junglebus.io

Le 17/01/2020 à 13:08, PanierAvide via Talk-fr a écrit :

Bonjour,

IRVE = Infrastructure de recharge de véhicule électrique

Cordialement,

Adrien P.

Le 17/01/2020 à 12:46, marc marc a écrit :

Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :

Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE

manquantes de Dordogne basé sur la donnée mobive disponible sur 
data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.


Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
   * CHADEMO (Ca c'est Ok)

socket:chademo :)


   * COMBO

socket:type2_combo


   * EF
   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)


   * T2

socket:type2

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


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

Re: [Talk-GB] 2 OSMUK presentations done in the first 2 weeks of 2020

2020-01-17 Per discussione Jez Nicholson

Thanks for the kind feedback :) Trying to move on from 'what is OSM' to
'...and why should you care?'. Intention is to encourage new mappers and
reactivate lapsed ones.


On Fri, 17 Jan 2020, 10:54 Philip Barnes,  wrote:

> On Friday, 17 January 2020, Jez Nicholson wrote:
> > Just FYI, I've started off 2020 with a bang by doing 2 OSMUK
> presentations
> > in the first 2 weeks. Firstly to #geomob in London about the FHRS
> Project +
> > OSMUK progress. Secondly to the Shrewsbury Geospatial Forum as an intro
> to
> > OSM and its relevance to them.
> >
> > The next outing is probably Brian Prangle at the Move 2020 Conference in
> > London, Feb.
> >
> > I'm interested in building resources to help with doing presentations,
> > especially the "Intro to OSM". I know that everyone wants to do it their
> > own way, so it needs to be flexible. Harry's slides have been useful and
> > we've got some more too. The current OSMF
> >
> https://blog.openstreetmap.org/2020/01/16/osm-swot-2020-share-your-thoughts/
> > could
> > be useful as a place to find key points to make.
> >
> > I now plan to do some of my day job ;)
> >
> I attended the Shrewsbury Geospatial Forum and have to say Jez's talk was
> excellent, very well put together.
>
> Phil (trigpoint)
> --
> Sent from my Sailfish device
> ___
> 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: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Per discussione Guillaume Rischard

Tu as raison, ça serait mieux en plus d’utiliser une solution open source.

En attendant, ça a l’avantage d’exister et de marcher. Si un jour l’OSMF 
héberge par exemple son propre gitlab, on pourrait y passer.

Guillaume

> On 17 Jan 2020, at 12:17, marc marc  wrote:
> 
> le défaut étant d'être un tier (github),
> donc les contributeurs après s'être inscrit ici, sur osm, sur le wiki
> doivent s'inscrire une fois de + alors qu'il n'est deja pas motivant
> pour certain d'aller consigner leur signalement quelque part..
> 
> une interface web permettant de s'identifier avec son compte osm
> serait agréable
> 
> Le 17.01.20 à 12:04, Guillaume Rischard a écrit :
>> Bonjour,
>> 
>> Cette page wiki est difficile à suivre. Je vous propose
>> d’utiliser https://github.com/grischard/osm-lacking-attribution 
>>  qui
>> permet une gestion individuelle et systématisée au cas par cas, et est
>> activement lu et utilisé par le CA de la fondation OSM ;).
>> 
>> Guillaume
>> 
>>> On 14 Jan 2020, at 12:14, Cyrille37 OSM >> 
>>> >> 
>>> wrote:
>>> 
>>> Bonjour à tou·te·s,
>>> 
>>> il me semble qu'il serait plus "poli / respectueux" de supprimer les
>>> cas résolus: les sites qui ont corrigé les attributions sur leurs
>>> cartes. Effectivement, nous avons à priori seulement besoin de suivre
>>> l'avancement des corrections.
>>> 
>>> Si un besoin de mémoire était nécessaire, il pourrait être comblé par
>>> l'historique du wiki, ce qui me parait être un besoin vraiment "à la
>>> marge".
>>> 
>>> J'avais posé la suggestion sur la page de discussion, et à 2 nous
>>> étions d'accord pour supprimer les cas résolus :
>>> https://wiki.openstreetmap.org/wiki/FR_talk:Manque_d%27attribution_appropri%C3%A9e#Suivi_du_tableau
>>> 
>>> Voilà, la proposition est posée :-)
>>> 
>>> Cyrille37.
>>> 
>>> 
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org  
>>> >
>>> https://lists.openstreetmap.org/listinfo/talk-fr 
>>> 
>> 
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr 
>> 
>> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr 
> 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Live HS - lié au lag de osm108 ? lui même lié aux modifs de nombreuses relations communales ?

2020-01-17 Per discussione Jocelyn Jaubert

Bonjour,

On Wed, Jan 15, 2020 at 05:38:51PM +0100, Cédric Frayssinet wrote:
> > > Je voulais présenter le live à mes élèves aujourd'hui mais cela semble
> > > casser. Ce matin, c'était très lent, actuellement, il ne fonctionne
> > > pas.
> > > 
> > > https://live.openstreetmap.fr/
> > 
> > il y a du lag dans la generation des diffs dans l'infra osm-fr
> > http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html
> > qui semble caussé par le traitement des modifs des relations communales.

En fait, je crois que c'était plutôt causé à un souci sur la VM, qui saturait
en mémoire. Je l'ai redémarré, et c'est reparti correctement.

> > De mémoire, live utilise les diffs depuis le serveur ci-dessus.
> > Jocelyn avait prévu un moyen de les contourner en cas de lag
> > Je le prévient.

live pointait déjà sur les diffs d'osm.org. J'ai quand même modifié la config 
du serveur pour:
  - prendre les diffs par défaut depuis osm-fr
  - si le dernier diff est <= au précédent, alors récupérer les diffs depuis 
osm.org


Ça devrait corriger tout souci futur dans le cas de délai sur la génération des 
diffs d'osm-fr.


Merci,
Jocelyn

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

[talk-cz] JOSM tutorial pro zacatecniky v CZ?

2020-01-17 Per discussione mahdi1...@centrum.cz


cau,

V ramci HOTOSM/Pyladies akce na zacatku unora v Brne si dame po HOT 
casti pro prezivsi zaklady JOSMu jako takovyho. Pripravil sem si zhruba 
osnovu (wip, splacal sem to ted za pul hodky, takze to jeste budu ladit) 
co bych chtel zminit - https://hackmd.io/3Ac9vUZ9T-W-k0XBeaDRog -  v 
realu to bude primarne zamereny na oblasti zajmu pritomnych.


Mam par dotazu:

- mate nekdo JOSM material v cestine pro zacatecniky, kterej bych mohl 
sdilet?
- pokud mate zkusenost z podobnych akci, jaky dalsi temata byste 
pridali? Co lidi zajima a co ne?
- nebo se vic zamerit na realny vyuziti v terenu napr vic OSMandu pro 
vtahnuti do OSM sveta?


dik,
mahdi

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

Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Per discussione PanierAvide via Talk-fr


Bonjour,

IRVE = Infrastructure de recharge de véhicule électrique

Cordialement,

Adrien P.

Le 17/01/2020 à 12:46, marc marc a écrit :

Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :

Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE


manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.


Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
   * CHADEMO (Ca c'est Ok)

socket:chademo :)


   * COMBO

socket:type2_combo


   * EF
   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)


   * T2

socket:type2

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


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

Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Per discussione marc marc

Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :
> Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE

> manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.

> Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
>   * CHADEMO (Ca c'est Ok)

socket:chademo :)

>   * COMBO

socket:type2_combo

>   * EF
>   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)

>   * T2

socket:type2

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

Re: [OSM-talk-fr] suivit du cadastre (était : Proposition de mise à jour : la population des communes)

2020-01-17 Per discussione HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)

En fait, je suis partagé entre travail avec méthode +- scientifique et ballade 
au gré des envies (ou du hasard parfois).
Ce qui est lassant dans les contributions régulières et/ou volumineuses c'est 
la monotonie. Aussi, je change régulièrement de sujets (bâti, ferroviaire, 
adresses, occupation du sol, voirie) ou de coin (ça permet de faire du tourisme 
virtuel pour pas cher et de voir comment un territoire est décrit par d'autres 
contributeurs)

Denis, chair-tourist

-Message d'origine-
De : marc marc  
Envoyé : vendredi 17 janvier 2020 12:22
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] suivit du cadastre (était : Proposition de mise à 
jour : la population des communes)

Le 17.01.20 à 12:13, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE) 
a écrit :

> mise à jour de bâti. Je suis presque tenté par la création d'un indice 
> de vieillesse (vieillure ?) des nœuds/ways d'une commune dans OSM, 
> genre la date moyenne de dernière modif des objets (éventuellement par 
> type)

ce serrait une bonne idée pour https://cadastre.damsy.net ceci dit, après avoir 
completé de nombreuses communes niveau du bati, j'en suis arrivé à la 
conclusion que c'est bien difficile de trouver un critère qui permet de dire oü 
il faut aller voir.
le moins mauvais critère que j'ai trouvé : les addresses.
nouveau lotisement = souvent nouvelle adresse.
du coup maintenant je fais systématiquement ajout des addr, ce qui conduit à 
ajout des batiments manquant ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Types de prises IRVE

2020-01-17 Per discussione emeric Prouteau

Bonjour,

Je souhaite intégrer les IRVE manquantes de Dordogne basé sur la donnée
mobive disponible sur data.gouv.

Concernant le type de prise je n'arrive pas à tout faire correspondre entre
les valeurs du fichier et les valeur du wiki : socket:...

Quelqu'un pourrait-il m'aider ?

Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket

Les valeurs du fichier :

   - CHADEMO (Ca c'est Ok)
   - COMBO
   - EF
   - T2
   - T2 - EF

Bonne journée,


-- 
*Emeric PROUTEAU*



*emeric.prout...@gmail.com Avant d'imprimer.
Pensons à l'environnement.Save paper. Do you really need to print this
e-mail?*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] suivit du cadastre (était : Proposition de mise à jour : la population des communes)

2020-01-17 Per discussione marc marc

Le 17.01.20 à 12:13, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT
GE PPE) a écrit :

> mise à jour de bâti. Je suis presque tenté par la création d'un indice de 
> vieillesse (vieillure ?) des nœuds/ways d'une commune dans OSM, genre la date 
> moyenne de dernière modif des objets (éventuellement par type)

ce serrait une bonne idée pour https://cadastre.damsy.net
ceci dit, après avoir completé de nombreuses communes niveau du bati,
j'en suis arrivé à la conclusion que c'est bien difficile de trouver
un critère qui permet de dire oü il faut aller voir.
le moins mauvais critère que j'ai trouvé : les addresses.
nouveau lotisement = souvent nouvelle adresse.
du coup maintenant je fais systématiquement ajout des addr,
ce qui conduit à ajout des batiments manquant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Per discussione marc marc

le défaut étant d'être un tier (github),
donc les contributeurs après s'être inscrit ici, sur osm, sur le wiki
doivent s'inscrire une fois de + alors qu'il n'est deja pas motivant
pour certain d'aller consigner leur signalement quelque part..

une interface web permettant de s'identifier avec son compte osm
serait agréable

Le 17.01.20 à 12:04, Guillaume Rischard a écrit :
> Bonjour,
> 
> Cette page wiki est difficile à suivre. Je vous propose
> d’utiliser https://github.com/grischard/osm-lacking-attribution qui
> permet une gestion individuelle et systématisée au cas par cas, et est
> activement lu et utilisé par le CA de la fondation OSM ;).
> 
> Guillaume
> 
>> On 14 Jan 2020, at 12:14, Cyrille37 OSM > > wrote:
>>
>> Bonjour à tou·te·s,
>>
>> il me semble qu'il serait plus "poli / respectueux" de supprimer les
>> cas résolus: les sites qui ont corrigé les attributions sur leurs
>> cartes. Effectivement, nous avons à priori seulement besoin de suivre
>> l'avancement des corrections.
>>
>> Si un besoin de mémoire était nécessaire, il pourrait être comblé par
>> l'historique du wiki, ce qui me parait être un besoin vraiment "à la
>> marge".
>>
>> J'avais posé la suggestion sur la page de discussion, et à 2 nous
>> étions d'accord pour supprimer les cas résolus :
>> https://wiki.openstreetmap.org/wiki/FR_talk:Manque_d%27attribution_appropri%C3%A9e#Suivi_du_tableau
>>
>> Voilà, la proposition est posée :-)
>>
>> Cyrille37.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Per discussione HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)

J'en profite pour ma part, pour vérifier le bon l'ordonnancement des tronçons 
(avec plusieurs corrections à la clé), ajouter quelques name:gsw au passage (et 
virer les name:als). Pas compris, la logique de traduction des noms des 
communes (en malais, par ex)
Je refais les limites de commune plus quand je fais de la mise à jour de bâti. 
Je suis presque tenté par la création d'un indice de vieillesse (vieillure ?) 
des nœuds/ways d'une commune dans OSM, genre la date moyenne de dernière modif 
des objets (éventuellement par type)
Les fourmis jardinent même en hiver ;-)

-Message d'origine-
De : Vincent de Château-Thierry  
Envoyé : vendredi 17 janvier 2020 11:54
À : Discussions sur OSM en français 
Objet : Re: [OSM-talk-fr] Proposition de mise à jour : la population des 
communes


> De: "Donat ROBAUX" 
> 
> Pour info, la barre des 25% de communes à jour a été dépassée ce 
> matin!
> C'est une réelle satisfaction de voire la barre augmentée, mais 
> clairement c'est pas très passionnant à faire en manuel.

Oui & oui. De mon côté je traite les communes à un petit rythme, et en en 
profitant vraiment pour jardiner au passage, en voyant notamment sur quoi le 
validateur JOSM grogne. Hier par exemple j'ai eu droit à un "angle du chemin 
trop aigü" ou quelque chose d'approchant. Je ne connaissais pas ce message, au 
passage :) Et s'en est suivi du re-traçage de limite admin qui était imbriquée 
dans du tracé de rue pas joli joli... 

La mise à jour de population est vraiment un prétexte à venir jeter un oeil en 
des coins où on ne serait pas allé sinon. Statistiquement il y a quasi toujours 
prétexte à corriger 2-3 trucs en passant.

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Mateusz Konieczny




17 Jan 2020, 11:42 by andrew.harv...@gmail.com:

> I'm all for using the lifecycle prefix, > 
> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix> . I agreed that if 
> there's still remains there use ruined or destroyed, not sure what the 
> difference is though.
>
ruined implies that ruins still remain, destroyed may mean that or that there 
is no trace at all

in practice difference is minor if any

>  Once it's been cleared you could use demolished, removed or raised
>
Probably razed, not raised. I see not real difference.

> , again not sure what the difference is. While damaged is not documented it 
> seems the perfect fit since there is no other suitable tag for this on the 
> wiki.
>
damaged seems to me a poor fit as prefix, damaged building is still a building,
and I would expect building=something tag to be used.

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

Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Per discussione Guillaume Rischard

Bonjour,

Cette page wiki est difficile à suivre. Je vous propose d’utiliser 
https://github.com/grischard/osm-lacking-attribution 
 qui permet une gestion 
individuelle et systématisée au cas par cas, et est activement lu et utilisé 
par le CA de la fondation OSM ;).

Guillaume

> On 14 Jan 2020, at 12:14, Cyrille37 OSM  wrote:
> 
> Bonjour à tou·te·s,
> 
> il me semble qu'il serait plus "poli / respectueux" de supprimer les cas 
> résolus: les sites qui ont corrigé les attributions sur leurs cartes. 
> Effectivement, nous avons à priori seulement besoin de suivre l'avancement 
> des corrections.
> 
> Si un besoin de mémoire était nécessaire, il pourrait être comblé par 
> l'historique du wiki, ce qui me parait être un besoin vraiment "à la marge".
> 
> J'avais posé la suggestion sur la page de discussion, et à 2 nous étions 
> d'accord pour supprimer les cas résolus : 
> https://wiki.openstreetmap.org/wiki/FR_talk:Manque_d%27attribution_appropri%C3%A9e#Suivi_du_tableau
> 
> Voilà, la proposition est posée :-)
> 
> Cyrille37.
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Per discussione Vincent de Château-Thierry


> De: "Donat ROBAUX" 
> 
> Pour info, la barre des 25% de communes à jour a été dépassée ce
> matin!
> C'est une réelle satisfaction de voire la barre augmentée, mais
> clairement c'est pas très passionnant à faire en manuel.

Oui & oui. De mon côté je traite les communes à un petit rythme, et en en 
profitant vraiment pour jardiner au passage, en voyant notamment sur quoi le 
validateur JOSM grogne. Hier par exemple j'ai eu droit à un "angle du chemin 
trop aigü" ou quelque chose d'approchant. Je ne connaissais pas ce message, au 
passage :) Et s'en est suivi du re-traçage de limite admin qui était imbriquée 
dans du tracé de rue pas joli joli... 

La mise à jour de population est vraiment un prétexte à venir jeter un oeil en 
des coins où on ne serait pas allé sinon. Statistiquement il y a quasi toujours 
prétexte à corriger 2-3 trucs en passant.

vincent

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

Re: [Talk-GB] 2 OSMUK presentations done in the first 2 weeks of 2020

2020-01-17 Per discussione Philip Barnes

On Friday, 17 January 2020, Jez Nicholson wrote:
> Just FYI, I've started off 2020 with a bang by doing 2 OSMUK presentations
> in the first 2 weeks. Firstly to #geomob in London about the FHRS Project +
> OSMUK progress. Secondly to the Shrewsbury Geospatial Forum as an intro to
> OSM and its relevance to them.
> 
> The next outing is probably Brian Prangle at the Move 2020 Conference in
> London, Feb.
> 
> I'm interested in building resources to help with doing presentations,
> especially the "Intro to OSM". I know that everyone wants to do it their
> own way, so it needs to be flexible. Harry's slides have been useful and
> we've got some more too. The current OSMF
> https://blog.openstreetmap.org/2020/01/16/osm-swot-2020-share-your-thoughts/
> could
> be useful as a place to find key points to make.
> 
> I now plan to do some of my day job ;)
>
I attended the Shrewsbury Geospatial Forum and have to say Jez's talk was 
excellent, very well put together.

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

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

2020-01-17 Per discussione Vincent de Château-Thierry


> De: "marc marc" 
> 
> Le 17.01.20 à 10:52, Vincent de Château-Thierry a écrit :
> > Oui merci Marc. J'ai reçu ce matin un mail envoyé par
> > verd...@gmail.com comme quoi tout arrive.
> 
> oui et il n'y a eu plus aucun bounce depuis la modération/suppression
> de l'email problématique.

Cool

> derrière talk-fr-ow...@openstreetmap.org il y avait
> talkfrad...@gmail.com et nul ne sait/se souvient/n'a dit se souvenir
> de qui c'était vu l'absence de réaction aux messages depuis longtemps et 
> qu'il y
> avait des messages en attende de modération depuis 6 ans, TomH a accepté de
> m'envoyer au charbon à la place du précédent :)
> il n'y a personne au rôle modérateur, les lignes précédentes
> concernent le rôle admin qui a aussi accès à la modération.

Bon, le mystère restera entier.

> > Je suis partant pour faire partie de ce "pool".
> je t'ajoute volontiers, mais ne risques-tu pas un bounce si tu reçois
> un email problématique vu que tu es sur un fai le détectant ?
> sur des listes osm-fr oü il y a plus d'un modérateur, je vois souvent
> que la demande de modération d'email problématique subit un bounce
> pour les autres modérateurs. j'avais envisagé la création d'une boite
> email non filtré.

Non je ne penses pas, si je prends l'exemple des listes osm.fr où je suis admin 
: je reçois bien les mails envoyés à l'admin vdct disant que l'inscrit vdct 
bounce :/
 
> > aussi bien par souci de gouvernance que de "bus factor"
> 
> Pour le "bus factor", les admin osm.org peuvent tjs modifier :)
> Mais tout a fait d'accord. A savoir cependant qu'il n'y a pas de
> quorum de modération, le premier qui fait l'action valide.

Oui on est d'accord, c'est bien comme ça que ça fonctionne

> Plusieurs liste osm-fr manquent aussi de modérateur actif.

Auxquelles penses-tu ?

vincent

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

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Andrew Harvey

On Fri, 17 Jan 2020 at 19:53, Warin <61sundow...@gmail.com> wrote:

> I have tagged some buildings that have been fire damaged to a large degree.
> I have used building=razed however I think this is wrong.
>
> I think the lifecycle prefix should be used.
>
> The choices are;
>
> ruins:*
>
> or
>
> destroyed:*
>
> Thoughts?
>
> I note there is the possibility of partial damage. A new tag of damaged:*
> might be of use?
>

I'm all for using the lifecycle prefix,
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix. I agreed that if
there's still remains there use ruined or destroyed, not sure what the
difference is though. Once it's been cleared you could use demolished,
removed or raised, again not sure what the difference is. While damaged is
not documented it seems the perfect fit since there is no other suitable
tag for this on the wiki.

You'd probably need local knowledge to know all this, from the Maxar
imagery you can see houses and trace them not sure how easy it will be to
see destroyed houses though, will need to wait for the post event imagery
to come out.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Per discussione Donat ROBAUX

Hello,

Pour info, la barre des 25% de communes à jour a été dépassée ce matin!
C'est une réelle satisfaction de voire la barre augmentée, mais clairement
c'est pas très passionnant à faire en manuel.

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

2020-01-17 Per discussione marc marc

Bonjour,

Le 17.01.20 à 10:52, Vincent de Château-Thierry a écrit :
> Oui merci Marc. J'ai reçu ce matin un mail envoyé par verd...@gmail.com comme 
> quoi tout arrive.

oui et il n'y a eu plus aucun bounce depuis la modération/suppression
de l'email problématique.

> Pour la modération, deux questions :
> - as-tu finalement compris quelle(s) adresses étaient destinataires de 
> l'adresse générique de propriétaire/modérateur de talk-fr ? 

derrière talk-fr-ow...@openstreetmap.org il y avait
talkfrad...@gmail.com et nul ne sait/se souvient/n'a dit se souvenir
de qui c'était.
vu l'absence de réaction aux messages depuis longtemps et qu'il y avait
des messages en attende de modération depuis 6 ans, TomH a accepté de
m'envoyer au charbon à la place du précédent :)
il n'y a personne au rôle modérateur, les lignes précédentes concernent
le rôle admin qui a aussi accès à la modération.

> - qui d'autre que toi est modérateur ? Ca me semble sain que ce rôle soit 
> réparti sur plusieurs personnes,

Personne et je partage ton avis qu'il serrait sain d'être + que un.

> Je suis partant pour faire partie de ce "pool".
je t'ajoute volontiers, mais ne risques-tu pas un bounce si tu reçois
un email problématique vu que tu es sur un fai le détectant ?
sur des listes osm-fr oü il y a plus d'un modérateur, je vois souvent
que la demande de modération d'email problématique subit un bounce
pour les autres modérateurs. j'avais envisagé la création d'une boite
email non filtré.

> aussi bien par souci de gouvernance que de "bus factor"

Pour le "bus factor", les admin osm.org peuvent tjs modifier :)
Mais tout a fait d'accord. A savoir cependant qu'il n'y a pas de quorum
de modération, le premier qui fait l'action valide.
Plusieurs liste osm-fr manquent aussi de modérateur actif.
Pour la partie technique, c'est simple et cela s'apprend facilement.
Et on peux envisager un lieu de discussion s'il faut discuter de cela
sans noyer les listes concernées.

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

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Andrew Harvey

On Fri, 17 Jan 2020 at 20:45, Andy Mabbett 
wrote:

> On Fri, 17 Jan 2020 at 06:56, Andrew Harvey 
> wrote:
>
> > Maxar have generously donated some satellite imagery of bushfire affected
> > areas and they explicitly allow tracing for OSM,
> >
> >
> https://blog.maxar.com/open-data-program/2020/open-data-response-to-the-australian-wildfires
> .
>
> There's nothing explicitly about OSM on that page and the licence is
> stated (despite a claim of "open data") as "Creative Commons
> Attribution Non-Commercial 4.0 license (CC BY-NC 4.0). This licensing
> allows for non-commercial use of the information..."
>
> Have I missed something?
>

Yeah so if you click through to the landing page
https://www.digitalglobe.com/ecosystem/open-data/australia-wildfires and
then click the License button and then scroll down to see the OpenStreetMap
Exception.


> In the licensing terms, DigitalGlobe has a stated exception for
> OpenStreetMap. OSM is allowed to use imagery released under the Open Data
> Program. Even though OSM enables commercial usage, OSM is a critical
> platform for the disaster response community. Allowing usage of our imagery
> in OSM will enable faster data access by local communities as well as
> global relief efforts.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] 2 OSMUK presentations done in the first 2 weeks of 2020

2020-01-17 Per discussione Andy Mabbett

On Fri, 17 Jan 2020 at 09:36, Jez Nicholson  wrote:
>
> Just FYI, I've started off 2020 with a bang by doing 2 OSMUK presentations in 
> the first 2 weeks.

Good work!

> The next outing is probably Brian Prangle at the Move 2020 Conference in 
> London, Feb.

There's an OSM-Cymru presentation at this 'Digital Heritage'
conference on 12/13 February, in Aberystwyth:

   
https://rcahmw.gov.uk/about-us/digital-past-conference/speakers-and-abstracts-2020/

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Per discussione James

I could set the task up to be seen only by validators+ which I then can sst
individual users as validators

On Thu., Jan. 16, 2020, 10:10 p.m. Tim Elrick,  wrote:

> I would assume in most cases the imported building footprint will be
> more precise than existing data. For me, this would be a reason to
> replace already existing objects. However, I think this is a case by
> case decision. However, I think it is important to keep tags and history
> of buildings already existent in OSM. This is how I would read/interpret
> the import guideline stated by Nate: "If you are importing data where
> there is already some data in OSM, then *you need to combine this data*
> in an appropriate way or suppress the import of features with overlap
> with existing data." (emphasis added by me)
>
> However, that just means, the import, hence, is nothing easy and could
> not be achieve quickly, I would assume. One way of making sure that this
> is dealt with diligently, would be setting the tasking manager to
> 'experienced mappers only'. We would have to ask James, who is in charge
> of the Canada Tasking Manager, how to edit/set up the 'experienced
> mapper role' in the TM. It might be possible to feed in a list of
> mappers manually or to set a threshold of objects/changesets that they
> must have entered in OSM. However, maybe only mappers who feel
> experienced enough to handle the import would contribute to the TM
> project anyway and we let everyone judge on their own and don't restrict
> access.
>
> If we were to separate the new and overlapping buildings, I am also
> leaning towards Daniel's assessment. I would be afraid to cause more
> issues than by doing it all at once (with a reasonable tile size, of
> course).
>
> In the end, the main point of importing this specific dataset fulfils
> two purposes, in my opinion: first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset), second, to get the best geospatial representation possible in
> our OSM database. That means, we defer from using the Microsoft dataset
> and use the much higher quality data from the ODB. This also means that
> we should replace already existing buildings (yet keeping tags and
> history) wherever the ODB footprint is more precise than the existing one.
>
> Just my two cents here,
> Tim
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] adresse mail rejetée - premières modifs

2020-01-17 Per discussione Vincent de Château-Thierry

Bonjour,

> De: "Stéphane Péneau" 
> 
> Le 16/01/2020 à 13:46, marc marc a écrit :
> > J'ai reçu hier l'accès à l'administration de la liste.
> 
> Merci de prendre ça en charge Marc !

Oui merci Marc. J'ai reçu ce matin un mail envoyé par verd...@gmail.com comme 
quoi tout arrive.

Pour la modération, deux questions :
- as-tu finalement compris quelle(s) adresses étaient destinataires de 
l'adresse générique de propriétaire/modérateur de talk-fr ? 
- qui d'autre que toi est modérateur ? Ca me semble sain que ce rôle soit 
réparti sur plusieurs personnes, aussi bien par souci de gouvernance que de 
"bus factor". Si tu es actuellement seul sur le rôle, et si d'autres ici 
veulent se porter volontaires pour répartir la tâche, profitons-en. Je suis 
partant pour faire partie de ce "pool".

merci
vincent

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

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Andy Mabbett

On Fri, 17 Jan 2020 at 06:56, Andrew Harvey  wrote:

> Maxar have generously donated some satellite imagery of bushfire affected
> areas and they explicitly allow tracing for OSM,
>
> https://blog.maxar.com/open-data-program/2020/open-data-response-to-the-australian-wildfires.

There's nothing explicitly about OSM on that page and the licence is
stated (despite a claim of "open data") as "Creative Commons
Attribution Non-Commercial 4.0 license (CC BY-NC 4.0). This licensing
allows for non-commercial use of the information..."

Have I missed something?

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

[Talk-GB] 2 OSMUK presentations done in the first 2 weeks of 2020

2020-01-17 Per discussione Jez Nicholson

Just FYI, I've started off 2020 with a bang by doing 2 OSMUK presentations
in the first 2 weeks. Firstly to #geomob in London about the FHRS Project +
OSMUK progress. Secondly to the Shrewsbury Geospatial Forum as an intro to
OSM and its relevance to them.

The next outing is probably Brian Prangle at the Move 2020 Conference in
London, Feb.

I'm interested in building resources to help with doing presentations,
especially the "Intro to OSM". I know that everyone wants to do it their
own way, so it needs to be flexible. Harry's slides have been useful and
we've got some more too. The current OSMF
https://blog.openstreetmap.org/2020/01/16/osm-swot-2020-share-your-thoughts/
could
be useful as a place to find key points to make.

I now plan to do some of my day job ;)
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Trottoir traversant

2020-01-17 Per discussione marc marc

Je trouve que tu fais compliqué :)

une route et un trottoir se croise, donc un nœud d'intersection
"passage piéton" highway=crossing + crossing=uncontrolled probablement
pour le niveau de sécurité + crossing_ref=no probablement
pour le type (lié au marquage en fr be ch) + kerb=no

si tu veux maintenant ajouter du détail pour dire en linéaire
la longueur de ce croissement pour chaque usager :
- pour la voiture, c'est un plateau traffic_calming=table
sur le way voiture.
côté voiture, je vois pas de différence entre traverser
un plateau passage piéton avec marquage (les ""anciens"" trottoir
traversants qui existent depuis des années) et un plateau
passe piéton trottoir traversant).
tout autre tag me semble donc superflu ou erroné.
est-ce qu'il y a une différence dans la loi ?
- pour le piéton, il y a 2 incohérences dans ce que tu dis.
la clef crossing sert a décrire le passage piéton (le nœud même
si certain duplique l'info du passage 3 fois).
crossing=continuous n'est donc pas une bonne idée pour décrire
l'étendue du cheminement de voie le composant.
par ailleurs si tu considères qu'un trottoir traversant est un trottoir,
alors ce n'est pas un passage piéton, c'est highway=path path=sidewalk
si c'est pas tout a fait un trottoir (peut-on s'y arrêter pour faire
ses lacets ou discuter avec un autre pendant 5 min ? j'en doute),
alors highway=path path=continuous_sidewalk ou qlq chose du genre.

Le 17.01.20 à 10:03, Florimond Berthoux a écrit :
> Bonjour,
> 
> J’aimerai ajouter un possibilité, aujourd’hui les segments
> d’intersections vélo ou piéton peuvent être taggué avec
> path/cycleway/footway=crossing.
> https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing
> 
> On pourrait alors continuer et ajouter crossing=continuous (nouvelle clé).
> https://wiki.openstreetmap.org/wiki/Key:crossing
> 
> Ça me parait pas mauvais, après dans le principe ça me gène que ça soit
> la piste qui porte le crossing alors que l’idée c’est que c’est la
> voiture qui traverse la piste ;)
> Peut-être le plus simple serait d’ajouter sur le nœud d’intersection
> crossing=continuous_sidewalk, mais il faudrait alors préciser
> crossing:cycleway=continuous.
> Comme ça un router à l’info pour les trois modes de déplacement.
> 
> Mais crossing est une clé mal foutu avec des valeurs possible
> orthogonales :/
> 
> La clé kerb pourrait être aussi intéressante
> https://wiki.openstreetmap.org/wiki/Key:kerb
> 
> (l’enfer est pavé de tags ’:)
> 
> 
> Le dim. 12 janv. 2020 à 18:56, Florimond Berthoux
> mailto:florimond.berth...@gmail.com>> a
> écrit :
> 
> Salut,
> 
> Moi, mais il en existe trop peu par chez moi pour avoir essayer de
> trouver un schéma de tags.
> Mais on peut réfléchir à plusieurs :
> 
> En anglais on parle de continous sidewalk
> https://www.youtube.com/watch?v=9OfBpQgLXUc
> Pour ce qui est des trottoirs évidemment.
> 
> Je pense qu'on peut distinguer deux notions comme montré dans la
> vidéo, le côté trottoir traversant et le côté ralentisseur.
> Pour le côté ralentisseur on pourrait le tagguer simplement comme un
> traffic_calming=continuous_sidewalk
> 
> Pour le côté trottoir : sur le highway parallèle du trottoir
> traversant un tag sidewalk:right:continuous=yes
> Si le highway piéton est séparé on pourrait imaginer sur la portion
> du trottoir traversant :
> highway=footway
> footway=sidewalk
> sidewalk=continuous
> 
> Et on pourrait faire de même pour la piste cyclable
> cycleway:right=track
> cycleway:right:continuous=yes
> ou
> highway=cycleway
> cycleway=continuous ?
> 
> 
> 
> Le dim. 12 janv. 2020 à 17:25, Axel Listes  > a écrit :
> >
> > Bonjour,
> >
> > Suite à la rénovation d'un faubourg, j'ai vu que le trottoir ainsi que
> > la piste cyclable qui le longe sont agencés d'une façon que je n'avais
> > jamais vu dans le secteur.
> >
> > Dans certains carrefours avec des rues résidentielles, les rues en
> > question "s'interrompent" au croisement. Les véhicules peuvent
> circuler
> > sur une sorte de plateau, sauf que le plateau est intégré au
> trottoir du
> > Faubourg.
> >
> > Je sais que c'est courant aux Pays-bas, existant également sur
> Strasbourg.
> >
> > Est-ce que l'un ou l'une d'entre vous s'est déjà posé la question de
> > comment représenter cela sur OSM ?
> >
> > https://fr.wikipedia.org/wiki/Trottoir_traversant
> > http://velobuc.free.fr/trottoirtraversant.html
> >
> > Bien cordialement.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Florimond Berthoux
> 
> 
> 
> -- 
> Florimond Berthoux
> 
>

Re: [OSM-talk-fr] Trottoir traversant

2020-01-17 Per discussione Florimond Berthoux

Bonjour,

J’aimerai ajouter un possibilité, aujourd’hui les segments d’intersections
vélo ou piéton peuvent être taggué avec path/cycleway/footway=crossing.
https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing

On pourrait alors continuer et ajouter crossing=continuous (nouvelle clé).
https://wiki.openstreetmap.org/wiki/Key:crossing

Ça me parait pas mauvais, après dans le principe ça me gène que ça soit la
piste qui porte le crossing alors que l’idée c’est que c’est la voiture qui
traverse la piste ;)
Peut-être le plus simple serait d’ajouter sur le nœud d’intersection
crossing=continuous_sidewalk, mais il faudrait alors préciser
crossing:cycleway=continuous.
Comme ça un router à l’info pour les trois modes de déplacement.

Mais crossing est une clé mal foutu avec des valeurs possible orthogonales
:/

La clé kerb pourrait être aussi intéressante
https://wiki.openstreetmap.org/wiki/Key:kerb

(l’enfer est pavé de tags ’:)


Le dim. 12 janv. 2020 à 18:56, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Salut,
>
> Moi, mais il en existe trop peu par chez moi pour avoir essayer de trouver
> un schéma de tags.
> Mais on peut réfléchir à plusieurs :
>
> En anglais on parle de continous sidewalk
> https://www.youtube.com/watch?v=9OfBpQgLXUc
> Pour ce qui est des trottoirs évidemment.
>
> Je pense qu'on peut distinguer deux notions comme montré dans la vidéo, le
> côté trottoir traversant et le côté ralentisseur.
> Pour le côté ralentisseur on pourrait le tagguer simplement comme un
> traffic_calming=continuous_sidewalk
>
> Pour le côté trottoir : sur le highway parallèle du trottoir traversant un
> tag sidewalk:right:continuous=yes
> Si le highway piéton est séparé on pourrait imaginer sur la portion du
> trottoir traversant :
> highway=footway
> footway=sidewalk
> sidewalk=continuous
>
> Et on pourrait faire de même pour la piste cyclable
> cycleway:right=track
> cycleway:right:continuous=yes
> ou
> highway=cycleway
> cycleway=continuous ?
>
> 
>
> Le dim. 12 janv. 2020 à 17:25, Axel Listes  a écrit :
> >
> > Bonjour,
> >
> > Suite à la rénovation d'un faubourg, j'ai vu que le trottoir ainsi que
> > la piste cyclable qui le longe sont agencés d'une façon que je n'avais
> > jamais vu dans le secteur.
> >
> > Dans certains carrefours avec des rues résidentielles, les rues en
> > question "s'interrompent" au croisement. Les véhicules peuvent circuler
> > sur une sorte de plateau, sauf que le plateau est intégré au trottoir du
> > Faubourg.
> >
> > Je sais que c'est courant aux Pays-bas, existant également sur
> Strasbourg.
> >
> > Est-ce que l'un ou l'une d'entre vous s'est déjà posé la question de
> > comment représenter cela sur OSM ?
> >
> > https://fr.wikipedia.org/wiki/Trottoir_traversant
> > http://velobuc.free.fr/trottoirtraversant.html
> >
> > Bien cordialement.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Florimond Berthoux
>


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

[Talk-it] Segnalazione numeri di telefono su Osmose

2020-01-17 Per discussione Francesco Ansanelli

Buongiorno a tutti,

È attiva da ieri la validazione dei numeri di telefono su Osmose.
I numeri verdi (toll-free), gli 800, vengono segnalati come errati se in
formato internazionale...
Visto che non dovrebbero funzionare le chiamate da estero, ho pensato che
il +39 non è corretto, va bene per tutti?
Prima di iniziare a correggere, vorrei raccogliere qualche feedback...
Grazie
Francesco
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-au] Maxar bushfire imagery

2020-01-17 Per discussione Warin


I have tagged some buildings that have been fire damaged to a large degree.
I have used building=razed however I think this is wrong.

I think the lifecycle prefix should be used.

The choices are;

ruins:*

or

destroyed:*

Thoughts?

I note there is the possibility of partial damage. A new tag of 
damaged:* might be of use?


On 17/1/20 5:56 pm, Andrew Harvey wrote:
Maxar have generously donated some satellite imagery of bushfire 
affected areas and they explicitly allow tracing for OSM, 
https://blog.maxar.com/open-data-program/2020/open-data-response-to-the-australian-wildfires. 



So far they haven't released any post event imagery but I'll try to 
keep an eye for updates (should out if you see any), I'm sure they'll 
start flowing in. In the meantime I've loaded pre event imagery going 
back to June 2019.


The URLs for JOSM / iD (exclude the "tms:", start with the "https") are

2019-06-15 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.10300100921A2B00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-06-15 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.1030010093328400/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-07-01 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.104001004E982900/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-07-13 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.1050010017610F00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-07-14 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.105001001769C500/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-07-14 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.105001001769C600/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-07-23 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.103001009793C100/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-07-24 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.1050010017841E00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-08-02 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.103001009840FE00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w 

2019-08-13 
tms:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/openstreetmapau.103001009646FC00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Per discussione Philippe Verdy

Le plus simple c'est de modifier les deux en même temps (seulement pour les
noeuds admin_centre des communes au niveau 8, ou 9 pour les communes
déléguées ou arrondissements) ou sinon virer la population du noeud.

Pur les grosses communes divisées en IRIS, y compris à Paris avec ses
arrondissements groupant des quartiers, sous-quartiers et IRIS ; le noeud
Paris ne devrait avoir aucune population d'arrondissement mais ce n'est pas
clair si cela désigne la population départementale/municipale, ou celle de
la préfecture de Paris avec la petite couronne, ou le Grand Paris, de toute
façon ce n'est pas un IRIS Insee et c'est une totalisation partielle en
retirant les double-compte : on ne peut pas déduire cette population par
une simple somme arithmétique, la source est différente, les critères
d'inclusion dans une commune ou une autre sont un peu différent, et ce
n'est pas la somme des populations communales mais celle établie ensuite
par l'Insee qui a retiré les double-compte (notamment la population légale
par département, publiée par le décret de janvier 2020).

L'insee passe un temps fou à détecter les double-comptes mais certaines
communes exigent et obtiennent un droit à tenir compte de certaines
populations (dont les étudiants ou les touristes qu'elle héberge de façon
non permanente ou rapatrier chez elles les personnes à charge de personnes
situées dans d'autres communes, la population hospitalisée, celle
temporairement en prison n'importe où au moment du recensement mais ayant
encore un "domicile" officiel qu'elle ne peuvent pas occuper, tous ceux en
service extérieur commandé pour les armées, et la capacité d'accueil
moyenne dans les casernes en France à qui les communes ou communautés
doivent aussi rendre certains services, et certains autres résidents
quasi-permanents à l'étranger qui ont un droit de retour ou de rapatriement
permanent et immédiat en France à leur domicile déclaré.

Pour les communes non subdivisées en IRIS, donc de moins de 5000 habitants
(donc des noeuds de type place=town, village, voire hamlet dans quelques
cas) le noeud chef-lieu devrait afficher une population égale à celle de sa
relation de niveau 8 ou 9.

Moi je suis convaincu que la population au niveau du noeud n'est pas liée à
celle de la relation, le noeud ayant plus la signification associée à la
classification OSM (place=city/town/village/etc.) mais c'est significatif
si cela désigne l'agglomération. Mais dans les agglos multicommunales la
population de l'agglo ne marche plus.

De même des communes rurales et certaines communes urbaines récentes sont
créées pour grouper des villages formant des agglo différentes; ce n'est
pas clair si le noeud admin_centre devrait être la population totale de la
commune incluant ces villages périphériques dans des agglos séparées, ou la
population de l'agglo centre contenant le noeud (et parfois le noeud
communal n'est même pas fixé dans une des agglos mais entre elles, c'est le
cas pour les communes nouvelles à moins qu'on ait choisi le chef-lieu de la
commune déléguée membre, mais il y a encore des exceptions avec les
communes insulaires).

Bref Osmose peut dire ce qu'il veut. La population du noeud est difficile
voire impossible à vérifier par un moyen automatique, elle n'est pas
réellement sourçable elle donne jutse un indicateur estimé. Ce qui compte
c'est la population des relations qu'Osmose peut alors vérifier de façon
limitée (pas question de faire des cumuls à cause des double-compte, mais
la somme des membres devrait être supérieure ou égale à celle du contenant;
il vaut mieux sourcer séparément la population de chaque relation
contenante, et laisser à part celle des membres à gérer séparément)


Le ven. 17 janv. 2020 à 08:33, Jacques Lavignotte 
a écrit :

> Bonjour,
>
> Osmose râle sur mes récentes modifs d'hier soir (selon le mode op
> indiqué par Vincent )  :
>
>   Attribut “population” inconsistant entre la relation et son membre
> “admin_centre”
> Population du rôle “admin_centre” (309) supérieure à celle de la
> relation (305)
> relation 146525
>
> Qu'ai-je fait de mal ?
>
> Merci de me guider vers les corrections
>
> J.
>
>
>
> Le 14/01/2020 à 12:02, Vincent de Château-Thierry a écrit :
> > Bonjour,
> > Après l'échauffement avec la mise à jour des cantons il y a quelques
> jours, je vous propose un nouveau chantier, d'une autre ampleur mais à
> peine plus long.
> >
> > L'INSEE vient en effet de publier les chiffres de population légale par
> commune pour 2017 [1]. C'est l'occasion de mettre à jour le tag population
> de nos 35000 relations communales. Ca peut effrayer au premier abord car ça
> signifie écrire 35000 fois un chiffre relevé sur un listing, sans se
> tromper... pas sûr d'avoir envie. J'ai donc essayé de nous économiser, en
> proposant une interface de saisie que j'espère efficace.
> >
> > En allant ici :
> http://dev.cadastre.openstreetmap.fr/fantoir/maj_population_2017.html
> vous visualisez la liste des départements, et pour chacun le % de communes
>

[talk-ph] 2020 HOT-PH Critical Lifeline Infrastructure Data Model Consultation

2020-01-17 Per discussione Feye Andal

Hello everyone,

The Humanitarian OpenStreetMap Team (HOT) - Philippines is currently
developing a Critical Lifeline Infrastructure Data Model
for
our project PhilAWARE. PhilAWARE is a local installation of DisasterAWARE,
a disaster risk reduction and integrated early warning and decision support
system that also incorporates many data layers from OpenStreetMap. We will
be using the data model as we conduct OSM trainings, fieldworks, and
mapathons in Pampanga and Metro Manila. Your comments and recommendations
on how we can improve it would be greatly appreciated. You may contact me
if you have any questions or concerns.

Thank you!

Regards,
Feye
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk] Tag:man_made=embankment

2020-01-17 Per discussione Janko Mihelić

On Thu, Jan 16, 2020, 23:47 80hnhtv4agou--- via talk 
wrote:

> OK !
>
> but where do i draw the line and which way do the v’s point ?
>
>

The line is drawn next to the road, on the top of the embankment. The v's
point down.

The thing I don't know, is if I draw the detailed embankment with it's own
way, do I add embankment=yes to the road? In my opinion, it should be on
the road as well, because it's an attribute of the road.

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

73 matches

Mail list logo