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

[Jacques Lavignotte]

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 dont le 
tag population est à jour, avec les valeurs de 2017. A droite de chaque ligne, 
le lien fait accéder au détail des communes pour un département. Ici sur chaque 
ligne, on retrouve le code INSEE, le nom de commune, le nouveau chiffre de 
population, et un lien JOSM. Ce lien charge dans JOSM la relation 
administrative de la commune ET se propose de mettre à jour le tag population 
avec la bonne valeur, et le tag source:population avec la valeur 'INSEE 2020'. 
Pour info on a pour l'instant 29964 tags source:population = 'INSEE 2013' [2].

A aucun moment du processus on est censé renseigner manuellement la population, 
c'est le clic sur le lien JOSM qui fait le boulot, grâce aux chouettes 
fonctionnalités de la telecommande JOSM :). C'est pour ça que je pense que 
cette mise à jour peut se faire rapidement, d'autant plus si chacun en fait un 
petit morceau, dans sa zone de confort.

Ce chantier peut au passage être l'occasion d'un petit bilan de santé de nos 
relations communales :
- est-ce que la relation a bien des ensembles de way formant des boucles 
fermées ?
- est-ce que la relation a bien un node avec le rôle 'admin_centre' ?
- est-ce qu'on tombe sur un tag addr:postcode=* ? Si oui ça peut être 
l'occasion de le convertir en postal_code=* sachant qu'on l'a sous la main, ça 
homogénéise notre modèle de données des polygones postaux
...et toute autre 'opération de maintenance' que vous trouverez à faire sur les 
relations administratives (n'hésitez pas à les proposer dans le fil)

Les tableaux d'avancement sont mis à jour toutes les 2mn donc il est recommandé 
de produire de petits changesets et de les envoyer souvent, pour minimiser le 
risque de conflit d'édition. Et un bémol : je n'avais pas sous la main les 
populations 2017 des arrondissements municipaux pour Paris, Lyon et Marseille, 
ça se fera donc à la main en piochant ici [3].

Merci pour vos retours et vos quelques clics :)

vincent


[1] https://www.insee.fr/fr/statistiques/4265439?sommaire=4265511
[2] https://taginfo.openstreetmap.org/search?q=insee+2013#values
[3] https://www.insee.fr/fr/statistiques/zones/4269674?debut=0

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



--
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-it] Corso di formazione OpenStreetMap per docenti (e non)

[Alessandro Sarretta]

Buongiorno,
giro anche qui in lista la comunicazione che entro domani 18 gennaio è 
ancora possibile iscriversi al corso su OpenStreetMap che partirà il 25 
gennaio a Verona: https://www.wikimedia.it/formazione-docenti/modulo-c/
È uno dei corsi di formazione docenti riconosciuti dal MIUR e 
organizzati da Wikimedia Italia: 
https://www.wikimedia.it/formazione-docenti/
C'è la possibilità di frequentare il corso anche per non docenti; per 
maggiori informazioni: https://www.wikimedia.it/formazione-docenti/contatti/

Se potete, fate rigirare tra i vostri contatti,

Ale


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

[talk-au] Maxar bushfire imagery

[Andrew Harvey]

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
2019-08-13 tms:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/openstreetmapau.10300100972B2C00/{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.103001009795AC00/{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.1030010098AA7E00/{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.1030010099B36000/{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.10500100180CAD00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
2019-08-14 tms:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/openstreetmapau.104001004ED5C200/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
2019-08-21 tms:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/openstreetmapau.1040010051188200/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
2019-08-24 tms:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/openstreetmapau.1050010018401100/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
2019-08-27 tms:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/openstreetmapau.10500100184E7D00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
2019-09-07 tms:https://{switch:a,b,c,d}.

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

[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 !

Stéphane


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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

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

[OSM-talk] Trying to find Russian user Usm78

[Steve Coast]

If anyone’s able to connect me…

   https://wiki.openstreetmap.org/wiki/User:Usm78

Last edited around 2015.

thanks…

Steve

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

Re: [Talk-ca] Building tags in Canada

[stevea]

On Jan 16, 2020, at 3:56 PM, john whelan  wrote:
> I think what is in the wiki is a sort of dream.  An accurate building date 
> for example is often difficult to determine. but probably it needs a sort of 
> low hanging fruit section of what should be easy to tag.

One of the best parts of an open data collaboration like OSM is that "dreamy 
goals" are sometimes (even often?) posited, then pretty darn good results come 
from people picking and choosing from a large menu what interests them,   hat 
works for them, what is relevant to them (and their knowledge and the data and 
the structure into which all of this is poured).  It doesn't have to be 
all-or-nothing, in fact, it shouldn't be:  the "one brick at a time" approach 
is largely how our map has been built so far.

If the wiki is too dreamy to use as a wiki now, I might suggest it (or whatever 
consensus-based documentation of "how we do this" IS being used) be whacked 
down to where it IS realistic.  One benefit from doing so is that low-hanging 
fruit, on a short menu, looks that much easier to achieve towards completion, 
and therefore might even make great results MORE likely to be achieved.

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

Re: [Talk-ca] Building tags in Canada

[john whelan]

That sort of works but doesn't include roof:levels.

The easy tag would be building=detached but then you get building=house
which can be used for a semi detached house.

Locally we have some split levels so a single floor at ground level then a
garage often slightly sunk with another room or two on top.
building:levels=?

I'm tempted by the idea of using Streetcomplete's set of suggested tags.

Postcode is fine if you know it but it isn't always obvious from looking at
the building on the outside.

I think what is in the wiki is a sort of dream.  An accurate building date
for example is often difficult to determine. but probably it needs a sort
of low hanging fruit section of what should be easy to tag.

Thanks John

On Thu, 16 Jan 2020 at 17:49, stevea  wrote:

> On Jan 16, 2020, at 2:37 PM, John Whelan  wrote:
> > Is there somewhere that offers guidelines on how to add additional tags?
> and which tags are more interesting and which should be avoided?   For
> example country=Canada is probably superfluous.
>
> As it hasn't been touched in five months, I'm not sure how applicable the
> wiki
>
>
> https://wiki.osm.org/wiki/Canada/Building_Canada_2020#The_data_that_could_be_mapped
>
> is, relevant to how "this" is being done today.  This effort's wikis and
> approaches have changed — and grown!— since that document was drafted.
>
> But, that section does indicate that OSM's "key building=* currently has
> over 60 documented values" and the "man_made=* key now has over 50
> documented values."  I do recall when I selected eight or ten of the values
> noted there that I was largely making educated guesses.  But now, as is
> true of wiki, especially during a project that is still sort of "wet cement
> being mixed" (nothing wrong with that, it has to happen, it happens well
> now) please feel free to modify these values as you see fit.  It was meant
> to be a starting point, may you continue with it as well as possible.  (Or
> not).
>
> SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[stevea]

On Jan 16, 2020, at 3:24 PM, Tomek  wrote:
> La angla lingvo estas plago de la nuntempa mondo

(The English language is a plague / scourge of the contemporary world).

While I strive to accommodate (and often do) and I resonate well with 
Frederik's pleas to be pragmatic, avoid zealotry and "the usual language on 
this list is English," I can't help but find highly offensive calling my native 
language "plague de la nuntempa mondo."  (Ironic is that I speak some Polish 
and Esperanto as well, but find them to be inappropriate languages here).

I will say that phrase one more time:  "highly offensive."

Tomek, of course I see your point(s), but as my mother says, "you catch more 
flies with honey than you do with vinegar."  Please stop offending this list's 
readers with your opinions, especially as they contain insults to their 
language — that is wholly uncalled for.  I sometimes say to people, "thank you 
for your opinions."  With you, here and now, I do not.

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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Tomek]

W dniu 20-01-12 o 22:25, Alan Mackie pisze:
> The elephant in the room here is that this is a project founded in
> London in (British) English.  Regardless of the 'name' tag, all the
> main tags are themselves written in English, the official wording of
> the license is in English, the primary documentation is in English,
> the historical discussions about standard practice, most of the
> tools,  etc. etc. etc.. Changing the 'façade' on international objects
> will not change this underlying fact, and I don't think there is good
> enough a reason to.
>
> OpenStreetMap is open source, the whole thing can be machine
> translated into Esperanto, Klingon or Latin if you like, all you have
> to do is fork it. I suspect the forked project will see far less use,
> especially if you choose a niche constructed language that never
> really caught on.
>
> Meanwhile, a great number of international endeavours are currently
> conducted in English, it has become the Lingua Franca for many things
> now that the original Lingua Franca has gone the way of the Dodo. It
> also has the advantage that it can be expressed with a set of
> characters that is supported by just about every computing device you
> are likely to encounter worldwide without special hardware. Values
> have to support a wider array of characters, but in every case I can
> think of: 'local character set' + ASCII should get you what you need
> to contribute to the database, even if you have lots of regional
> subtags. It will also allow visitors to enter everything except name
> if they can't read the script on the sign, but do know what an object is.
>
> I don't think it makes sense for the main tagging scheme to change
> language and as long as that is true I don't think it makes sense to
> change the name tags on international objects either.
>
PL
Nie rozumiem jaki słoń, jaki pokój?

Angielski jest przekleństwem dziesiejszego świata, uniemożliwia sprawną
komunikację i faworyzuje pewne narody. Język angielski może i jest
popularny, ale ta popularność nie wynika z jego cech, ale tylko i
wyłącznie z potęgi gospodarczej Wielkiej Brytanii i USA, czas już zacząć
korzystać z języka PRAWDZIWIE MIĘDZYNARODOWEGO.

Esperanto również korzysta z alfabetu łacińskiego, nie rozumiem co masz
na myśli?

Wydaje mi się, że próbujesz sprowadzić moją wypowiedź do absurdu: nie
mam zamiaru zmieniać języka znaczników OSM! Chcę tylko usunąć znacznik
„name” z międzynarodowych obiektów, który jest błędny: nazwa powinna być
w lokalnym języku (to co jest na ziemi), skoro nie ma tabliczki/boi z
napisem „Atlantic Ocean”, to dlaczego ma to być w znaczniku „name”?

EO
Mi ne komprenas, kiu elefanto, kiu ĉambro?

La angla lingvo estas plago de la nuntempa mondo, ĝi malfaciligas efikan
komunikadon kaj favoras kelkajn naciojn. La angla lingvo eble estas
populara, sed tiu populareco rezultas nur pro ekonomia povo de Britujo
kaj Usono, jam estas tempo komenci uzi vere INTERNACIAN LINGVON.

Esperanto ankaŭ uzas la latinan alfabeton, mi ne komprenas pri kio vi
parolas?

Ŝajnas, ke vi volas karikaturi mian eldiron: mi ne volas ŝanĝi lingvon
de OSM-etikedoj! Mi nur volas forigi la etikedon “name” el internaciaj
objektoj, kiu kontraŭas al reguloj de OSM: nomo estu en loka lingvo
(tiu, kiu estas videbla el la tero), do se ne estas tabulo/buo kun la
skribaĵo “Atlantic Ocean”, do kial ĝi estas en la etikedo “name”?
<>

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

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

[Warin]

IF there is a road with embankments on either side then Volker is 
correct, just add embankment=yes to the way of the road. In this case 
the direction of the way does not matter.


Read https://wiki.openstreetmap.org/wiki/Key:embankment


On 17/1/20 9:44 am, 80hnhtv4agou--- via talk wrote:

OK !
but where do i draw the line and which way do the v’s point ?
*From:* Volker Schmidt
*Sent:* Thursday, January 16, 2020 3:10 AM
*To:* talk@openstreetmap.org
*Subject:* Re: [OSM-talk] Tag:man_made=embankment

If you have a road with a drop on either side then tag ways on either
side with embankment, with the appropriate directions.

I thought this is normally tagged with embankment=yes on the road way. See
Key:embankment. 
In case of oddly-shaped slopes that do not follow the road geometry 
you can use separate  man_made=embankment ways



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

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



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

Re: [OSM-talk-fr] adresse mail rejetée - email problématique modéré jusqu'à résolution

[marc marc]

Le 16.01.20 à 22:45, Philippe Verdy a écrit :
> je n'ai RIEN bricolé du tout

tu continues d'envoyer des email "from verd...@wanadoo.fr",
via serveur gmail et cela vient de produire 41 bounce.
cet email redirigé est TON choix, ce n'est pas parce que gmail
le permet que les autres fai doivent accepter un comportement
courant dans l'usurpation d'identité et le spam, d'autant
que tu as (tu le dis toi-même) ton email gmail qui va bien.

Par conséquent ton email est modéré jusqu'à résolution du problème.
si un email verd...@wanadoo.fr arrive via gmail, il serra supprimé.
si un email disant "c'est la faute des autres si tu utilises
ton email wanadoo dans gmail" arrive, il serra supprimé.
si c'est un email non bricolé, je le validerai.
Tu dois cependant t'attendre à des délais de validation,
je ne vais pas passer ma vie derrière mon écran pour valider
un hypothétique message valide à la minute alors que cela fait
des semaines que la demande a été faite calmement et patiemment.
En moyenne je m'attends cependant à les valider dans la journée.

J'en suis navré d'en arriver là mais ta mauvaise foi te perdra.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Building tags in Canada

[stevea]

On Jan 16, 2020, at 2:37 PM, John Whelan  wrote:
> Is there somewhere that offers guidelines on how to add additional tags? and 
> which tags are more interesting and which should be avoided?   For example 
> country=Canada is probably superfluous.

As it hasn't been touched in five months, I'm not sure how applicable the wiki

https://wiki.osm.org/wiki/Canada/Building_Canada_2020#The_data_that_could_be_mapped

is, relevant to how "this" is being done today.  This effort's wikis and 
approaches have changed — and grown!— since that document was drafted.

But, that section does indicate that OSM's "key building=* currently has over 
60 documented values" and the "man_made=* key now has over 50 documented 
values."  I do recall when I selected eight or ten of the values noted there 
that I was largely making educated guesses.  But now, as is true of wiki, 
especially during a project that is still sort of "wet cement being mixed" 
(nothing wrong with that, it has to happen, it happens well now) please feel 
free to modify these values as you see fit.  It was meant to be a starting 
point, may you continue with it as well as possible.  (Or not).

SteveA
___
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

[Florian_G]

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) : 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: [OSM-talk] Tag:man_made=embankment

[80hnhtv4agou--- via talk]

OK !
 
but where do i draw the line and which way do the v’s point ?
 
From: Volker Schmidt
Sent: Thursday, January 16, 2020 3:10 AM
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] Tag:man_made=embankment
 
 
 
>If you have a road with a drop on either side then tag ways on either
>side with embankment, with the appropriate directions.
 
I thought this is normally tagged with embankment=yes on the road way. See
Key:embankment.
In case of oddly-shaped slopes that do not follow the road geometry you can use 
separate  man_made=embankment ways
 
 
--
___
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] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Tomek]

W dniu 20-01-12 o 18:09, Marc Gemis pisze:
> Tomek,
>
> My mother tongue is Dutch. The second language I learned in school was
> French. Then English. I can follow discussions in German as well.
>
> But I'm not going to learn Esperanto, Polish, etc. anymore. I'm too
> old for that.
> I'm also not going to follow links to some sites that I don't know to
> get to some poor translation.. So if you refuse to write in English on
> this mailing list, you will no longer be able to communicate with me
> and probably many others.
>
> regards
>
> m.
NL (elektronische vertaler)
Waarom zou iedereen zich aan jou aanpassen en in jouw taal schrijven?
Dit is een internationale lijst, dus laten we schrijven in International
(Esperanto), of proberen het te begrijpen met behulp van elektronische
vertalers. Laten we elkaar respecteren, laten we niet zo egoïstisch zijn.

PL
Dlaczego wszyscy mają się dostosować do Ciebie i pisać w Twoim języku?
To jest międzynarodowa lista, więc piszmy w języku międzynarodowym
(Esperanto), ewentualnie starajmy się zrozumieć używając elektronicznych
tłumaczy. Szanujmy się nawzajem, nie bądźmy tacy samolubni.

EO
Kial vi atendas, ke ĉiuj konformiĝos al ci kaj skribos en cia lingvo?
Tio ĉi estas internacia listo, do ni skribu en internacia lingvo
(Esperanto), eventuale ni provu kompreniĝi per elektronikaj tradukiloj.
Ni respektu reciproke kaj ne estu tiel egoismaj.
<>___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-ca] Building tags in Canada

[John Whelan]

Part of the building import was the idea that once an outline was in 
place it could be tagged with more detail by someone with local 
knowledge. Sometimes some of this this information might be available 
from Mapillary.


For example building=house rather than building=yes

In Coburg there are a number of buildings labelled roof:levels=1

My understanding is this means a room in the attic which is fine but if 
you'd noted the attic room would it not make sense to map the number of 
levels as well?


Is there somewhere that offers guidelines on how to add additional tags? 
and which tags are more interesting and which should be avoided?   For 
example country=Canada is probably superfluous.


Thanks John

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

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[Nate Wessel]

Daniel,

The section you cite from the import guidelines seems to support my 
position. Perhaps that means I haven't explained my thoughts well? It says:


"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. Only where you have 
explicit support, which is highly unusual, should you replace current 
data with your imported data."


OSM is not all that dynamic - if it was, we wouldn't be talking about an 
import. We should do our best to align the data we're thinking of 
bringing in with gaps in the existing data. That's what conflation is 
all about. We should not systematically change existing data. That's 
called an automated edit and is governed by different policies than an 
import.


I'm not saying any plan is perfect - there will be gaps and overlaps, of 
course. But that doesn't mean we don't try at all.


Toronto has hundreds of thousands of buildings in OSM. They are not 
going to be compared manually, one by one if there is an import.


--

And again, I'm not saying not to do explicit building conflation and 
check for updated geometries - I'm just saying that it needs to be a 
separate process if it happens.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-16 2:56 p.m., Daniel @jfd553 wrote:


Hello Nate,

I understand that you don’t like to see an import process that both 
bring in new objects and overwrite existing ones. You also suggest 
removing "overlapped" building from ODB prior to import it. Such 
pre-processing, that would ensure there will be no buildings 
"overwrite" during the import, is not realistic (i.e. you will need to 
overwrite some buildings anyway). Here are two reasons why it would be 
difficult...


1-OSM is a dynamic project and, unless you can "clean" the data on the 
fly, you will end up with overlaps since some contributors will have 
added buildings in the meantime.


2-One cannot assume that an OSM building, and its ODB counterpart, 
will be found at the same location (look at DX and DY columns in ODB 
inventory tables). These are averages, which means there are larger 
offsets between both datasets (i.e. you won’t get a match between 
buildings, or get a match with the wrong ones).


The only realistic option is then to manually delete the ODB buildings 
if they overlap OSM ones. Here is what the import guideline suggests [1]…


"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."


Therefore, importing data and using a conflation process is not 
unusual. Again, I understand that in case of an overlap, you go for 
the last option (suppress the import building). I am rather inclined 
toward using conflation when necessary, which means...


-Importing an ODB building when there is no corresponding one in OSM;

-Conflating both ODB and OSM buildings when it significantly improves 
existing OSM content;


-Not importing an ODB building when the corresponding one in OSM is 
adequate.


What do the others on the list think?

Daniel

[1] 
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data


*From:*Nate Wessel [mailto:bike...@gmail.com]
*Sent:* Thursday, January 16, 2020 10:38
*To:* Daniel @jfd553; talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] FW: Re: Importing buildings in Canada

Responding to point C below,
I would strongly suggest that we not confuse the process of importing 
new data with that of updating/modifying existing data in the OSM 
database. One of the things I really disliked about the initial 
building import was that it overwrote existing data at the same time 
that new data was brought in. These are really two separate import 
processes and require very different considerations.


We can certainly consider using this dataset to improve/update 
existing building geometries, but I think that is a separate process 
from the import we are discussing here. To keep things simple for this 
import, I would suggest removing any building from the import dataset 
that intersects with an existing building in the OSM database. That 
is, let's not worry about conflation for now, and come back and do 
that work later if we still feel there is a strong need for it.


I see the main point of this effort as getting more complete coverage 
- it we want to use the dataset to do quality assurance on existing 
data, that is a whole other discussion.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:

Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of
others). So yes, I think hosting 

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

[deuzeffe]

Le 16/01/2020 à 22:45, Philippe Verdy a écrit :

Au final il n'y a que l'adresse Gmail qui marche correctement pour 
l'instant et n'a aucune perte.


Utilise-la.
--
deuzeffe - pourquoi faire simple, etc.

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

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

[deuzeffe]

Le 16/01/2020 à 23:08, Philippe Verdy a écrit :


Qu'est-ce que je peux y faire, moi ?


Utiliser une adresse qui ne produit pas de problème ?
--
deuzeffe - just saying

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

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

[Philippe Verdy]

Le jeu. 16 janv. 2020 à 21:13, DH  a écrit :

> 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.
>

Tu as de la chance. Je me suis fait virer plusieurs fois sans même avoir
aucun bounce avant, et sans jamais recevoir la notification.

>
> * mot qui a fait florès à une époque mais dont on a dévoyé le terme (aka
> si Ph. V.** s'y oppose il n'y a pas consensus)
>

Et encore une fois je ne suis pas du tout responsable de ça. Je ne gère pas
les serveurs de messagerie d'OSM.org ou ceux des FAI. J'ai des adresses
valides, confirmées, qui fonctionnent toutes et ne devraient déclencher
aucun "bounce" (et n'en déclenche strictement nulle part sauf certains pour
vous à cause du gestionnaire de cette liste OSM.org). S'il y a des bounces
éventuels ce sont les fitlres antispam des différents fournisseurs de mail
qui fonctionnent mal mais je ne peux rien y faire

(concernant Orange je les ai contacté plein de fois, il ont toujours
répondu qu'il n'y avait aucun problème chez eux et me demandaient à la
place d'utiliser leur webmail tout pourri, il n'y a pas moyen de tomber sur
quelqu'un de compétent qui remonte l'incident; pourtant Orange laisse
passer énormément de spams et troyens dans les mails qu'il accepte et qu'il
affiche directement sans filtre sur son webmail pourri même pas doté d'un
antivirus correct ou d'une fonction de clic avant activation des liens: le
webmail d'Orange laisse passer en particulier tous les pixels traceurs, les
clips audio/vidéos/flash en autoplay et divers scripts javascript
dangereux; je refuse d'utiliser ce webmail trop dangereux, pourtant le seul
service qu'Orange accepte officiellement de supporter pour ses clients. Au
delà c'est "hors périmètre du support", on ne peut trouver personne à qui
parler concernant leurs inscriptions DNS des serveurs hébergeant les
domaines d'Orange, le comportement de leurs service DNS pour ses clients,
le traitement des entête MIME, l'authentification des serveurs, etc.).

Ce qui pose surtout problème sur OSM.org est que ses listes modifient de
façon incorrecte le corps des messages, les signatures numériques initiales
ne sont pas conservées, et des entêtes MIME sont aussi modifiés au lieux
d'être seulement ajoutés en tête; certaines modifs d'entêtes sont possibles
mais très limitées (principalement la gestion des blancs et saus de ligne
et certains encodages de caractères. Mais tout le monde ne semble pas
synchro pour utiliser les mêmes RFC.

Même si on utilise un même logiciel, il faut aussi de la maintenance et
aussi des services complémentaires pour le gestionnaire de liste OSM.org:
- client DNS: quel est le fournisseur DNS (Bytemark je suppose) ? A-t-il
une limitation du nombre maxi de requêtes ?
- routeur et parefeu amont d'OSM.org : là aussi des filtres à régler et un
proxy DNS à vérifier (tient-il la charge ? A-il un cache de capacité
suffisante ?)
- synchro horaire (config de l'OS local et client SNTP)
- fichiers de règles et exceptions des protocoles de vérif, pour certains
domaines de messagerie (SPF, DKIM, etc...) qui peuvent ne pas être corrects
pour un des protocoles mais vérifiés plutôt par un autre pourtant moins
préféré
- etc.

Qu'est-ce que je peux y faire, moi ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Du calme, je n'ai RIEN bricolé du tout. Et ca fait longtemps que je reçois
des pseudo-"spams" (des bounces) aussi de pas mal de monde (dont ceux de
LaPoste et d'autres).

Et je ne suis pas le seul non plus à ne pas recevoir tous les messages de
la liste (et pas que les miens justement), depuis mars dernier j'en ai
loupé plein alors que je n'avais rien changé et n'avis qu'une souscription
à mon adresse Orange, tout à fait normale et qui existe depuis près de 30
ans et n'a jamais été hors service, toujours valide, et ne posant
strictemetn aucun problème non plus aux autres listes.

Bref je n'ai rien touché, ce n'est pas de mon contrôle mais à voir avec les
différents FAI qui refusent de faire les choses (dont Orange mais il n'est
pas le seul) et au gestionnaire de ces listes OSM.org, les seules qui ont
des problème (alors que d'autres mailing lists utilisant mailman n'ont
strictement aucun problème).

Bref quelquechose a changé et c'est du côté d'OSM.org uniquement que ça se
passe et ça date depuis le mois de mars dernier. Certainement un problème
de mise à jour ou perte de configuration pour les mises à jour de règles.
ou un changement très agressif sur OSM.org concernant le traitement des
bounces. Beaucoup ne sont plus abonnés mais ce n'est pas de ma faute (j'ai
aussi été désabonné de force par moment alors que je n'avais qu'une adresse
Orange). J'ai aussi été désabonné avec une adresse Yahoo (que je n'ai
jamais utilisé pour répondre, juste pour recevoir les messages en copie et
voir ceux qui manquaient).

Au final il n'y a que l'adresse Gmail qui marche correctement pour
l'instant et n'a aucune perte.

Je ne peux strictement rien faire concernant les problèmes de cette liste
ou les problèmes des FAI et autres fournisseurs de mail qui n'arrivent pas
à se mettre d'accord sur les règles de suivi des listes.


Le jeu. 16 janv. 2020 à 13:47, marc marc  a
écrit :

> Bonjour,
>
> J'ai reçu hier l'accès à l'administration de la liste.
> l'email de Philippe [1] a provoqué à lui tout seul des bounces sur 16
> email différents ainsi que 10 désinscriptions sur plusieurs domaines
> différents.
>
> J'ai réactivé manuellement les 15 personnes qui ont subi à ce moment
> là et dans le passé une désinscription pour "bounce excessif".
> J'ai fait quelques modifs pour rendre la liste temporairement "plus
> relax" au niveau des bounces, temporairement parce que cette fonction
> est nécessaire dans une liste normale pour détecter les adresses mortes
> avant que le serveur d'en face ne s'en irrite (comportement normal
> dans le domaine spam<>antispam).
>
> Philippe il t'a déjà été demandé à de nombreuses reprises de cessez
> d'envoyer ces emails bricolés rejetés par la moitié des fai français.
> Merci d'en tenir compte MAINTENANT, le taux de nuisance n'est pas
> acceptable. dire que c'est la faute du monde entier sauf toi
> n'est pas une solution.
>
> [1]
> https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096313.html
>
> 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: [Talk-ca] FW: Re: Importing buildings in Canada

[john whelan]

My understanding is that is when we imported Ottawa we followed the normal
process as detailed by Daniel and that seemed to work quite nicely.

Cheerio John

On Thu, Jan 16, 2020, 2:57 PM Daniel @jfd553,  wrote:

> Hello Nate,
>
> I understand that you don’t like to see an import process that both bring
> in new objects and overwrite existing ones. You also suggest removing
> "overlapped" building from ODB prior to import it. Such pre-processing,
> that would ensure there will be no buildings "overwrite" during the import,
> is not realistic (i.e. you will need to overwrite some buildings anyway).
> Here are two reasons why it would be difficult...
>
> 1-  OSM is a dynamic project and, unless you can "clean" the data on
> the fly, you will end up with overlaps since some contributors will have
> added buildings in the meantime.
>
> 2-  One cannot assume that an OSM building, and its ODB counterpart,
> will be found at the same location (look at DX and DY columns in ODB
> inventory tables). These are averages, which means there are larger offsets
> between both datasets (i.e. you won’t get a match between buildings, or get
> a match with the wrong ones).
>
> The only realistic option is then to manually delete the ODB buildings if
> they overlap OSM ones. Here is what the import guideline suggests [1]…
>
> "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."
>
> Therefore, importing data and using a conflation process is not unusual.
> Again, I understand that in case of an overlap, you go for the last option
> (suppress the import building). I am rather inclined toward using
> conflation when necessary, which means...
>
> -  Importing an ODB building when there is no corresponding one
> in OSM;
>
> -  Conflating both ODB and OSM buildings when it significantly
> improves existing OSM content;
>
> -  Not importing an ODB building when the corresponding one in
> OSM is adequate.
>
> What do the others on the list think?
>
> Daniel
>
> [1]
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data
>
>
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Thursday, January 16, 2020 10:38
> *To:* Daniel @jfd553; talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] FW: Re: Importing buildings in Canada
>
>
>
> Responding to point C below,
> I would strongly suggest that we not confuse the process of importing new
> data with that of updating/modifying existing data in the OSM database. One
> of the things I really disliked about the initial building import was that
> it overwrote existing data at the same time that new data was brought in.
> These are really two separate import processes and require very different
> considerations.
>
> We can certainly consider using this dataset to improve/update existing
> building geometries, but I think that is a separate process from the import
> we are discussing here. To keep things simple for this import, I would
> suggest removing any building from the import dataset that intersects with
> an existing building in the OSM database. That is, let's not worry about
> conflation for now, and come back and do that work later if we still feel
> there is a strong need for it.
>
> I see the main point of this effort as getting more complete coverage - it
> we want to use the dataset to do quality assurance on existing data, that
> is a whole other discussion.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:
>
> Thanks for the quick replies!
>
> Now, about...
>
> *a) Data hosting:*
>
> Thank you James, I really appreciate your offer (and that of others). So
> yes, I think hosting pre-processed data in the task manager, for approved
> regions, is an attractive offer. When we agree on a municipality for
> pre-processing, I will contact you to make the data available.
>
> BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
> manager. I understand that ODB data are currently converted on the fly when
> requested?
>
> *b) Task manager work units for import:*
>
> I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
> was thinking at the same importation rate, but for an hour of work. It
> seems best to target 20-minute tasks.
>
> *c) Task manager work units for checking already imported data*
>
> According to Nate, it is definitely not faster than actively importing. We
> should then keep the above setup (b).
>
> However, what if I add a new tag to pre-processed data indicating if a
> building was altered or not by the orthogonalization (and simplification)
> process? For instance, *building:altered=no*, would identify buildings
> that were not changed by the process and that could be left unchanged in
> OSM (i.e. 

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

[Andreas Vilén]

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 <
talk-se@openstreetmap.org> wrote:

> Här är länken till samtliga filer, version 9:
> https://drive.google.com/open?id=182NzEuSHM3fuYIVRErp7-GWYhum02UZN
> 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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

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

[Grigory Rechistov via Talk-se]

Här är länken till samtliga filer, version 9: 
https://drive.google.com/open?id=182NzEuSHM3fuYIVRErp7-GWYhum02UZN
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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

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

[DH]

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.


je plussoie.

Des mesures s'imposent si l'analyse est correcte (je suis niveau -1000 
sur le sujet mais je fait confiance si consensus*)


Denis

* mot qui a fait florès à une époque mais dont on a dévoyé le terme (aka 
si Ph. V.** s'y oppose il n'y a pas consensus)


** ce n'est pas une attaque ad homimen


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

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[Daniel @jfd553]

Hello Nate,
I understand that you don't like to see an import process that both bring in 
new objects and overwrite existing ones. You also suggest removing "overlapped" 
building from ODB prior to import it. Such pre-processing, that would ensure 
there will be no buildings "overwrite" during the import, is not realistic 
(i.e. you will need to overwrite some buildings anyway). Here are two reasons 
why it would be difficult...

1-  OSM is a dynamic project and, unless you can "clean" the data on the 
fly, you will end up with overlaps since some contributors will have added 
buildings in the meantime.

2-  One cannot assume that an OSM building, and its ODB counterpart, will 
be found at the same location (look at DX and DY columns in ODB inventory 
tables). These are averages, which means there are larger offsets between both 
datasets (i.e. you won't get a match between buildings, or get a match with the 
wrong ones).
The only realistic option is then to manually delete the ODB buildings if they 
overlap OSM ones. Here is what the import guideline suggests [1]...

"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."
Therefore, importing data and using a conflation process is not unusual. Again, 
I understand that in case of an overlap, you go for the last option (suppress 
the import building). I am rather inclined toward using conflation when 
necessary, which means...

-  Importing an ODB building when there is no corresponding one in OSM;

-  Conflating both ODB and OSM buildings when it significantly improves 
existing OSM content;

-  Not importing an ODB building when the corresponding one in OSM is 
adequate.
What do the others on the list think?
Daniel
[1] 
https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data


From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Thursday, January 16, 2020 10:38
To: Daniel @jfd553; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] FW: Re: Importing buildings in Canada


Responding to point C below,
I would strongly suggest that we not confuse the process of importing new data 
with that of updating/modifying existing data in the OSM database. One of the 
things I really disliked about the initial building import was that it 
overwrote existing data at the same time that new data was brought in. These 
are really two separate import processes and require very different 
considerations.

We can certainly consider using this dataset to improve/update existing 
building geometries, but I think that is a separate process from the import we 
are discussing here. To keep things simple for this import, I would suggest 
removing any building from the import dataset that intersects with an existing 
building in the OSM database. That is, let's not worry about conflation for 
now, and come back and do that work later if we still feel there is a strong 
need for it.

I see the main point of this effort as getting more complete coverage - it we 
want to use the dataset to do quality assurance on existing data, that is a 
whole other discussion.

Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com
On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:
Thanks for the quick replies!
Now, about...
a) Data hosting:
Thank you James, I really appreciate your offer (and that of others). So yes, I 
think hosting pre-processed data in the task manager, for approved regions, is 
an attractive offer. When we agree on a municipality for pre-processing, I will 
contact you to make the data available.
BTW, I thought ODB data in OSM format was hosted with the OSMCanada task 
manager. I understand that ODB data are currently converted on the fly when 
requested?
b) Task manager work units for import:
I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I was 
thinking at the same importation rate, but for an hour of work. It seems best 
to target 20-minute tasks.
c) Task manager work units for checking already imported data
According to Nate, it is definitely not faster than actively importing. We 
should then keep the above setup (b).
However, what if I add a new tag to pre-processed data indicating if a building 
was altered or not by the orthogonalization (and simplification) process? For 
instance, building:altered=no, would identify buildings that were not changed 
by the process and that could be left unchanged in OSM (i.e. not imported); 
building:altered=yes for those who were changed by the process and that should 
be imported again. The same pre-processed datasets could then be made available 
for all cases. Thoughts?
d) Finding local mappers:
I agree with Nate's suggestion to try contacting the top 10 mappers in an area. 
Using the "main activity center" would work for most of the contributors but 
selecting other 

[Talk-pe] Improvements to water and land use / mejoras a datos de aqua y uso de tierra

[Andrew Wiseman via Talk-pe]

Hello all,

This is Andrew again with Apple. In addition to the road network improvements I 
messaged about before, we are planning to work on some limited data corrections 
and improvements to OSM in Peru around coastal and water features and land use 
and land cover polygons, such as parks, university and hospital campuses, 
airports and similar features.

For example, sometimes coastlines and national parks are missing a correct tag, 
or are digitized inaccurately (maybe due to old low resolution imagery). We 
will make sure to follow the appropriate OSM and local guidelines. We have been 
doing a similar project around Africa and in other regions for some time. 

Also, thanks to those who contributed to the MapRoulette challenges I posted 
earlier! 
https://lists.openstreetmap.org/pipermail/talk-pe/2019-December/000851.html 
 

I wanted to get your feedback and see if you had any suggestions or data 
resources we could use. 

There’s more information on our Github page: 
https://github.com/osmlab/appledata/issues/52 
 

Thank you, 

Andrew 
//

Hola a todos,

Este es Andrew con Apple. Además de las mejoras en la red de carreteras que 
envié antes, estamos planeando trabajar en algunas correcciones de datos y 
mejoras limitadas a OSM en Perú en torno a las características costeras y del 
agua y los polígonos de la cobertura de la tierra, como parques, universidades 
y campus hospitalarios, aeropuertos y temas similares.

Por ejemplo, a veces a las costas y los parques nacionales les falta una 
etiqueta correcta, o se digitalizan de manera incorrecta (tal vez debido a 
imágenes antiguas de baja resolución). Nos aseguraremos de seguir las pautas 
apropiados de OSM y locales. Hemos estado haciendo un proyecto similar en 
África y en otras regiones durante algún tiempo.

Además, ¡gracias a quienes contribuyeron a los retos de MapRoulette que 
publiqué anteriormente! 
https://lists.openstreetmap.org/pipermail/talk-pe/2019-December/000851.html 
 

Quería recibir sus comentarios y ver si tenía alguna sugerencia o recursos de 
datos que pudiéramos utilizar. 

Hay más información en nuestra página de Github: 
https://github.com/osmlab/appledata/issues/52 
 

Gracias,

Andrew

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 

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

[Talk-cl] Improvements to water and land use / mejoras a datos de aqua y uso de tierra

[Andrew Wiseman via Talk-cl]

Hello all,

This is Andrew again with Apple. In addition to the road network improvements I 
messaged about before, we are planning to work on some limited data corrections 
and improvements to OSM in Chile around coastal and water features and land use 
and land cover polygons, such as parks, university and hospital campuses, 
airports and similar features.

For example, sometimes coastlines and national parks are missing a correct tag, 
or are digitized inaccurately (maybe due to old low resolution imagery). We 
will make sure to follow the appropriate OSM and local guidelines. We have been 
doing a similar project around Africa and in other regions for some time. 

Also, thanks to those who contributed to the MapRoulette challenges I posted 
earlier! 
https://lists.openstreetmap.org/pipermail/talk-cl/2020-January/001936.html 
 

I wanted to get your feedback and see if you had any suggestions or data 
resources we could use. 

There’s more information on our Github page: 
https://github.com/osmlab/appledata/issues/35 
 

Thank you, 

Andrew 
//

Hola a todos,

Este es Andrew con Apple. Además de las mejoras en la red de carreteras que 
envié antes, estamos planeando trabajar en algunas correcciones de datos y 
mejoras limitadas a OSM en Chile en torno a las características costeras y del 
agua y los polígonos de la cobertura de la tierra, como parques, universidades 
y campus hospitalarios, aeropuertos y temas similares.

Por ejemplo, a veces a las costas y los parques nacionales les falta una 
etiqueta correcta, o se digitalizan de manera incorrecta (tal vez debido a 
imágenes antiguas de baja resolución). Nos aseguraremos de seguir las pautas 
apropiados de OSM y locales. Hemos estado haciendo un proyecto similar en 
África y en otras regiones durante algún tiempo.

Además, ¡gracias a quienes contribuyeron a los retos de MapRoulette que 
publiqué anteriormente! 
https://lists.openstreetmap.org/pipermail/talk-cl/2020-January/001936.html 
 

Quería recibir sus comentarios y ver si tenía alguna sugerencia o recursos de 
datos que pudiéramos utilizar. 

Hay más información en nuestra página de Github: 
https://github.com/osmlab/appledata/issues/35 
 

Gracias,

Andrew

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


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

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

[Andreas Vilén]

Hej!

Jag tog en snabb koll i en av dina testfiler och jämförde mot ekonomiska
kartan. Platsnamnen verkar ligga på ungefär samma plats men viktigt att
notera att det är inte alltid platsnamnen där är unika, dels pga
fastighetsindelningar och dels pga i kartbladsgränser eftersom ortnamn nära
gränserna ofta skrivs ut en gång per kartblad. Exempelvis förekommer
Hjortseryd två gånger, med en brytlinje mellan två kartblad mellan dem
båda. Kommer sådana dubbletter kollas av? Själv hade jag gärna velat titta
på en fil över Skåne som är jämförd med befintlig data för att se vad som
blir kvar. Är det möjligt att ordna fram en sådan?

MVH Andreas

On Thu, Jan 16, 2020 at 6:19 PM Grigory Rechistov via Talk-se <
talk-se@openstreetmap.org> wrote:

> 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 

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

[Sébastien Dinot]

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.

Dans l'archive en ligne, je compte 401 messages envoyés depuis le 1er
janvier inclus. Dans mes archives personnelles, je n'en compte que 337.
J'ai donc clairement raté une partie des échanges et est ennuyeux
(surtout pour moi), mais je reçois tout de même 84 % des messages. Mon
adresse est donc valide et on ne peut accuser une boite aux lettres
pleine (je collecte quotidiennement mes messages sur mon PC et ils sont
effacés du serveur, je n'atteins donc jamais le quota octroyé par mon
fournisseur). Du coup, je trouve l'outil de gestion de liste un peu
tatillon sur ce coup.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

Re: [Talk-ca] Importing buildings in Canada

[Daniel @jfd553]

The page "The Open Database of Buildings" has been moved to the "Canada - The 
Open Database of Buildings" not to confuse wiki users from outside the country 
(a Tim Elrick suggestion).

Tim also identified another way to identify local mappers. I added a link to 
his recipe in the above wiki page, in "Get local buy-in before importing" 
section.

Daniel

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Wednesday, January 15, 2020 17:19
To: Daniel @jfd553; john whelan
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

I understand your concerns, John. However, many mappers might not follow 
talk-ca. So, I guess, Daniel's suggestion to contact them, might work 
better than waiting for them to incidentally check talk-ca.

* More to finding local mappers *
By providing the overpass query I just wanted to share a different way 
of contacting active mappers in your area. The advantage of Pascal's 
Who's around me is that you can see the mappers with lots of changesets, 
ie. presumably experienced mappers. The disadvantage is that these 
changesets do not have to be from the area we are interested in 
(however, with activity center in the last 6 months we at least make 
sure they were working in our area); another disadvantage is that you 
cannot collect the names of the mappers easily (or am I missing 
something here?). The advantage of the overpass query is that you get 
that list of names easily and you can see how many objects they have 
added in your area in the past months. The disadvantage, of course, is 
that we don't know how experienced the mappers are (but maybe this 
doesn't matter).

Anyway, either approach works as Daniel already pointed out. Thanks to 
stevea, I now know that I can share Overpass queries easily:
for a geocoded area:
http://overpass-turbo.eu/s/PM9
for a bounding box:
http://overpass-turbo.eu/s/PMb

* Contacting local mappers *
I suggest we design a template letter on the wiki page that can be send 
out to local mappers that include the everything that Daniel suggested 
in his last message below.

Tim


On 2020-01-15 15:54, Daniel @jfd553 wrote:
Hi John, Tim, and the others :-)
John, I understand your concern and if it was not addressed properly, 
this could block the import again.

IMHO, we just need to make sure that we have done everything reasonable 
to inform the concerned contributors, in order to discuss the import in 
case they do not agree with it. That is why I proposed the following, in 
a previous email, concerning local mappers buy-in…

1- We contact them to explain our intentions by referring to the 
appropriate wiki pages.
2- We wait a week or two for them to respond to nothing, have concerns 
or want to help.
3- Without negative answers, we could proceed to the import.

The point 3 above make sure the project is not stalled in case there is 
no or only a few answers. The identification of local contributors using 
Neis’ tool, or the query Tim Elrick just proposed, are what I consider 
reasonable attempts for contacting the local mappers.

Daniel

-Original Message-
From: Tim Elrick via Talk-ca [mailto:talk-ca@openstreetmap.org]
Sent: Wednesday, January 15, 2020 15:12
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour tasks

*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a
list of all users in the time period specified in the area specified.

// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
 // I collected users active in the last 6 months, but you can
 // change that
 node(newer:"{{date:6 months}}")(area.searchArea);
 way(newer:"{{date:6 months}}")(area.searchArea);
 relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then
'raw data directly from Overpass API'. This will generate a csv. You can
then count the number of times a name appears in your list by using
LibreOffice, R, Python or Excel. This will give you the number of
objects a user entered in the last 6 months.

If I do this for Montreal I end up with 106 names who have contributed
20 objects or more in the last half year or 46 names who have
contributed 100 objects and more.

You can then use https://www.openstreetmap.org/message/new/USERNAME by
replacing USERNAME with the names from the list to contact these users.

For areas where there is no geocodeArea in OSM you can use the
boundingbox query below. 

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[Nate Wessel]

Responding to point C below,
I would strongly suggest that we not confuse the process of importing 
new data with that of updating/modifying existing data in the OSM 
database. One of the things I really disliked about the initial building 
import was that it overwrote existing data at the same time that new 
data was brought in. These are really two separate import processes and 
require very different considerations.


We can certainly consider using this dataset to improve/update existing 
building geometries, but I think that is a separate process from the 
import we are discussing here. To keep things simple for this import, I 
would suggest removing any building from the import dataset that 
intersects with an existing building in the OSM database. That is, let's 
not worry about conflation for now, and come back and do that work later 
if we still feel there is a strong need for it.


I see the main point of this effort as getting more complete coverage - 
it we want to use the dataset to do quality assurance on existing data, 
that is a whole other discussion.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:


Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of others). 
So yes, I think hosting pre-processed data in the task manager, for 
approved regions, is an attractive offer. When we agree on a 
municipality for pre-processing, I will contact you to make the data 
available.


BTW, I thought ODB data in OSM format was hosted with the OSMCanada 
task manager. I understand that ODB data are currently converted on 
the fly when requested?


*b) Task manager work units for import:*

I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. 
I was thinking at the same importation rate, but for an hour of work. 
It seems best to target 20-minute tasks.


*c) Task manager work units for checking already imported data*

According to Nate, it is definitely not faster than actively 
importing. We should then keep the above setup (b).


However, what if I add a new tag to pre-processed data indicating if a 
building was altered or not by the orthogonalization (and 
simplification) process? For instance, /building:altered=no/, would 
identify buildings that were not changed by the process and that could 
be left unchanged in OSM (i.e. not imported); /building:altered=yes/ 
for those who were changed by the process and that should be imported 
again. The same pre-processed datasets could then be made available 
for all cases. Thoughts?


*d) Finding local mappers:*

I agree with Nate’s suggestion to try contacting the top 10 mappers in 
an area. Using the "main activity center" would work for most of the 
contributors but selecting other overlays (.e.g. an activity center 
over last 6 months) could also work great. As long as we identify who 
might be interested in knowing there is an import coming.


Comments are welcome, particularly about the proposal on c)

Daniel

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

[OSM-legal-talk] New data source

[Cj Malone]

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

Re: [OSM-talk-fr] [DAE] fonctionnement de la base de données nationale des,défibrillateurs automatisés externes

[marc marc]

Merci.
Quelqu'un a eu une réaction à nos ràactions sur le format ?

Le 16.01.20 à 13:51, Laurent Magréault a écrit :
> Bonjour,
> 
> Ci-dessous, les dates des 3 "webdémos" pour en savoir plus sur la base
> nationale des DAE.
> 
> ___)```)___
> 
> Laurent Magréault
> 
>      Courriel original 
>     Objet: Base nationale des DAE - faire suivre
>     Date: 15/01/2020 18:16
>     De: ATLASANTE mailto:atlasa...@ars.sante.fr>>
>     À:
> 
> 
>     Bonjour,
> 
>      
> 
>     Ce message s’adresse aux collectivités locales ou opérateurs privés
> propriétaires de défibrillateurs, aux membres des plateformes régionales
> d’échanges de données, aux mainteneurs de défibrillateurs, aux
> professionnels du secours, aux gestionnaires des applications citoyennes
> qui assurent le service aujourd’hui.
> 
>      
> 
>     La base de données nationale de collecte des défibrillateurs
> automatisés externes ouvrira prochainement afin de permettre aux
> exploitants de déclarer leur DAE en ligne, conformément à la Loi du 28
> juin 2018.
> 
>     Afin de comprendre et voir comment cela va se mettre en place nous
> vous proposons 3 web démos d’une durée d’une heure. L’inauguration
> officielle aura lieu mi-février, mais nous ouvrirons le service avant
> pour permettre les déclarations des premiers DAE.
> 
>      
> 
>     La Direction Générale de la Santé (DGS) a mandaté les équipes
> d’Atlasanté pour assurer les aspects techniques de ce recueil et du
> partage de la donnée.
> 
>     Atlasanté est le Système d’Information Géographique mutualisé des
> ARS et du ministère de la santé.
> 
>      
> 
>     Le projet n’a pas vocation à remplacer les applications citoyennes
> existantes. Elles assurent un rôle indispensable d’animation de
> communautés de secouristes. La base nationale permettra à toutes les
> applications qui le souhaiteront de disposer des mêmes données via des
> API gratuites. Les données publiques de ce projet seront également
> disponibles en Open Data.
> 
>      
> 
>      
> 
>     3 webdémos  en janvier
> 
>     le 21 à 10h55            le 24 à 13h25            le 27 à 13h55
> 
>      
> 
>     1h pour découvrir le projet et poser vos questions
> 
>      
> 
>     ·         Audio : 01 70 75 07 40
> 
>     ·         Ecran :
> https://ars-auvergne-rhonealpes.anywhereconference.com/
> 
>     Web login
>    
> 
>     Code PIN Participant
> 
>     418836232
>    
> 
>     92796633
>    
> 
>      
> 
>     Pour le confort de tous, nous vous demanderons de couper vos micros
> et poser vos questions au fur et à mesure par écrit via l’outil de
> dialogue. Vos questions seront ensuite regroupées et posées à l’orateur.
> 
>     La démo dure environ 30mn, le reste du temps sera dédié aux réponses
> à vos questions.
> 
>      
> 
>      
> 
>     Cordialement,
> 
>      
> 
>     Xavier VITRY
> 
>     SCN SIM ARS
> 
>    
> https://www.atlasante.fr/media/site/gen/atlasante/logo-atla-sant-l...@2x.png
> 
>     cid:image001.png@01D5C49D.064A2650  
> 
>     Ministère des Solidarités et de la Santé
>     Ministère du Travail
> 
>     Ministère de l’Éducation nationale
> 
>     Ministère des Sports
> 
>     04 27 86 57 30
> 
>     07 78 63 92 32
> 
>     xavier.vi...@ars.sante.fr 
> 
>      
> 
> 
>     Les ministères sociaux agissent pour un développement durable.
> 
>     Préservons l'environnement : n'imprimons que si nécessaire !
> 
> Le mer. 11 déc. 2019 à 10:51, Cyrille37 OSM via Talk-fr
> mailto:talk-fr@openstreetmap.org>> a écrit :
> 
> Revue de publication officielle:
> 
> Arrêté du 29 octobre 2019 relatif au fonctionnement de la base de
> données nationale des défibrillateurs automatisés externes (DAE)
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT39363959
> 
> Cet arrêté précise les modalités d'exploitation (alimentation, gestion,
> communication) de la base de données nationale des défibrillateurs
> automatisés externes.
> https://www.legifrance.gouv.fr/eli/arrete/2019/10/29/SSAP1932161A/jo/texte
> 
> 
> 
> ___
> 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] [DAE] fonctionnement de la base de données nationale des,défibrillateurs automatisés externes

[Laurent Magréault]

Bonjour,

Ci-dessous, les dates des 3 "webdémos" pour en savoir plus sur la base
nationale des DAE.

___)```)___

Laurent Magréault

 Courriel original 
Objet: Base nationale des DAE - faire suivre
Date: 15/01/2020 18:16
De: ATLASANTE 
À:


Bonjour,



Ce message s’adresse aux collectivités locales ou opérateurs privés
propriétaires de défibrillateurs, aux membres des plateformes régionales
d’échanges de données, aux mainteneurs de défibrillateurs, aux
professionnels du secours, aux gestionnaires des applications citoyennes
qui assurent le service aujourd’hui.



La base de données nationale de collecte des défibrillateurs
automatisés externes ouvrira prochainement afin de permettre aux
exploitants de déclarer leur DAE en ligne, conformément à la Loi du 28 juin
2018.

Afin de comprendre et voir comment cela va se mettre en place nous vous
proposons 3 web démos d’une durée d’une heure. L’inauguration officielle
aura lieu mi-février, mais nous ouvrirons le service avant pour permettre
les déclarations des premiers DAE.



La Direction Générale de la Santé (DGS) a mandaté les équipes
d’Atlasanté pour assurer les aspects techniques de ce recueil et du partage
de la donnée.

Atlasanté est le Système d’Information Géographique mutualisé des ARS
et du ministère de la santé.



Le projet n’a pas vocation à remplacer les applications citoyennes
existantes. Elles assurent un rôle indispensable d’animation de communautés
de secouristes. La base nationale permettra à toutes les applications qui
le souhaiteront de disposer des mêmes données via des API gratuites. Les
données publiques de ce projet seront également disponibles en Open Data.





3 webdémos  en janvier

le 21 à 10h55le 24 à 13h25le 27 à 13h55



1h pour découvrir le projet et poser vos questions



· Audio : 01 70 75 07 40

· Ecran :
https://ars-auvergne-rhonealpes.anywhereconference.com/

Web login


Code PIN Participant

418836232


92796633




Pour le confort de tous, nous vous demanderons de couper vos micros et
poser vos questions au fur et à mesure par écrit via l’outil de dialogue.
Vos questions seront ensuite regroupées et posées à l’orateur.

La démo dure environ 30mn, le reste du temps sera dédié aux réponses à
vos questions.





Cordialement,



Xavier VITRY

SCN SIM ARS


https://www.atlasante.fr/media/site/gen/atlasante/logo-atla-sant-l...@2x.png

cid:image001.png@01D5C49D.064A2650

Ministère des Solidarités et de la Santé
Ministère du Travail

Ministère de l’Éducation nationale

Ministère des Sports

04 27 86 57 30

07 78 63 92 32

xavier.vi...@ars.sante.fr




Les ministères sociaux agissent pour un développement durable.

Préservons l'environnement : n'imprimons que si nécessaire !

Le mer. 11 déc. 2019 à 10:51, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Revue de publication officielle:
>
> Arrêté du 29 octobre 2019 relatif au fonctionnement de la base de
> données nationale des défibrillateurs automatisés externes (DAE)
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT39363959
>
> Cet arrêté précise les modalités d'exploitation (alimentation, gestion,
> communication) de la base de données nationale des défibrillateurs
> automatisés externes.
> https://www.legifrance.gouv.fr/eli/arrete/2019/10/29/SSAP1932161A/jo/texte
>
>
>
> ___
> 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] adresse mail rejetée - premières modifs

[marc marc]

Bonjour,

J'ai reçu hier l'accès à l'administration de la liste.
l'email de Philippe [1] a provoqué à lui tout seul des bounces sur 16
email différents ainsi que 10 désinscriptions sur plusieurs domaines
différents.

J'ai réactivé manuellement les 15 personnes qui ont subi à ce moment
là et dans le passé une désinscription pour "bounce excessif".
J'ai fait quelques modifs pour rendre la liste temporairement "plus
relax" au niveau des bounces, temporairement parce que cette fonction
est nécessaire dans une liste normale pour détecter les adresses mortes
avant que le serveur d'en face ne s'en irrite (comportement normal
dans le domaine spam<>antispam).

Philippe il t'a déjà été demandé à de nombreuses reprises de cessez
d'envoyer ces emails bricolés rejetés par la moitié des fai français.
Merci d'en tenir compte MAINTENANT, le taux de nuisance n'est pas
acceptable. dire que c'est la faute du monde entier sauf toi
n'est pas une solution.

[1]
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096313.html

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

Re: [OSM-talk-fr] Fond de carte sans mention OSM

[Vincent de Château-Thierry]

Bonjour,

> De: "PierreV" 
> 
> mais surtout si je viens ici c'est que je souhaite savoir si
> quelqu'un me dise quel est le "rendu" utilisé car je ne trouve pas sur Umap.

Entre l'allure générale et le fait que c'est proprement découpé aux limites du 
département, ça me fait plutôt penser à une carte élaborée à l'aide de QGis ou 
autre SIG, tout droit sortie du système d'information du département.

Ça n'empêche pas d'y faire figurer la bonne attribution s'il s'avère que les 
données sont OSM, vu que la carte est publiée.

vincent

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

Re: [Talk-it] Brainstorming su a che punto è OSM

[Francesco Ansanelli]

Ciao Marco,

Grazie per aver condiviso il documento!

Aggiungerei ancora che wiki non è il "metodo" migliore per gestire la
documentazione tecnica dei tag in quanto troppo facilmente si incappa nel
disallineamento tra pagine in lingua (e non). Ognuno immagino vorrebbe ogni
tag localizzato nella propria lingua, ma per un progetto così grande non
sembra possibile con il metodo attualmente in vigore. Ci si dovrebbe
appoggiare ad uno strumento esterno per tradurre le singole frasi e usare
una pagina comune in inglese per i testi. Qualcuno potrebbe argomentare che
i contenuti in lingua es. IT:Indirizzi sono per gli italiani, ma in realtà
essendo per l'Italia andrebbero comunque (e a maggior ragione) tradotti in
altre lingue.

Cosa ne pensate?
Francesco

Il gio 16 gen 2020, 11:45 mbranco2  ha scritto:

> https://wiki.openstreetmap.org/wiki/OSM_SWOT
>
> Non scatenatevi troppo, eh?  :-)
> ___
> 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

[Talk-it] Brainstorming su a che punto è OSM

[mbranco2]

https://wiki.openstreetmap.org/wiki/OSM_SWOT

Non scatenatevi troppo, eh?  :-)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Volker Schmidt]

If you have a road with a drop on either side then tag ways on either
> side with embankment, with the appropriate directions.
>

I thought this is normally tagged with embankment=yes on the road way. See
Key:embankment. 
In case of oddly-shaped slopes that do not follow the road geometry you can
use separate  man_made=embankment ways
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk