Re: [Talk-cz] Detekce z fotek osmhicheck

[Jan Skala]

Dobře díky za info oběma. Když jsem se letmo probíral tím strojovým čtením, tak jsem zjistil, že je nutno detekovat (dopravní) značku, odhadnout zkos a natočení, vyrovnat to tak jako by se koukalo zpříma a pak se pokusit to přečíst OCR. Možností by pak byl nástroj, který by zobrazil fotku a vedle co se mu povedlo přečíst. To by pak člověk upravil a potvrdil. Už to by ušetřilo dost času při vytváření DB cílů.HonzaDne 6. 1. 2018 11:19 PM napsal uživatel majka :6. ledna 2018 22:30:43 SEČ, "Marián Kyral"  napsal:>>Myslím, že první krok byl zjistit, zda máme zmapovány všechny trasy>(barvy), které na tom rozcestníku jsou.>Osobně si moc nadějí nedělám ani v tomhle - dokonce i ty barvy nejsou úplně jednoduché. Narazila jsem na komplet vybledlé, takže zelená se nedala poznat, u rybníků zarostlé řasami a koneckonců i dnes za západu slunce pořízená fotka je zajímavá (vpravo nahoře) - místo červené se ty nejlépe čitelné tabule ukazují žlutozeleně místo červené. >Teoreticky by ti to právě s tím přepisem mohlo pomoct. Ale to OCR zatím>není příliš úspěšné. Hlavně proto, že kvalita fotek je velmi rozdílná.Navíc spousta i jinak dobře čitelných fotek je problematická úhlem nafocení, případně jsou rozcestníky zarostlé a lépe než z části zakryté větvemi nešly nafotit. Opět pár mých příkladů:ne příliš ideální úhel kvůli sluncidalší - slunce + umístěnízměť rozcestníků + moje nedostatečná výška, takže foceno výrazně směrem vzhůruzarostlý rozcestník, pro mě vysoko, a to jsem některé větve klackem odsouvala, takže komedie při foceníA samozřejmě ty koláže taky nejsou pro techniku legrace. Za mě - na mnou nafocených rozcestnících kontroluji, že ty okolní máme zadané. Pokud nejsou, tak je vkládám do dat - například tenhle - jednou to tam budu muset vše prolézt důkladněji, protože se mi ho najít nepodařilo.Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-us] Parks, again

[Mateusz Konieczny]

On Sat, 6 Jan 2018 21:11:04 +
Doug Hembry  wrote:

> IMHO, AT THE VERY LEAST, the background green fill for leisure=park 
> could and should be dropped by openstreeetmap-carto - it is
> unnecessary, causes problems, and can be replaced by natural=* or
> landcover=* . This would reduce one incentive for inappropriate use,
> and if still used inappropriately, it wouldn't matter so much.

I am not sure. As I understand, problem is caused by tagging for
renderer - but national park borders are already displayed in this
style.

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

Re: [OSM-talk] GeoChat

[Andrew Buck]

I used it about a week ago and it was working fine then, but haven't 
tried it more recently than that.  So the project is not dead, but that 
doesn't mean there aren't issues at the moment.





On 01/06/2018 04:33 PM, Paul Johnson wrote:

Is GeoChat  down
or defunct now?  I haven't been able to connect to it in a couple days now.



___
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: [Talk-it] disused:

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 18:07, demon.box  wrote:
> 
> se utilizzo il prefisso disused: tutti questi oggetti spariscono ma invece
> ci sono ancora!


come ti ho scritto prima, io farei la distinzione se un servizio/attività viene 
sospeso/a (quindi non c’è più, ma ci sono ancora dei segni) oppure qualcosa 
apparentemente non viene più usato (quindi continua a esistere).

In qualche modo anche dalla cosa: un emergency=telephone e disused=yes non 
sembra buon tagging, per un pipeline invece c’è meno rischio.

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

[Talk-es] OpenLocalMap: OSM en tu localidad

[yo paseopor]

Buenas !
Tal y como habeis podido leer seguramente en el grupo de Telegram hemos
conseguido la actualización de una herramienta antigua que @KonfrareAlbert
desarrolló para su población y que podeis encontrar en [1]. Esta
herramienta ya era conocida por la comunidad pero no acababa de encontrar
nuestro interés por desarrollarla, modificarla, etc. Años después y con
otro debate de fondo (el detectar un etiqueta determinada) unido a un
interés concreto (el crear un mapa con una etiqueta determinada) se van
desarrollando soluciones en esa dirección. Enmedio de ese desarrollo se
recupera la idea de la herramienta, que no es más que un fork de osm-pois
de Humitos . La novedad esta vez es hacerla totalmente autónoma sin
requerimiento de ninguna máquina externa, sólo una cuenta de Github. Y el
añadirle la explicación para poder hacer una personalización sencilla y
rápida de toda la herramienta.

El resultado lo hemos llamado OpenLocalMap y encontrareis su código en [2]
y una versión en funcionamiento en [3]
Básicamente OLM es un Mapa OSM centrado en una población concreta al que se
le añade información de proyectos de terceros que también tienen su base en
OSM o en fuentes libres. En concreto se ofrece y utiliza :

-Mapa centrado en la localidad (y con posibilidad de cambios de capas)
(OpenStreetMap y Leaflet)
-Muestra de PDI (Puntos de Interés, vamos, nuestros POIs) (Overpass)
-Búsqueda en la localidad o bien en el resto del mundo (Nominatim)
-Imágenes de Mapillary (en construcción) (Mapillary)
-Recorridos personalizados por el municipio (Graphhopper)
-Artículos sobre la localización (Wikipedia)
-Mapa concreto , exterior , personalizable (ejemplo aparcamiento Overpass)
-Enlaces (explica otros proyectos de OSM, personalizable 100%)
-Modo experto (en construcción) (iD)
-Explicación de todo el proyecto (personalizable 100%)

Todo ello sólo a partir de una cuenta Github, por lo que es forkeable y
personalizable de forma muy sencilla tal y como explico en [4] (se reduce a
modificar un par de archivos buscando la cadena "MODIFICAR AQUÍ").
El resultado es el que veis en [3]: un mapa sencillo pero potente, ideal
para mostrar la utilidad de OSM a los responsables de asociaciones y
territorios, totalmente adaptable y ampliable.
Por lo que os animo a que le echéis un vistazo y a que os decidáis a crear
el vuestro OLM de la localidad que estiméis oportuno.
Aprovecho este correo para agradecer a Konfrare Albert por su idea y la
guía para la adaptación de su herramienta así como a Joan Montané por
facilitar la ubicación del código en el repositorio de la comunidad
catalana.


 [1] http://www.konfraria.org/osm/cerca/web
 [2] https://github.com/OSM-Catalan/openlocalmap
 [3] https://osm-catalan.github.io/openlocalmap
 [4]
http://yopaseopor.blogspot.com.es/2018/01/yorenderizo-openlocalmap-osm-en-tu.html
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau

[marc marc]

Il y a en permanence un nombre important de polygone ouvert.
319 en France en ce moment
https://osmose.openstreetmap.fr/fr/errors/?country=france*=1040
Depuis 2 semaines je passe un peu de temps à en corriger.
La seule cause récente trouvée dans ceux dont j'ai trouvé l'origine 
précise vient contre tout attente vient d'utilisateur sous josm.
Il suffit de télécharger une relation via overpass (au hasard une ligne 
de bus). de couper un chemin qui la compose (au hasard découpe 
conflictuel pour le rendu d'un rond-point) pour se retrouver avec une 
cassure dans les autres relations qui utilisent ces chemins.
L'autre causse de casse avec la même méthode c'est la découpe d'une 
place tagé comme aire et utilisé dans + d'une relation route.
Une solution serrait que josm fasse toujours une recherche
des relations parents lorsqu'on coupe ou supprime un chemin.
Car si josm ignore l’existence d'une relation parent,
celle-ci est fatalement cassée après l'opération.
Je n'ai pas trouvé cependant de moyen pour retrouver facilement
le dernier état valide d'un polygone.

Le 07. 01. 18 à 00:07, orhygine a écrit :
> En effet, j'ai vu cette anomalie en jetant un coup d’œil aux éditions 
> d'un nouveau contributeur ayant mis un changeset en "review requested" 
> dans le coin. Je lui ai d'ailleurs fait un certain nombre de remarques 
> sur plusieurs changesets. Mon objectif, est en toute bienveillance, de 
> l'accompagner dans son apprentissage d'OSM, plutôt dans l'optique de lui 
> permettre de corriger lui même, dans la mesure du possible.
> 
> Dans le cas présent, j'ai pu voir qu'il avait touché ce polygone et je 
> me demandais si sa modification pouvait-être la cause de l'anomalie. En 
> l'occurrence, l'idée serait de lui indiquer les risques potentiels 
> lorsque l'on touche ce types d'objets plutôt que de corriger lui même. 
> Il ne s'agit pas de manip simples et même un "novice" comme moi avec 9 
> ans de projet et un nombre de contributions non négligeable est 
> légèrement retissant lorsque qu'il s'agit d'éditer les mega-polygones 
> CLC :) Mais je sais, il faut que je m'y mette...
> 
> Donc au delà de la correction, si quelqu'un peut m'indiquer la méthode 
> debuger ce type de problème, je suis preneur. Quel outil utiliser pour 
> consulter l'historique d'une relation et savoir à quel moment elle a été 
> cassée.
> 
> Salutations,
> Christophe
> 
> 
> Le 6 janvier 2018 à 19:03, jabali  > a écrit :
> 
> Quand on voit la quantité de détails terrain (zones boisées -
> résidentielles
> - fermes - paturages) qui sont recouverts par ce MP CLC farm , si je
> peux
> avancer mon humble avis, il aurait peut-être été mieux de le laisser
> ouvert
> pour que ce contributeur ,novice certes mais motivé, puisse
> retravailler son
> secteur.
> Maintenant, la matrice s'est refermée pour les xx prochaines années.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ca] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

hebdoOSM Nº 389 2017-12-26-2018-01-01

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 389 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9835/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-GB] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

hebdoOSM Nº 389 2017-12-26-2018-01-01

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 389 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9835/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[talk-ph] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-in] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[OSM-talk-ie] weeklyOSM #389 2017-12-26-2018-01-01

[weeklyteam]

The weekly round-up of OSM news, issue # 389,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9835/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-fr] review_requested=yes sans commentaire pour aider les nouveaux

[marc marc]

Pour les flux rss, il a fait un autre outil pour les notes par pays.
mais pour les "review" apparemment pas.
Si c'est utile, je peux lui proposer.

Pour la bbox, c'est pour fractionner une partie de la France ou au 
contraire couvrir une + grande zone ?
Je me pose la question vu le nombre raisonnable tant de demande que 
d'aidant.

Pour surveiller tous les changements d'une bbox
https://simon04.dev.openstreetmap.org/whodidit/
https://tyrasd.github.io/latest-changes/

Le 06. 01. 18 à 07:40, Stéphane Péneau a écrit :
> Est-ce qu'il y a une solution pour obtenir un flux rss de ces changesets 
> sur une bounding box ?
> 
> Stf
> 
> Le 05/01/2018 à 18:19, marc marc a écrit :
>> Le 05. 01. 18 à 18:09, pepilepi...@ovh.fr a écrit :
 je relance le message car je pense que ce serrait utile d'aider ceux 
 qui
 se posent des questions sur leur contribution.
 je retourne régulièrement voir ce qu'ils ont fait après mon message,
 ceux qui continue à être actif ont généralement corrigé leurs erreurs.
 le lien affiche les nouveaux qui n'ont eu aucun commentaire.
> https://resultmaps.neis-one.org/osm-suspicious?country=140=96=10=c=review_requested%3Dyes=t=>=10=d=n=t
>  
>
 si on arrive à traiter cette liste de demande d'aide, on peux toujours
 changer le critère pour viser + large.
>>> Tout ce qu'il faut faire c'est mettre un commentaire expliquant les
>>> erreurs ou constatant simplement que c'est tout bon ?
>> Oui :)
>> Je rajoute une ligne de bienvenue pour faire sympa.
>> Mais je laisse le soin au contributeur initial de corriger lui-même ses
>> erreurs pour apprendre.Si on corrige sans lui dire, il l'ignore.
>> Il n'y a que si c'est grave ou compliqué à corriger pour un débutant que
>> je corrige moi-même (par exemple un nœud déplacé par mégarde sur une
>> grande distance ou un relation effacée impossible à restaurer avec iD).
>> Mais si tu souhaites faire autrement, n'hésites pas.
>> ___
>> 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] Challenge ? Si on dégommait du rose ?

[orhygine]

Merci Vincent.
J'ai un comportement étrange d'Osmose. Si je charge cette URL, rien ne
s'affiche. Je choisis "High" dans la dropdown gravité puis je remets "All"
et les anomalies s'affichent avec application correcte des filtres
item=7170 et class=13...
Christophe


Le 6 janvier 2018 à 16:33, Vincent Privat  a
écrit :

> Avec cette URL ça fonctionne chez moi:
> http://osmose.openstreetmap.fr/fr/map/#source=14708=
> 7170=13=12=43.6043=1.4618=
> T=1%2C2%2C3==
>
> Vincent
>
> Le 6 janvier 2018 à 16:17, orhygine  a écrit :
>
>> Salut,
>> Cette analyse est en effet intéressante et fait ressortir beaucoup de
>> routes manquantes. Du travail qui va occuper un moment...!
>>
>> Dans Osmose, si j'active la checkbox routes, cela affiche également les
>> erreurs de limite admin décalée (par exemple sur cette zone
>> osmose.openstreetmap.fr/fr/map/?lat=43.386224379340945=-
>> 0.3609073162078858=17#zoom=14=43.12172=-0.78399=7170).
>> Si l'on veut se concentrer sur les routes, il serait intéressant de
>> n'afficher que les classes 13.
>>
>> Savez-vous s'il est possible de ne filtrer dans la vue carto que les
>> erreurs de classe 13 ? J'ai tenté l'ajout de "=13" dans l'URL sans
>> succès.
>>
>> Salutations,
>> Christophe
>>
>> Le 6 janvier 2018 à 15:29, Christian Quest  a
>> écrit :
>>
>>> Un petit bilan après une bonne dizaine de jours...
>>>
>>> L'analyse comparant la voirie du cadastre avec OSM est fort intéressante
>>> !
>>>
>>> En zone urbaine, elle permet de détecter de petites impasses, des
>>> chemins, de nouveaux lotissements, etc.
>>> En zone plus rurale, elle est aussi intéressante même si elle remonte
>>> des chemins où le cadastre à prolongé le noms des rues, je pense souvent à
>>> tort.
>>>
>>> Je vous la recommande donc après plus d'une semaine d'usage régulier,
>>> elle ne m'a pas fait perdre de temps et trouvé des manques difficiles à
>>> détecter sans être sur le terrain.
>>>
>>> http://osmose.openstreetmap.fr/fr/errors/?source=14708=
>>> 7170=13
>>>
>>> 
>>> Les principaux défauts sur les rond-points et places sont résolus... il
>>> n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être
>>> détectés.
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Christophe aka orhygine | http://orhyginal.free.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
>
>


-- 
Christophe aka orhygine | http://orhyginal.free.fr |
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Ang. källor för korrigering av mindre sjöar/skogstjärnar

[Essin]

Hej!

Yahoo syftar på gamla satellitbilder [1] så namnet kommer ändå från någon
annan källa (inklusive local_knowledge). Om man får tro wikin [2] är det
numera att föredra att sätta source-taggar på ändringssetet, bland annat
just eftersom det är jobbigt och ibland otydligt att ange vilken info om
ett objekt som kommer från vilken källa.

[1] https://wiki.openstreetmap.org/wiki/Yahoo!_Aerial_Imagery
[2] https://wiki.openstreetmap.org/wiki/Key:source

Hälsningar
Essin

Den 6 januari 2018 15:36 skrev Christian Asker :

> Hej. Ekonomiska kartan har ju ofta sjönamn med. Hur ser det ut för ditt
> fall?
>
> Mvh Christian
>
> "Jimmy Utterström"  skrev: (6 januari 2018 13:20:51
> CET)
>
>> Hej!
>> Jag sitter och ser över mappningar som gjorts i södra lappland och håller
>> bland annat på att korrigera lite större skogsytor som ser ut att ha lagts
>> till utan att skapa multipolygoner så att de inomliggande sjöarna renderas
>> korrekt. Jag har dock upptäckt en inkorrekt mappning där en mindre
>> skogstjärn har givits samma namn som en större intilliggande. Jag funderar
>> dock lite kring vilka källor som är acceptabla att ange som "source" när
>> jag senare checkar in min korrigering. Det är nämligen så att den användare
>> som lagt till den (gunnar1m) har angivit "Yahoo" som tidigare källa. Jag
>> skulle därför vilja ange en ny källa så att den person som utförde den
>> ursprungliga mappningen kan kontrollera varifrån jag fått uppgifterna från.
>>
>> I detta fall skulle jag kunna använda "local knowledge" eftersom det är
>> mina hemtrakter och jag har hyfsad koll på området,  men bäst vore ju om
>> det gick använda exempelvis SMHIs sjöregister som källa. För där finns det
>> korrekta uppgifter för tjärnen. Men som jag förstått det så är inte CC BY
>> 4.0 (som SMHI använder?) helt kompatibel med OSM, stämmer det? Finns det
>> några andra bättre datakällor för sjöar jag kan titta i?
>>
>> Med vänliga hälsningar,
>> Jimmy Utterström
>>
>
> --
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
>
> ___
> 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] Ang. källor för korrigering av mindre sjöar/skogstjärnar

[Erik Johansson]

2018-01-06 13:20 GMT+01:00 Jimmy Utterström :
> som jag förstått det så är inte CC BY 4.0 (som SMHI använder?) helt 
> kompatibel med OSM, stämmer det? Finns det några andra bättre datakällor för 
> sjöar jag kan titta i?

Det stämmer CC-BY är knepig och fungerar inte med OSM mest för att vi
är mer liberala egentligen.

Jag har för mig att SMHI och  Havs- och vattenmyndigheten är vänligt
inställda till OSM, när jag senast talade med dom  så det hela rann ut
i  sanden från min sida för att jag misstänkte att data var
kontaminerat av LM data och därför bara kunde släppas som CC-by, men
nu släpper ju LM mycket data som CC-zero så det borde bli lättare. Så
min fråga är har du kollat på den uppsjö av data som är CC-zero?

Det är ju inte bra att använda källor som idag är licensierade som
CC-by men i framtiden antagligen kommer bli CC-zero, även om det är
lockande.

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

Re: [Talk-it] standardizzazione stradario comunale

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 18:44, Andrea Musuruane  wrote:
> 
> In ML abbiamo sempre concordato di seguire la normativa ISTAT e anche tu in 
> una mail del 10 aprile dicevi che "  allora metterei questa forma appena 
> hanno provveduto i comuni a rendere ufficiale la nuova dicitura."



si, e lo vedo ancora così: appena hanno deliberato possiamo usare i nuovi nomi 
in official name, così come i comuni hanno messo i nomi nelle delibere. Vuol 
dire che sono i comuni a fare, e non Istat.


> ...Quindi tutti i comuni dovrebbero già essersi adeguati e comunque 
> l'adeguamento è un obbligo.


si, mi ricordo di questo. Se l’hanno fatto dovrebbe essere facile trovare le 
delibere. Se non lo hanno fatto vuol dire che i nomi sono rimasti quelli 
“vecchi”.


> 
> Per esserne certo, dovresti leggere le varie delibere di giunta dato che 
> "l’adeguamento alle modalità tecniche indicate per la standardizzazione e la 
> normalizzazione della denominazione estesa [..] non rendono necessaria la 
> sostituzione della cartellonistica stradale o delle targhe indicanti le 
> denominazioni già deliberate non in forma standard".
> Pertanto la cartellonistica non sarà aggiornata.


si, ricordo questo. Per me (e credo anche per chi vuole usare la mappa in loco) 
è più importante quello che si vede, il nome “vero” ma non diffuso potrebbe 
entrare in official_name, ma questo sarebbe comunque sempre il nome dato dal 
comune, sia in regola con Istat, o forse anche no.


> 
> Quindi, vista l'impraticabilità di leggere le tutte le delibere di giunta di 
> tutti i comuni italiani


Quelle riguardanti la toponomastica non sono tante, non è un task impossibile. 
Ci hai chiesto di leggere la normativa Istat per intero (cosa, ammetto, una 
volta ho fatto), nello stesso tempo potremmo leggere materiale rilevante 
(delibere dei nostri comuni sulla toponomastica).


> , e visto che comunque l'adeguamento alle nuove regoleISTAT è un obbligo, 
> tanto vale adeguarsi subito.


no, Istat non ha la competenza di cambiare i nomi, e finché non si cambiano da 
chi lo può fare, non sono da cambiare.

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

Re: [Talk-de] routing.openstreetmap.de

[Richard]

On Sun, Dec 31, 2017 at 01:14:22PM +0100, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 30. Dec 2017, at 22:53, Volker Schmidt  wrote:
> > 
> > Nein.
> > 
> > track hat keine implizite Zugangsbeschraenkung, d.h unter anderem foot=yes.
> > access=agricultural bedeutet laut wiki "Access permission for agricultural
> > vehicles, e.g. tractors"
> > Der Weg is als offen fuer Fussgaenger (und Radfahrer und Reiter) getagged.
> 
> 
> 
> ist access=agricultural denn exklusiv, d.h. alles außer agricultural wäre 
> verboten? Das legt dieses Beispiel im Wiki nahe: „For example 
> access=deliveryon a service road tagged with highway=servicewould imply that 
> all transport modes can use the entrance for delivery only.“
> Man könnte es ja so sehen, dass das explizite access=agricultural das 
> implizite access=yes überschreibt. 
> 
> Im Beispiel hier würde ich sagen, es dürfen nur agricultural Fußgänger und 
> Pferde und Schneemobile rein, motorcar und motorbike aber überhaupt nie, weil 
> das spezifischere Regeln sind und die das allgemeine access überschreiben, 
> m.E. also vermutlich falsch getaggt.

in der Realität ist access=agricultural immer ein öffentlicher Weg weil
er sonst als private gemappt werden solle und für öffentliche Wege gilt
implizit foot=yes ausser wenn es explizit verboten wäre.

Richard


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

Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau

[orhygine]

En effet, j'ai vu cette anomalie en jetant un coup d’œil aux éditions d'un
nouveau contributeur ayant mis un changeset en "review requested" dans le
coin. Je lui ai d'ailleurs fait un certain nombre de remarques sur
plusieurs changesets. Mon objectif, est en toute bienveillance, de
l'accompagner dans son apprentissage d'OSM, plutôt dans l'optique de lui
permettre de corriger lui même, dans la mesure du possible.

Dans le cas présent, j'ai pu voir qu'il avait touché ce polygone et je me
demandais si sa modification pouvait-être la cause de l'anomalie. En
l'occurrence, l'idée serait de lui indiquer les risques potentiels lorsque
l'on touche ce types d'objets plutôt que de corriger lui même. Il ne s'agit
pas de manip simples et même un "novice" comme moi avec 9 ans de projet et
un nombre de contributions non négligeable est légèrement retissant lorsque
qu'il s'agit d'éditer les mega-polygones CLC :) Mais je sais, il faut que
je m'y mette...

Donc au delà de la correction, si quelqu'un peut m'indiquer la méthode
debuger ce type de problème, je suis preneur. Quel outil utiliser pour
consulter l'historique d'une relation et savoir à quel moment elle a été
cassée.

Salutations,
Christophe


Le 6 janvier 2018 à 19:03, jabali  a écrit :

> Quand on voit la quantité de détails terrain (zones boisées -
> résidentielles
> - fermes - paturages) qui sont recouverts par ce MP CLC farm , si je peux
> avancer mon humble avis, il aurait peut-être été mieux de le laisser ouvert
> pour que ce contributeur ,novice certes mais motivé, puisse retravailler
> son
> secteur.
> Maintenant, la matrice s'est refermée pour les xx prochaines années.
>
>
>
>
>
>
>
>
>
> --
> 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
>



-- 
Christophe aka orhygine | http://orhyginal.free.fr |
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Församlingshem: vilka taggar finns och hur ska man använda dem?

[Essin]

Den 30 december 2017 01:22 skrev Erik Johansson :

> 2017-12-28 22:02 GMT+01:00 Essin 
>>
>> När jag tog upp det här i #osm på IRC kom några invändningar mot den
>> första taggningen, för det första eftersom församlingshemmens verksamhet
>> kanske inte är tillräckligt utåtriktad för att räknas som community_centre,
>> för det andra för att "parish hall" i Storbritannien ofta syftar på något
>> snarare motsvarande sockenstuga, alltså den icke-kyrkliga betydelsen av
>> "parish", och för det tredje för att ordvalet passar dåligt på samfund som
>> inte har territoriella församlingar. Det visade sig också att den är
>> ifrågasatt på wikin [5]. Frågan är då: ska man anse att taggningen ändå är
>> en förbättring och använda den med förhoppning om att den ersätts av något
>> ännu bättre senare, eller ska man avstå från att använda den?
>>
>>
> Jag är av den fasta åsikten att OSM taggar måste vara generella och
> specifika, därför är community centre den bästa taggningen, med extra
> taggning som särskiljer det från andra sådana ställen. Församlingshem, ABF
> hus och bygdegårdar fungerar som knutpunkter i många samhällen alltså ett
> community, man vill dessutom gärna kunna hitta dit men  inte till
> organisationen som driver det.
>

Kontroversen om amenity=community_centre rör som jag förstår det
huvudsakligen inte nyttan med en sådan övergripande tagg, utan namnet:
taggen hade en snävare betydelse förut. Men det är kanske en mindre fråga
om man är beredd på att det kan bli massomtaggningar i framtiden.

Kör event_venue om du verkligen måste ha något som redan är definierat, om
> inte det så tycker jag det kan vara en bra idé att köra på den svenska
> termerna som värde till communit_centre= eftersom de är någorlunda
> väldefinierade i vår kulturellasfär. Det med lite Wiki dokumentation är
> perfekt.
>

Kan du utveckla lite varför events_venue skulle vara den lämpligaste
taggen? De flesta aktiviteterna i de församlingshem jag känner till är
sådant som barn- och ungdomsverksamhet, böneluncher och liknande.
Dokumentationen av community_centre=events_venue säger "A community-driven
space for holding events. See also amenity=events_venue for places where
events are commercially organised." och amenity=events_venue exemplifierar
"events" med "formal dinners, dinner-dances, weddings or other
celebrations". Sådana evenemang förekommer i mindre utsträckning i
församlingshem -- principiellt sett visserligen kanske den del som är mest
tillgänglig för icke-medlemmar, men missionerande religioner brukar
välkomna även icke-medlemmar till sina aktiviteter.

Taggar på svenska riskerar att är bara motiverade om fenomenet
"församlingshem" verkligen är unikt för Sverige, och inte går att beskriva
på (brittisk) engelska. Utifrån de diskussioner jag har haft på IRC och
sett på wikin verkar det som att något i vart fall mycket liknande finns i
andra länder.

office=* känns helt fel, förutom när det verkligen är ett kontor som är
> huvudfunktionen (vilket jag aldrig stött på vilket naturligtvis färgar min
> åsikt).
>

Jag håller med om att kontorsverksamheten inte är den huvudsakliga i ett
församlingshem (till skillnad från en renodlad pastorsexpedition, som är
sällsynt nuförtiden men går att hitta), men om den finns där tycker jag
ändå att den är tillräckligt viktig för att taggas _tillsammans med_ taggar
för den sociala verksamheten. Det hade varit en annan sak om kontoren bara
var för driften av själva församlingshemmet.

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

Re: [Talk-de] routing.openstreetmap.de

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 18:39, Sven Geggus  wrote:
> 
> AFAIK ist nicht motorisierter Verkehr erlaubt.


ja, da hatte ich mich unklar ausgedrückt, gemeint war ein allgemeines Verbot 
für das Befahren mit Kraftfahrzeugen, nicht mit jeglichen Fahrzeugen.


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

Re: [Talk-it] Un problema con JOSM

[Max1234Ita]

Beccato.
In effetti avevo attivo il plugin IndoorHelper  (ora non più). Curiosamente,
la regola di controllo era presente addirittura in triplice copia (!)

Inoltre, come temevo, il mio selezionare l'opzione di correzione automatica
non ha fatto altro che aggiungere un tag /level=*/ su tutti gli oggetti che
ho modificato ieri ed oggi...

Per fortuna era poca roba, ed è bastata una ricerca locale (inview level=*)
per individuarli e sistemare le cose. Tranquilli, in quella zona non ci sono
indoor mappati :) 

Grazie a tutti!
Max



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

[OSM-talk] GeoChat

[Paul Johnson]

Is GeoChat  down
or defunct now?  I haven't been able to connect to it in a couple days now.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cz] Detekce z fotek osmhicheck

[majka]

6. ledna 2018 22:30:43 SEČ, "Marián Kyral"  napsal:
>

>Myslím, že první krok byl zjistit, zda máme zmapovány všechny trasy
>(barvy), které na tom rozcestníku jsou.
>

Osobně si moc nadějí nedělám ani v tomhle - dokonce i ty barvy nejsou úplně
jednoduché. Narazila jsem na komplet vybledlé, takže zelená se nedala
poznat, u rybníků zarostlé řasami
 a koneckonců i dnes
za západu slunce pořízená fotka je zajímavá (vpravo nahoře
) - místo červené se
ty nejlépe čitelné tabule ukazují žlutozeleně místo červené.

>Teoreticky by ti to právě s tím přepisem mohlo pomoct. Ale to OCR zatím
>není příliš úspěšné. Hlavně proto, že kvalita fotek je velmi rozdílná.

Navíc spousta i jinak dobře čitelných fotek je problematická úhlem
nafocení, případně jsou rozcestníky zarostlé a lépe než z části zakryté
větvemi nešly nafotit. Opět pár mých příkladů:
ne příliš ideální úhel
 kvůli slunci
další  - slunce +
umístění
změť rozcestníků  +
moje nedostatečná výška, takže foceno výrazně směrem vzhůru
zarostlý rozcestník
, pro mě vysoko,
a to jsem některé větve klackem odsouvala, takže komedie při focení

A samozřejmě ty koláže taky nejsou pro techniku legrace. Za mě - na mnou
nafocených rozcestnících kontroluji, že ty okolní máme zadané. Pokud
nejsou, tak je vkládám do dat - například tenhle
 - jednou to tam budu muset vše prolézt
důkladněji, protože se mi ho najít nepodařilo.

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

Re: [Talk-cz] Detekce z fotek osmhicheck

[Marián Kyral]

Dne 6.1.2018 v 21:04 Jan Skala napsal(a):
> Ahoj,
>
> chtěl jsem se zeptat, co je zač "Detekce z fotek" na
> http://osm.fit.vutbr.cz/OsmHiCheck/

Ahoj,

Diplomová práce, která se snažila o automatické rozpoznání tabulek
rozcestníků, identifikaci barev a následně i OCR.
https://is.muni.cz/th/396113/fi_m/
Vedl Tomáš Kašpárek a něco o tom povídal na OpenAltu (SOTM CZ 2017 ;-)
): https://openalt.cz/2017/program_detail.php#event_241

Koukám, že už to Tom zprovoznil a zkouší to reálně využít. Na SOTM měl
jen demo ;-)
Myslím, že první krok byl zjistit, zda máme zmapovány všechny trasy
(barvy), které na tom rozcestníku jsou.

> Ptám se proto, že jsem nějakou dobu strávil na způsobem detekce v
> datech (spíše ve fotografiích) zcela chybějících rozcestníků. Dám to
> sem jen do zápisu, protože by se to mohlo třeba hodit, nebo někoho
> jiného by něco napadlo.
>
> Způsob jak najít chybějící rozcestník je celkem jednoduchý. Porovnat
> naši mapu s nějakou turistickou a najít ty, které nám chybí, vypravit
> se tam a zmapovat. Jenže já mám rád věci strojově zpracované a tak
> jsem vymyslel následující systém, který využívá naše fotky. Krok 1:
> rozepsat každý rozcestník do XML, krok 2: projít každý rozcestník a
> zjistit, jestli jeho cíle (položky na tabulkách) existují jako
> samostatné rozcestníky, pokud ne, tak vypsat.
>
> ...
>
> A říká, který rozcestník chybí a který na něj odkazuje, aby se snadno
> určila přibližná poloha. Třeba položka vzdálenost není nutná, ani ten
> ref není důležitý. Problém je, kde získat přepis těch tabulek. 

Teoreticky by ti to právě s tím přepisem mohlo pomoct. Ale to OCR zatím
není příliš úspěšné. Hlavně proto, že kvalita fotek je velmi rozdílná.

> Na závěr jen dodám, že nevím kolik procent všech rozcestníků (KČT) nám
> chybí, a jestli to má vůbec cenu, ale programování zdar!
>

To zase ví Gorn. Taky o tom na OpenAltu mluvil:
https://openalt.cz/2017/program_detail.php#event_239

Marián

> Honza, http://osm.paws.cz
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz


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

Wochennotiz Nr. 389 26.12.2017–01.01.2018

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 389 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2018/01/wochennotiz-nr-389/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-us] Parks, again

[Doug Hembry]

Greetings everyone..

I have a stake in this discussion, being resident in CA and dealing 
regularly with the representation of the various state and local parks, 
Open Spaces, Ecological Reserves, water company lands, National Parks 
and Forests, etc, etc, with which this state is blessed. It's a crazy 
patchwork quilt of what are all, essentially, protected lands.

I'm broadly in agreement (I think) with Bradley White and other earlier 
posters and less so with Steve. My take is that "parks" differ 
essentially in their level of protection, and there is a whole spectrum 
of protection levels. These levels are already well described by the 
boundary=protected_area tag set. Protect_class encompasses a range from 
legally designated wilderness down to local urban parks (plus 
special-purpose areas). Protection_title=*, operator=*, and name=* 
capture information about the responsible jurisdiction (you can throw in 
"park_type" if you like, though it seems superfluous) and access=* 
(along with mapped trails, etc) describes the area's availability for 
public recreation. I don't think we need to embark on some big new 
program to determine how to map California's parks - we already have the 
means to do so. The boundary=protected_area might need some tweaking for 
national or local peculiarities and some discussion about what protect 
levels apply to what types of CA "parks", but it's already there and it 
works and we should just use it.

Protect_class is not just some abstract value of interest only to 
professional ecologists. The general "personality", and type of 
recreation available in a given park - ie, whether you take your dog and 
your kid in a stroller to picnic and play ball, or whether you carry 
survival equipment, bear spray, a PLB and GPS, or something in between - 
is strongly correlated  with level of protection. And given this, the 
importance of the leisure=park/nature_reserve tags for understanding 
"what kind of park is this?" is greatly decreased.

If I can throw in a note of cynicism: I have long suspected that there 
is a lot of deliberate tagging for the renderer going on in this whole 
business. I suspect the propensity for tagging anything with the word 
"Park" in it's name as leisure=park (given the wiki definition, 
seriously ?) stems from a belief by some mappers (no names) that the map 
is improved by fill-coloring all protected lands a light shade of green 
(It's gone so far that someone has been putting leisure=park on National 
Forests in Humboldt County). This is a terrible idea - apart from being 
totally counter to the wiki definition, the uniform green coloration of 
"parks" at medium to high zooms is incompatible with describing land 
cover characteristics with natural=* or landcover=*

IMHO, AT THE VERY LEAST, the background green fill for leisure=park 
could and should be dropped by openstreeetmap-carto - it is unnecessary, 
causes problems, and can be replaced by natural=* or landcover=* . This 
would reduce one incentive for inappropriate use, and if still used 
inappropriately, it wouldn't matter so much.

While on the topic of rendering "parks", I do agree with Steve (again, 
if I'm understanding correctly) that  it would be valuable, if possible 
at some point in the future - both for map clarity as well as providing 
useful information to users - for carto to use different colors for 
different types of boundaries. I differ with Steve in that IMO the 
coloring should be based off protect_class (or at least for several 
bands of protect_class if there are too many distinct values for 
separate colors) rather than jurisdiction. Jurisdiction is less 
meaningful to users than level of protection, and in any case is usually 
obvious from the area name and other tags. Further, boundary rendering 
should indicate access restrictions (access=yes/no/permit) by some means 
- perhaps a dashed line as is presently done for highways.

Happy New Year to all!

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

Wochennotiz Nr. 389 26.12.2017–01.01.2018

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 389 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2018/01/wochennotiz-nr-389/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[OSM-talk-fr] Liste des outils d'OSM FR

[Vincent Frison]

Suite à une ancienne discussion:

Plus globalement je trouve qu'il manque une page (voir un menu) listant
>> tous les super projets fait par OSM FR: osmose, les outils pour BANO ou le
>> cadastre, le serveur de tuile pour ne citer que ceux que je connais...
>>
>
> Tu ne connais pas http://openstreetmap.fr/outils
>

Ba voila c'est exactement la page que j'imaginais !

Mais je trouve ça dommage qu'elle soit aussi difficilement accessible. Le
seul lien que j'ai trouvé, avec difficulté, est tout en bas de la page
Association.

Ne pourrait on pas avoir un lien "Outils" ou "Services" carrément
dans le menu ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu avec relief sur osm.fr

[Vincent Frison]

Le 6 janvier 2018 à 19:36, Christian Quest  a
écrit :

> J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
> l'ombrage...
>
> STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
> certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
> les 2Go d'où un ombrage incomplet.
>
> Je regarde pour corriger ça, sinon 95% du boulot est fait.
>
> Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 milliards
> de pixels ;)
> Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout le
> dossier du projet fait presque 600Go.
>

Je recréé un nouveau fil de discussion avec un sujet mieux adapté ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 6 janvier 2018 à 19:36, Christian Quest  a
écrit :

> J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
> l'ombrage...
>
> STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
> certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
> les 2Go d'où un ombrage incomplet.
>
> Je regarde pour corriger ça, sinon 95% du boulot est fait.
>
> Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 milliards
> de pixels ;)
> Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout le
> dossier du projet fait presque 600Go.
>

C'est impressionnant !

Mais ce qui l'est encore plus c'est que tu nous sortes ça de ton
congélateur :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Un problema con JOSM

[Damjan Gerl]

06.01.2018 - 20:12 - Max1234Ita:

Grazie per le risposte.

Kendzi3d è disabilitato (credo sia la prima cosa che ho disattivato
installando JOSM la prima volta, dal momento che non lo uso).

Nodi senza tag, non ne risultano in partenza: è come se i nodi venissero
alterati nel momento in cui aggiungo o cancello delle way.
Oggi ho provato di nuovo, mappando (manualmente) alcuni oggetti nuovi: un
paio di filari ed un landuse. Per ognuno dei nodi creati JOSM segnala questo
warning ed anche scegliendo di visualizzare l'oggetto problematico (dal menu
contestuale di JOSM) non mi sembra di vedere alcunché.

La cosa strana è che viene ricercato un tag "level" anche per oggetti che
non mi risulta ne abbiano bisogno (se non sbaglio si usa solo per gli
edifici e per la mappatura indoor).

Potrei anche aprire un ticket agli sviluppatori, ma prima di farlo mi
piacerebbe capire se posso trovare qualche informazione che sia loro un po'
più utile di "non funziona" (probabilmente è una deformazione professionale
:p)

Max


Ho lo stesso problema ed è causato da IndoorHelper plugin, che suppone 
che tutti gli oggetti dovrebbero avere un level tag, ovviamente questo è 
sbagliato. Difatti è solo un warning, che però e molto disturbante. 
Anche se disinstalli IndoorHelper la rule per josm validator resta e 
devi disabilitarla a mano. Vai in Preferenze, clicchi sull'icona di 
Validator (il spunta blu) e scegli Regole controllo etichette. Sotto 
Regole attive: deselezioni la regola Indoor. Fatto. Ora non da più 
warning su oggetti che non hanno il level tag.


Ciao
Damjan

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

Re: [Talk-it] Nuovo utente che cancella

[liste DOT girarsi AT posteo DOT eu]

Il 06/01/2018 21:01, francesco gargano ha scritto:

alle prime armi quanto vogliamo ma ha eliminato anche una strada
provinciale
http://www.openstreetmap.org/way/388914238/history



Mica la sto difendendo, solo non mi pare il solito spammer che si 
impegna, spero invece risponda e tranquillamente risolva-imparando tutto 
qui.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it] disused:

[demon.box]

Certo "non si mappa per il rendering" e sono comunque perfettamente d'accordo
sia ben chiaro, anche perchè il rendering non lo temo assolutamente visto
che le mie mappe me le confeziono come voglio, ma il mio problema è un
altro: desidererei mappare correttamente e per fare ciò devo prima
comprendere a fondo le regole.

Quindi tornando sul pezzo, il discorso del "disused" consiste nel marcare
come tale la funzione che non c'è più (cioè la non funzione) ma non
l'oggetto stesso.
Intendo dire che è la funzione ad essere "disused" e non l'oggetto stesso.

Infatti capisco benissimo l'uso del prefisso disused: ad es. su amenity che
diventa disused:amenity nulla da dire, ma rimango invece ancora perplesso
fondamentalmente su 2 categorie di tags: building e man_made perchè quando
voglio indicare che sono disused è la loro funzione ad essere non più attiva
ma non l'oggetto stesso.

Un building rimane sempre un bulding anche se non più utilizzato (forse
potrebbe starci un building=disabled così come esiste building=ruins ??) e
perciò (al di là della questione rendering) faccio fatica a metabolizzare
disabled:building=yes

Stesso discorso vale per i man_made, ad es. una man_made=tower (ad esempio +
tower_type=communication) se non viene più utilizzata rimane sempre tower e
cambiare il tag con disused:man_made=tower mi sembra proprio errato, semmai
quello da cambiare è tower_type=communication in
disused:tower_type=communication, non siete d'accordo?

In conclusione il prefisso disused: si DEVE mettere davanti a QUALSIASI tag?
Grazie.
--enrico





--
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: [Talk-it] Nuovo utente che cancella

[francesco gargano]

alle prime armi quanto vogliamo ma ha eliminato anche una strada
provinciale
http://www.openstreetmap.org/way/388914238/history

2018-01-06 20:56 GMT+01:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:

> Il 06/01/2018 20:48, Andreas Lattmann ha scritto:
>
>> Scusate, è già stato segnalato questo utente[1]?
>> Grazie.
>>
>> [1] http://www.openstreetmap.org/changeset/55205835#map=8/41.927/14.683
>>
>> Andreas Lattmann
>>
>>
> Guardando i suoi changeset e quando si è iscritta, sembra un'utente alle
> prime armi che ha fatto un pò di casino,  ma non sembra reticente
> forse.
>
>
>
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
>
>
> ___
> 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: [Talk-it] Nuovo utente che cancella

[liste DOT girarsi AT posteo DOT eu]

Il 06/01/2018 20:48, Andreas Lattmann ha scritto:

Scusate, è già stato segnalato questo utente[1]?
Grazie.

[1] http://www.openstreetmap.org/changeset/55205835#map=8/41.927/14.683

Andreas Lattmann



Guardando i suoi changeset e quando si è iscritta, sembra un'utente alle 
prime armi che ha fatto un pò di casino,  ma non sembra 
reticente forse.




--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it] Un problema con JOSM

[liste DOT girarsi AT posteo DOT eu]

Il 06/01/2018 20:19, Max1234Ita ha scritto:

In ogni caso, ho appena provato  ad aggiunger quest'oggetto:
https://www.openstreetmap.org/way/551314351

ed ho aggiunto il piccolo edificio alla fine del track.

Mi sono usciti warning per entrambi, oltre che per la strada "unclassified"
da cui il track si dirama, cui si è aggiunto un nodo all'intersezione delle
due way.

Ho caricato senza correggere alcunché, stavolta.

Se qualcuno sa dirmi cosa c'è di sbagliato...
Max




Ho selezionato una parte della zona, mi esce solo questo warning:

Waterway ends without a connection to another waterway or the direction 
of the waterway is wrong. (1)


Vale a dire che c'è una way (waterway=ditch) che finisce senza buttarsi 
in qualche fiume/torrente/o altro, insomma non sarebbe completato, ma 
non è un problema, solo un'avvertimento che la mappatura non è completa.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

[Cavok]

Super Merci marc marc. C'étaient donc bien des erreurs injustifiées...

Le 6 janvier 2018 à 18:09, marc marc  a écrit :

> Le 04. 01. 18 à 22:55, Marc M. a écrit :
> > Le 04. 01. 18 à 19:31, Cavok a écrit :
> >> Vous pouvez voir des erreurs par ici
> >> http://osmose.openstreetmap.fr/fr/map/?item=2060=17;
> lat=46.8011892=1.6681943
> >>
> >>
> >> Toutes ces erreurs sont apparues le 02 jan 2018, alors que ces
> >> contributions
> >> addr:housenumber date de 2012
> >
> > il y a un bug général côté osmose ou de sa base de donnée
> >> https://osmose.openstreetmap.fr/fr/errors/graph.png?source=
> 668=2060=1
> >>
> >
> > j'en ai parlé à Fred et ouvert un ticket
> > https://github.com/osm-fr/osmose-backend/issues/260
> > un peu de patience :-)
>
> réponse de Fred : ce problème a disparu
> > https://osmose.openstreetmap.fr/fr/errors/graph.png?source=
> 668=2060=1_date=2018
>
> l'exemple de Cavok ci-dessus n'est plus en erreur.
>
> ___
> 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-it] Nuovo utente che cancella

[Andreas Lattmann]

Scusate, è già stato segnalato questo utente[1]?
Grazie.

[1] http://www.openstreetmap.org/changeset/55205835#map=8/41.927/14.683

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] Un problema con JOSM

[Max1234Ita]

In ogni caso, ho appena provato  ad aggiunger quest'oggetto:
https://www.openstreetmap.org/way/551314351

ed ho aggiunto il piccolo edificio alla fine del track.

Mi sono usciti warning per entrambi, oltre che per la strada "unclassified"
da cui il track si dirama, cui si è aggiunto un nodo all'intersezione delle
due way.

Ho caricato senza correggere alcunché, stavolta.

Se qualcuno sa dirmi cosa c'è di sbagliato...
Max



--
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: [Talk-it] Un problema con JOSM

[Max1234Ita]

Grazie per le risposte.

Kendzi3d è disabilitato (credo sia la prima cosa che ho disattivato
installando JOSM la prima volta, dal momento che non lo uso).

Nodi senza tag, non ne risultano in partenza: è come se i nodi venissero
alterati nel momento in cui aggiungo o cancello delle way.
Oggi ho provato di nuovo, mappando (manualmente) alcuni oggetti nuovi: un
paio di filari ed un landuse. Per ognuno dei nodi creati JOSM segnala questo
warning ed anche scegliendo di visualizzare l'oggetto problematico (dal menu
contestuale di JOSM) non mi sembra di vedere alcunché. 

La cosa strana è che viene ricercato un tag "level" anche per oggetti che
non mi risulta ne abbiano bisogno (se non sbaglio si usa solo per gli
edifici e per la mappatura indoor).

Potrei anche aprire un ticket agli sviluppatori, ma prima di farlo mi
piacerebbe capire se posso trovare qualche informazione che sia loro un po'
più utile di "non funziona" (probabilmente è una deformazione professionale
:p)

Max



--
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] Rendu avec relief sur osm.org

[Christian Quest]

J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur
l'ombrage...

STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre
certaines dalles de 10° x 10° étaient trop volumineuses et avaient dépassé
les 2Go d'où un ombrage incomplet.

Je regarde pour corriger ça, sinon 95% du boulot est fait.

Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 milliards
de pixels ;)
Le dossier avec les tuiles finales et leurs overview pèse 133Go... tout le
dossier du projet fait presque 600Go.

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

Re: [Talk-it] disused:

[Lorenzo "Beba" Beltrami]

Il giorno 6 gennaio 2018 18:07, demon.box  ha
scritto:

> [...]
> se utilizzo il prefisso disused: tutti questi oggetti spariscono ma invece
> ci sono ancora!
>
> cosa ne pensate?
>

Ciao Enrico,
"spariscono" nel caso di OSM è relativo:
http://www.openstreetmap.org/#map=19/44.60931/10.51351=D
Come vedi questa abandoned:building è invisibile se usi lo stile Standard,
ma  visibilissima se metti l'opzione "Dati della mappa".

Spostiamo il punto di vista.
Poniamo che io voglia fare una mappa tutta mio in cui evidenzio solo gli
edifici in disuso. Allora chiederò al db di OSM di darmi l'elenco di tutti
i disused:building del mondo e li disegnerò sulla mia mappa.
Se il tag disused=* viene marcato come desueto in favore di disused:* nel
momento in cui tu togli disused:building e lo sostituisci con disused=yes
allora rendi l'edificio "invisibile" alla mia mappa speciale.

(L'esempio è base base, ma spero di aver dato l'idea... ;-)

Per questo si dice "non si mappa per il rendering", perché il rendering che
usi tu in quel momento (ad esempio lo stile "Standard") non è detto che sia
quello che va bene per tutti.
Per rendere il mapping universale si sceglie un sistema di regole (i tag
elencati nel wiki, per intenderci).
Decise le regole si crea il rendering di conseguenza.

Nello stile "Standard" si è deciso un set di elementi da disegnare,
purtroppo disused:building non rientra tra questi...
Si può sempre provare ad aprire una discussione sul sito dedicato:
https://github.com/gravitystorm/openstreetmap-carto/issues

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

Re: [Talk-de] Kartendruck hochauflösend

[Markus]

Hallo Hartmut, hallo Martin,

>> man müsste entweder schauen inwieweit man den OpenSeaMap Renderer
>> dazu bewegen kann gößerflächige Bereiche zu rendern als 256x256 Pixel
>> große Kacheln, oder man geht den klassischen Weg die einzelnen Kacheln
>> des gewünschten Bereiches im passenden Zommlevel zu sammeln und dann
>> wieder zu einem großen Bild zusammenzufügen.
> 
> tiles stitchen ist zwar einfach (z.B. mit bigmap.cgi), aber es liefert nicht 
> 150dpi, da würden die Schrift und Icons viel zu klein im Ausdruck. Man müsste 
> das direkt im Renderer anpassen, und die Icons müssten in entsprechender 
> Auflösung oder als Vektoren vorliegen.

Ja, die Icons liegen m.W. alle als SVG vor.
Wie man den Renderer anpassen müsste/kann weiss ich nicht.

Deshalb suche ich jemanden, der das professionell übernimmt :-)

Mit herzlichem Gruss,
Markus



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

Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau

[jabali]

Quand on voit la quantité de détails terrain (zones boisées - résidentielles
- fermes - paturages) qui sont recouverts par ce MP CLC farm , si je peux
avancer mon humble avis, il aurait peut-être été mieux de le laisser ouvert
pour que ce contributeur ,novice certes mais motivé, puisse retravailler son
secteur.
Maintenant, la matrice s'est refermée pour les xx prochaines années.









--
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: [Talk-it] disused:

[Damjan Gerl]

  
  
06.01.2018 - 18:07 - demon.box:


  ...per la cronaca ho appena finito di sistemare tutti i miei
amenity=hunting_stand con, a seconda dei casi:

abandoned:amenity=hunting_stand
disused:amenity=hunting_stand

mi rimango però parecchi casi dove non trovo una valida alternativa a
disused=yes:

building=yes + disused=yes
building=industrial + disused=yes
power=tower + disused=yes
man_made=pipeline + disused=yes
man_made=water_well + disused=yes
man_made=adit + disused=yes

se utilizzo il prefisso disused: tutti questi oggetti spariscono ma invece
ci sono ancora!

cosa ne pensate?
grazie
--enrico



Spariscono perché il rendering non prende conto del disused, me è un
problema di rendering :-)
Io userei il disused: su tutti ...

D.
  


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

Re: [Talk-it] standardizzazione stradario comunale

[Andrea Musuruane]

Ciao Martin!

2018-01-06 15:55 GMT+01:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 6. Jan 2018, at 14:32, Marcello  wrote:
> >
> > Sull'argomento c'era stata una discussione anche ad aprile,
> > http://gis.19327.n8.nabble.com/nomi-con-date-tp5894982.html, alla fine
> > mi sembra che il consenso a seguire la direttiva Istat per le date mi
> > sembra abbastanza unanime.
>
>
> in generale le direttive Istat non hanno moltissima rilevanza per noi, e
> non hanno nemmeno valenza sul nome di una strada (o forse sbaglio?) nel
> senso che sono i comuni a decidere i nomi, e se non provvedono al
> cambiamento del nome, rimane.
>

In ML abbiamo sempre concordato di seguire la normativa ISTAT e anche tu in
una mail del 10 aprile dicevi che *" ISTAT ha dato le regole e se c'è una
legge che dice che i comuni devono adeguarsi e ridefinire come si scrivono
i nomi sul loro territorio (penso che ci sia questa regola), allora
metterei questa forma appena hanno provveduto i comuni a rendere ufficiale
la nuova dicitura."*

Nella normativa, che ti consiglio di leggere per intero (anche se capisco
che per un non madrelingua possa essere complicato :-/), c'è scritto
che *"ciascun
Comune deve provvedere, con una o più delibere anche di carattere
cumulativo, ad adeguare le denominazioni esistenti già deliberate alle
regole tecniche indicate dall’Istat, entro l’entrata in vigore di ANNCSU"*.
Quindi tutti i comuni dovrebbero già essersi adeguati e comunque
l'adeguamento è un obbligo.

Per esserne certo, dovresti leggere le varie delibere di giunta dato
che *"l’adeguamento
alle modalità tecniche indicate per la standardizzazione e la
normalizzazione della denominazione estesa [..] non rendono necessaria la
sostituzione della cartellonistica stradale o delle targhe indicanti le
denominazioni già deliberate non in forma standard".* Pertanto la
cartellonistica non sarà aggiornata.

Quindi, vista l'impraticabilità di leggere le tutte le delibere di giunta
di tutti i comuni italiani, e visto che comunque l'adeguamento alle nuove
regole ISTAT è un obbligo, tanto vale adeguarsi subito.

Ciao,

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

Re: [Talk-de] routing.openstreetmap.de

[Sven Geggus]

Martin Koppenhoefer  wrote:

> in Baden-Württemberg ist das Befahren von Wirtschaftswegen grundsätzlich
> nur land- und forstwirtschaftlichem Verkehr gestattet

Bist Du sicher, dass man da mit dem Rad nicht durch darf?

Grob nach Gefühl dürfte man dann nämlich so rund 50% der Radfernwege gar nicht
mit dem Rad befahren.

AFAIK ist nicht motorisierter Verkehr erlaubt.

Gruss

Sven

-- 
"C Is Quirky, Flawed, And An Enormous Success."
(Dennis M. Ritchie)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-it] standardizzazione stradario comunale

[Andrea Musuruane]

Ciao,

2018-01-06 14:32 GMT+01:00 Marcello :

> Sull'argomento c'era stata una discussione anche ad aprile,
> http://gis.19327.n8.nabble.com/nomi-con-date-tp5894982.html, alla fine
> mi sembra che il consenso a seguire la direttiva Istat per le date mi
> sembra abbastanza unanime. Sulla decisione maiuscole o minuscole invece
> l'Istat non è di aiuto, dato che usa solo il maiuscolo, la pagina wiki
> dice che si seguono le regole della lingua italiana, poi però negli
> esempi mette i titoli onorifici in maiuscolo.


Per un riassunto di cosa prevede la lingua italiana per maiuscole e
minuscole:
http://www.accademiadellacrusca.it/it/lingua-italiana/consulenza-linguistica/domande-risposte/uso-maiuscole-minuscole

http://www.treccani.it/enciclopedia/uso-delle-maiuscole_(La-grammatica-italiana)/


In particolare: "*Nell’italiano formale e burocratico, ad esempio nelle
lettere o e-mail commerciali, si può usare la maiuscola (detta maiuscola di
rispetto o reverenziale) sia per gli appellativi e i titoli, sia per i
pronomi personali e gli aggettivi possessivi relativi al destinatario*"

Direi che il nome di una strada è un tipico esempio di italiano formale.


> Per facilitare la vita si
> era proposto o tutte le iniziali in maiuscolo tranne le preposizioni
> (di, del, della, ecc), oppure tutte minuscole, tranne chiaramente i nomi
> propri e i termini Via, Piazza, ecc., senza però arrivare ad una scelta.
>

Personalmente queste due soluzioni non mi piacciono. In lista avevamo
sempre detto di seguire le regole della lingua italiana.

Ciao,

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

Re: [OSM-talk-fr] OSM embarque dans l'IRIS 320

[Christian Quest]

Usage privé, rendu public c'est vrai avec ce reportage, mais ce n'est pas
l'objectif initial ;)

Le 6 janvier 2018 à 18:05, François Lacombe  a
écrit :

> Pour info, peut-être que cela avait déjà été constaté
> https://twitter.com/InfosReseaux/status/949685820289638400
>
> Le train en question semble être unique en Europe, en assurant ses
> tournées d'inspection en s'insérant dans le trafic à grande vitesse.
>
> Je n'ai pas voulu mentionner que je ne voyais pas d'attributions sur les
> captures, peut-être est-ce mentionné dans la page "about" des softs.
>
> François
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

[OSM-talk-ie] AGM meeting for Feb

[Tadeusz Cantwell]

Just as a reminder there was a temporary board elected for OSM Ireland on
the 2nd of December, with a recommendation to elect a full board of
directors in three months time. As the previous two meetings I can arrange
for the AGM to happen in Tog. I will be busy on the Saturday the 10th and
the 24th of that month, so we can either have it on a different weekend or
the first Saturday of March since February is a short month. Please put
forward dates you are available here or on Facebook and we can see what
date suits most people.

Tadeusz Cantwell
Interim Board member OSMI
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] appostamenti di caccia non attivi

[Alberto]

> Puoi farti la tua mappa che non sia Mapnik con diversi strumenti (qgis, 
> maperitive ecc) oppure esortare qualche produttore
> a renderizzare anche dei disused tematici.
> Adattare un database come OSM alle esigenze di Mapnik mi pare sbagliato.
> Il metodo del namespace mi sembra funzionale ad un database. Se si rivelerà 
> tale, i renderizzatori seguiranno.

+1 per disused: in generale

> appunto, un hunting stand non lo metterei a “disused:” perché non lo puoi 
> sapere, potrebbe essere usato in qualsiasi momento,
> finché è utilizzabile. Non c’è un servizio che ora è sospeso, come nel caso 
> di una ferrovia o di un ristorante.

+1 nel caso specifico non metterei nulla

Ciao, Alberto



---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

[marc marc]

Le 04. 01. 18 à 22:55, Marc M. a écrit :
> Le 04. 01. 18 à 19:31, Cavok a écrit :
>> Vous pouvez voir des erreurs par ici
>> http://osmose.openstreetmap.fr/fr/map/?item=2060=17=46.8011892=1.6681943
>>  
>>
>>
>> Toutes ces erreurs sont apparues le 02 jan 2018, alors que ces 
>> contributions
>> addr:housenumber date de 2012
> 
> il y a un bug général côté osmose ou de sa base de donnée
>> https://osmose.openstreetmap.fr/fr/errors/graph.png?source=668=2060=1
>>  
>>
> 
> j'en ai parlé à Fred et ouvert un ticket
> https://github.com/osm-fr/osmose-backend/issues/260
> un peu de patience :-)

réponse de Fred : ce problème a disparu
> https://osmose.openstreetmap.fr/fr/errors/graph.png?source=668=2060=1_date=2018

l'exemple de Cavok ci-dessus n'est plus en erreur.

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

Re: [Talk-it] disused:

[demon.box]

...per la cronaca ho appena finito di sistemare tutti i miei
amenity=hunting_stand con, a seconda dei casi:

abandoned:amenity=hunting_stand
disused:amenity=hunting_stand

mi rimango però parecchi casi dove non trovo una valida alternativa a
disused=yes:

building=yes + disused=yes
building=industrial + disused=yes
power=tower + disused=yes
man_made=pipeline + disused=yes
man_made=water_well + disused=yes
man_made=adit + disused=yes

se utilizzo il prefisso disused: tutti questi oggetti spariscono ma invece
ci sono ancora!

cosa ne pensate?
grazie
--enrico








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

[OSM-talk-fr] OSM embarque dans l'IRIS 320

[François Lacombe]

Pour info, peut-être que cela avait déjà été constaté
https://twitter.com/InfosReseaux/status/949685820289638400

Le train en question semble être unique en Europe, en assurant ses tournées
d'inspection en s'insérant dans le trafic à grande vitesse.

Je n'ai pas voulu mentionner que je ne voyais pas d'attributions sur les
captures, peut-être est-ce mentionné dans la page "about" des softs.

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

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

[Alarig Le Lay]

On sam.  6 janv. 16:18:47 2018, François Lacombe wrote:
> Et donc lorsque tu passes par Londres, tu as le même soucis pour joindre
> l'API OSM ?
> Ou c'est une autre famille de soucis ?

Pour moi ça s’arrête à Londres dans les deux sens :
alarig@airmure ~ % mtr -bzw 2001:630:12:500:219:bbff:fe39:8aba
Start: Fri Jan  5 21:31:24 2018
HOST: airmure   
Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS3215   2a01cb08898cfc010001.ipv6.abo.wanadoo.fr 
(2a01:cb08:898c:fc01::1)  0.0%100.4   0.5   0.3   0.7   0.0
  2. AS3215   2a01cb08a00402150193025300760249.ipv6.abo.wanadoo.fr 
(2a01:cb08:a004:215:193:253   0.0%101.3   2.4   1.0   7.8   1.9
  3. AS5511   2a01:cfc4:0:500::b
 0.0%106.6  12.5   6.6  19.0   4.9
  4. AS5511   bundle-ether104.auvtr4.aubervilliers.opentransit.net 
(2a01:cfc4:0:500::7)  0.0%107.3   9.4   6.9  12.6   1.8
  5. AS5511   et-2-1-7-0.pastr3.paris03.opentransit.net (2001:688:0:2:4::dc)
 0.0%106.4   7.7   6.3  13.7   2.4
  6. AS1299   2001:2000:3080:cd::1  
 0.0%108.3   7.7   6.5  13.1   1.9
  7. AS??????   
100.0100.0   0.0   0.0   0.0   0.0

 1  ae20-0.londpg-sbr2.ja.net (2001:630:0:10::19d)  0.898 ms  1.018 ms  1.076 ms
 2  ae29.londhx-sbr1.ja.net (2001:630:0:10::1c9)  1.294 ms  1.577 ms  1.555 ms
 3  ae0.londhx-ban2.ja.net (2001:630:0:10::3e)  1.291 ms  1.272 ms  1.255 ms
 4  ldn-b3-link.telia.net (2001:2000:3080:fdd::1)  1.432 ms  1.414 ms  1.364 ms
 5  ldn-bb2-v6.telia.net (2001:2000:3019:7a::1)  3.508 ms  1.472 ms  1.457 ms
 MPLS Label=301552 CoS=0 TTL=1 S=0
 MPLS Label=2 CoS=0 TTL=1 S=1
 6  ldn-b5-v6.telia.net (2001:2000:3018:b::1)  1.719 ms  1.658 ms  1.597 ms
 7  bu2.lontr4.London.opentransit.net (2001:688:0:4::bd)  2712.397 ms * *

Après, savoir si les soucis sont liés je ne sais pas, je ne suis pas
chez OTI :D

> > > mais là c'est OTI qui a des soucis hardware.
> > > Visiblement c'est assez tricky
> >
> > Tu as vu ça où ?
> >
> 
> Ici + échanges en interne
> https://twitter.com/jlvuillemin/status/949289162594836480

Okay, merci :)

-- 
alarig


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

Re: [OSM-talk-fr] Modification de couverture du sol du côté de Pau

[Christian Quest]

J'ai refermé ce multipolygone...

Le 6 janvier 2018 à 16:29, JB  a écrit :

> Bonjour,
> Le fait que le way n'ait pas de tag est normal. Les tags sont portés par
> la relation : http://www.openstreetmap.org/relation/276616
> Cette relation n'est pas fermée : les membres outer ne forment pas de
> boucle. Du coup, elle est impossible à rendre.
> J'aurais bien montré ça, mais il semblerait que l'analyseur ne fonctionne
> pas : http://api.openstreetmap.fr/analyse/cgi-bin/index.py
> Je n'ai pas réparé pour que tu puisses regarder. Un coup de JOSM et de la
> motivation si nécessaire, et ça peut repartir.
> JB.
>
>
> Le 06/01/2018 à 15:53, orhygine a écrit :
>
> Salut à tous,
>
> Je constate du côté de Pau une modification au niveau de la couverture du
> sol dans cette zone :
>
> https://www.openstreetmap.org/#map=13/43.3570/-0.3401
>
> Entre les zoom 12 et 13, la couleur de couverture du sol passe de beige à
> gris. Il semblerait qu'une modification ait eu lieu, non encore répercutée
> sur tous les niveaux de zoom.
>
> Cela pourrait venir d'une modification intervenue sur le way 41766403 :
>
> https://aleung.github.io/osm-visual-history/#/way/41766403
>
> A la modification 41, des tags ont été supprimés mais cela commence à
> dater...
>
> Les multipolygones CLC étant une science à part entière, un expert du
> domaine peut-il donner son avis ?
>
> Salutations.
>
> --
> Christophe aka orhygine | http://orhyginal.free.fr |
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?

[Vincent Privat]

Avec cette URL ça fonctionne chez moi:
http://osmose.openstreetmap.fr/fr/map/#source=14708=7170=13=12=43.6043=1.4618=T=1%2C2%2C3==

Vincent

Le 6 janvier 2018 à 16:17, orhygine  a écrit :

> Salut,
> Cette analyse est en effet intéressante et fait ressortir beaucoup de
> routes manquantes. Du travail qui va occuper un moment...!
>
> Dans Osmose, si j'active la checkbox routes, cela affiche également les
> erreurs de limite admin décalée (par exemple sur cette zone
> osmose.openstreetmap.fr/fr/map/?lat=43.386224379340945&
> lon=-0.3609073162078858=17#zoom=14=43.12172=-
> 0.78399=7170). Si l'on veut se concentrer sur les routes, il serait
> intéressant de n'afficher que les classes 13.
>
> Savez-vous s'il est possible de ne filtrer dans la vue carto que les
> erreurs de classe 13 ? J'ai tenté l'ajout de "=13" dans l'URL sans
> succès.
>
> Salutations,
> Christophe
>
> Le 6 janvier 2018 à 15:29, Christian Quest  a
> écrit :
>
>> Un petit bilan après une bonne dizaine de jours...
>>
>> L'analyse comparant la voirie du cadastre avec OSM est fort intéressante !
>>
>> En zone urbaine, elle permet de détecter de petites impasses, des
>> chemins, de nouveaux lotissements, etc.
>> En zone plus rurale, elle est aussi intéressante même si elle remonte des
>> chemins où le cadastre à prolongé le noms des rues, je pense souvent à tort.
>>
>> Je vous la recommande donc après plus d'une semaine d'usage régulier,
>> elle ne m'a pas fait perdre de temps et trouvé des manques difficiles à
>> détecter sans être sur le terrain.
>>
>> http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13
>>
>> 
>> Les principaux défauts sur les rond-points et places sont résolus... il
>> n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être
>> détectés.
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christophe aka orhygine | http://orhyginal.free.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] Modification de couverture du sol du côté de Pau

[JB]

Bonjour,
Le fait que le way n'ait pas de tag est normal. Les tags sont portés par 
la relation : http://www.openstreetmap.org/relation/276616
Cette relation n'est pas fermée : les membres outer ne forment pas de 
boucle. Du coup, elle est impossible à rendre.
J'aurais bien montré ça, mais il semblerait que l'analyseur ne 
fonctionne pas : http://api.openstreetmap.fr/analyse/cgi-bin/index.py
Je n'ai pas réparé pour que tu puisses regarder. Un coup de JOSM et de 
la motivation si nécessaire, et ça peut repartir.

JB.

Le 06/01/2018 à 15:53, orhygine a écrit :

Salut à tous,

Je constate du côté de Pau une modification au niveau de la couverture 
du sol dans cette zone :


https://www.openstreetmap.org/#map=13/43.3570/-0.3401

Entre les zoom 12 et 13, la couleur de couverture du sol passe de 
beige à gris. Il semblerait qu'une modification ait eu lieu, non 
encore répercutée sur tous les niveaux de zoom.


Cela pourrait venir d'une modification intervenue sur le way 41766403 :

https://aleung.github.io/osm-visual-history/#/way/41766403

A la modification 41, des tags ont été supprimés mais cela commence à 
dater...


Les multipolygones CLC étant une science à part entière, un expert du 
domaine peut-il donner son avis ?


Salutations.

--
Christophe aka orhygine | http://orhyginal.free.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] Problème IPv6 chez Orange causant des erreurs avec JOSM

[François Lacombe]

Le 6 janvier 2018 à 16:14, Alarig Le Lay  a écrit :

> Probable, je suis à Rennes, donc tout remonte à Paris et ressort ensuite
> directement ou via Londres ou Frankfort (en gros, mais ça fait une belle
> part du trafic)
>

Et donc lorsque tu passes par Londres, tu as le même soucis pour joindre
l'API OSM ?
Ou c'est une autre famille de soucis ?


> > mais là c'est OTI qui a des soucis hardware.
> > Visiblement c'est assez tricky
>
> Tu as vu ça où ?
>

Ici + échanges en interne
https://twitter.com/jlvuillemin/status/949289162594836480
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?

[orhygine]

Salut,
Cette analyse est en effet intéressante et fait ressortir beaucoup de
routes manquantes. Du travail qui va occuper un moment...!

Dans Osmose, si j'active la checkbox routes, cela affiche également les
erreurs de limite admin décalée (par exemple sur cette zone
osmose.openstreetmap.fr/fr/map/?lat=43.386224379340945=-0.3609073162078858=17#zoom=14=43.12172=-0.78399=7170).
Si l'on veut se concentrer sur les routes, il serait intéressant de
n'afficher que les classes 13.

Savez-vous s'il est possible de ne filtrer dans la vue carto que les
erreurs de classe 13 ? J'ai tenté l'ajout de "=13" dans l'URL sans
succès.

Salutations,
Christophe

Le 6 janvier 2018 à 15:29, Christian Quest  a
écrit :

> Un petit bilan après une bonne dizaine de jours...
>
> L'analyse comparant la voirie du cadastre avec OSM est fort intéressante !
>
> En zone urbaine, elle permet de détecter de petites impasses, des chemins,
> de nouveaux lotissements, etc.
> En zone plus rurale, elle est aussi intéressante même si elle remonte des
> chemins où le cadastre à prolongé le noms des rues, je pense souvent à tort.
>
> Je vous la recommande donc après plus d'une semaine d'usage régulier, elle
> ne m'a pas fait perdre de temps et trouvé des manques difficiles à détecter
> sans être sur le terrain.
>
> http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13
> 
> Les principaux défauts sur les rond-points et places sont résolus... il
> n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être
> détectés.
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christophe aka orhygine | http://orhyginal.free.fr |
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

[Alarig Le Lay]

Hello,

On sam.  6 janv. 11:31:08 2018, François Lacombe wrote:
> Là ce serait à Marseille.
> Vincent à toulouse qui passe par d'autres PNI avec OTI n'a pas ce problème.

Probable, je suis à Rennes, donc tout remonte à Paris et ressort ensuite
directement ou via Londres ou Frankfort (en gros, mais ça fait une belle
part du trafic)

> Petrus étais coté 3215 

Ça je sais bien :) Mais c’est vachement plus proche de OTI que moi.

> mais là c'est OTI qui a des soucis hardware.
> Visiblement c'est assez tricky

Tu as vu ça où ?

-- 
alarig


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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[François Lacombe]

Bonjour Marc, Vincent,

Le 6 janvier 2018 à 14:35, marc marc  a écrit :

> Pour les dates, j'en rêve depuis longtemps d'avoir un moyen de connaître
> la source de photos aériennes la plus récente.
> Mais est-elle disponible ? pour une imagerie qui a une faible couverture
> (par exemple celle d'un département) on peux imaginer qu'elle est proche
> pour toute la zone.
> Mais à l'inverse, j'imagine que celle de Bing n'a pas de date uniforme,
> la maj étant peut-être faite en continu ou par zone.
> Du coup cette donnée est-elle dispo ? cad pour une zone donnée, est-il
> possible de connaître la date de l'imagerie ?
> je rêve d'un imagery_used:date bien pratique en cas de conflit entre un
> vieux survey et une imagerie sat.
>

Il est vrai que les couches comme Bing, et même Bd Ortho nationale soit les
dates ne sont pas dispo, soit elles sont disparates.
Je pensais aux couches d'orthophotos locales, dont certaines existent en
plusieurs millésimes.
Le champ date peut être optionnel.


> Il me semble donc difficile d'attribuer une note globale par source.
> Par contre, sauf délire de ma part, en éditant les alpes,
> j'ai eu un jour un message dans josm me disant que tel couche était
> déclaré la meilleur dans cette zone.
>

A ce niveau de détails, il va etre compliqué de l'ajouter à des plateformes
comme wikidata.E
Ce serait très intéressant par ailleurs comme méta-data.

Vincent, ce n'est pas qu'un problème d'images aériennes, il faut aussi
comparer les autres modes de contributions à conditions qu'elles soient
bien sourcées (survey, connaissance locale...)
Le problème qu'Alain m'exposait, point de départ de la discussion : il
s'est rendu sur les rives d'un lac avec son GPS et a relevé le bord de rive
et indiqué quelque chose comme source=survey dans son changeset ou sur les
objets eux-même.
Quelqu'un est ensuite passé sur la zone et a recalé le tracé obtenu du
terrain avec la vue Bing qui est moins précise.
Cet utilisateur aurait du être averti qu'il a modifié des objets à l'aide
d'une source moins précise qu'un survey.

Pour se faire, je ne vois que la qualification des sources d'images
aériennes et puisqu'il faut qualifier, autant le faire pour tout le monde
(éditeurs OSM, mais pas que).
C'est pour cela que j'ai pensé à Wikidata comme facilitateur. On a vu que
GitHub est adapté pour générer de la configuration, mais difficilement
requêtable.
L'aspect configuration des éditeurs est important et en parti résolu, ce
n'est toutefois qu'un maillon de la chaine complète.
Le fait que ce soit EII qui prenne en charge la génération des
configuration des éditeurs présuppose une interaction très forte puisqu'il
faut que les formats des configs soient bien connus d'EII.
Ne serait-ce pas mieux de n'avoir qu'une base de données interrogeable sans
partager les formats de fichier forcément différents ?


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

Re: [Talk-it] standardizzazione stradario comunale

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 14:32, Marcello  wrote:
> 
> Sull'argomento c'era stata una discussione anche ad aprile,
> http://gis.19327.n8.nabble.com/nomi-con-date-tp5894982.html, alla fine
> mi sembra che il consenso a seguire la direttiva Istat per le date mi
> sembra abbastanza unanime.


in generale le direttive Istat non hanno moltissima rilevanza per noi, e non 
hanno nemmeno valenza sul nome di una strada (o forse sbaglio?) nel senso che 
sono i comuni a decidere i nomi, e se non provvedono al cambiamento del nome, 
rimane.

Al momento non abbiamo un tag per inserire nomi secondo Istat, se name è on the 
ground e official_name il nome dato dal comune ;-)

Al livello di ricerca deve essere risolto: non dovrebbe fare differenza se io 
cerco via iv aprile, 4 aprile o quattro aprile. Se non parlo la lingua, da un 
navigatore mi piacerebbe invece sentire “quattro” quando sul cartello è scritto 
a lettere, e una traduzione del numero 4 quando il cartello riporta un numero, 
quindi cosa c’è scritto sul cartello mi sembra interessante da taggare (non so 
se va meglio in name o in un altro tag tipo signed_name)

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

[OSM-talk-fr] Modification de couverture du sol du côté de Pau

[orhygine]

Salut à tous,

Je constate du côté de Pau une modification au niveau de la couverture du
sol dans cette zone :

https://www.openstreetmap.org/#map=13/43.3570/-0.3401

Entre les zoom 12 et 13, la couleur de couverture du sol passe de beige à
gris. Il semblerait qu'une modification ait eu lieu, non encore répercutée
sur tous les niveaux de zoom.

Cela pourrait venir d'une modification intervenue sur le way 41766403 :

https://aleung.github.io/osm-visual-history/#/way/41766403

A la modification 41, des tags ont été supprimés mais cela commence à
dater...

Les multipolygones CLC étant une science à part entière, un expert du
domaine peut-il donner son avis ?

Salutations.

-- 
Christophe aka orhygine | http://orhyginal.free.fr |
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Ang. källor för korrigering av mindre sjöar/skogstjärnar

[Christian Asker]

Hej. Ekonomiska kartan har ju ofta sjönamn med. Hur ser det ut för ditt fall?

Mvh Christian

"Jimmy Utterström"  skrev: (6 januari 2018 13:20:51 CET)
>Hej!
>Jag sitter och ser över mappningar som gjorts i södra lappland och
>håller bland annat på att korrigera lite större skogsytor som ser ut
>att ha lagts till utan att skapa multipolygoner så att de inomliggande
>sjöarna renderas korrekt. Jag har dock upptäckt en inkorrekt mappning
>där en mindre skogstjärn har givits samma namn som en större
>intilliggande. Jag funderar dock lite kring vilka källor som är
>acceptabla att ange som "source" när jag senare checkar in min
>korrigering. Det är nämligen så att den användare som lagt till den
>(gunnar1m) har angivit "Yahoo" som tidigare källa. Jag skulle därför
>vilja ange en ny källa så att den person som utförde den ursprungliga
>mappningen kan kontrollera varifrån jag fått uppgifterna från.
>
>I detta fall skulle jag kunna använda "local knowledge" eftersom det är
>mina hemtrakter och jag har hyfsad koll på området,  men bäst vore ju
>om det gick använda exempelvis SMHIs sjöregister som källa. För där
>finns det korrekta uppgifter för tjärnen. Men som jag förstått det så
>är inte CC BY 4.0 (som SMHI använder?) helt kompatibel med OSM, stämmer
>det? Finns det några andra bättre datakällor för sjöar jag kan titta i?
>
>Med vänliga hälsningar,
>Jimmy Utterström

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?

[Christian Quest]

Un petit bilan après une bonne dizaine de jours...

L'analyse comparant la voirie du cadastre avec OSM est fort intéressante !

En zone urbaine, elle permet de détecter de petites impasses, des chemins,
de nouveaux lotissements, etc.
En zone plus rurale, elle est aussi intéressante même si elle remonte des
chemins où le cadastre à prolongé le noms des rues, je pense souvent à tort.

Je vous la recommande donc après plus d'une semaine d'usage régulier, elle
ne m'a pas fait perdre de temps et trouvé des manques difficiles à détecter
sans être sur le terrain.

http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13

Les principaux défauts sur les rond-points et places sont résolus... il n'y
a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être
détectés.

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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[Vincent Privat]

Bonjour,
Le sujet a été mainte fois débattu sur le bugtracker de JOSM et @josm-dev,
pas la peine d'en rajouter une couche :)
Les 2 listes sont synchronisées, c'est visible ici:
https://josm.openstreetmap.de/wiki/ImageryCompare
Pour plus de détails cf. les tickets suivants:
https://josm.openstreetmap.de/ticket/10760
https://josm.openstreetmap.de/ticket/11022
https://josm.openstreetmap.de/ticket/12313
https://josm.openstreetmap.de/ticket/12706
https://josm.openstreetmap.de/ticket/14655

A+
Vincent

Le 6 janvier 2018 à 14:35, marc marc  a écrit :

> L'idée est très intéressante.
>
> Pour les dates, j'en rêve depuis longtemps d'avoir un moyen de connaître
> la source de photos aériennes la plus récente.
> Mais est-elle disponible ? pour une imagerie qui a une faible couverture
> (par exemple celle d'un département) on peux imaginer qu'elle est proche
> pour toute la zone.
> Mais à l'inverse, j'imagine que celle de Bing n'a pas de date uniforme,
> la maj étant peut-être faite en continu ou par zone.
> Du coup cette donnée est-elle dispo ? cad pour une zone donnée, est-il
> possible de connaître la date de l'imagerie ?
> je rêve d'un imagery_used:date bien pratique en cas de conflit entre un
> vieux survey et une imagerie sat.
>
> Idem pour la qualité.
> je constate régulièrement qu'une même source peut-être de qualité à un
> endroit et médiocre ailleurs, probablement venant de 2 prises de vue
> différentes faite avec du matériel différent.
> Il me semble donc difficile d'attribuer une note globale par source.
> Par contre, sauf délire de ma part, en éditant les alpes,
> j'ai eu un jour un message dans josm me disant que tel couche était
> déclaré la meilleur dans cette zone.
> j'ignore si c'est une fonction native de josm ou si cela provient du
> plugin utilisé par mémoriser les décalages d'imageries.
> Je n'ai jamais réussi à le reproduire.
>
> 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-it] appostamenti di caccia non attivi

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 00:54, demon.box  wrote:
> 
> definire il capanno di caccia un building (sono perfettamente d'accordo con
> il wiki) mi sembra in effetti eccessivo...


potrebbe esserlo, è una struttura accessibile, costruita con materiale edilizio 
per il soggiorno di una persona, ha un tetto, ecc.
Si potrebbe discutere la permanenza, forse. 

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

Re: [Talk-it] standardizzazione stradario comunale

[Damjan Gerl]

  
  
06.01.2018 - 14:32 - Marcello:


  Sull'argomento c'era stata una discussione anche ad aprile,
http://gis.19327.n8.nabble.com/nomi-con-date-tp5894982.html, alla fine
mi sembra che il consenso a seguire la direttiva Istat per le date mi
sembra abbastanza unanime. Sulla decisione maiuscole o minuscole invece
l'Istat non è di aiuto, dato che usa solo il maiuscolo, la pagina wiki
dice che si seguono le regole della lingua italiana, poi però negli
esempi mette i titoli onorifici in maiuscolo. Per facilitare la vita si
era proposto o tutte le iniziali in maiuscolo tranne le preposizioni
(di, del, della, ecc), oppure tutte minuscole, tranne chiaramente i nomi
propri e i termini Via, Piazza, ecc., senza però arrivare ad una scelta.

Personalmente preferisco la prima soluzione, ossia tutte le iniziali in
maiuscolo


  +1 per questa soluzione. Però facciamo un elenco di preposizioni
  (o eccezioni), così la regola è chiusa e definita :-)
  
  Damjan

  


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

Re: [Talk-it] appostamenti di caccia non attivi

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 00:54, demon.box  wrote:
> 
> ma così facendo sparisce tutto mentre di fatto il capanno esiste ancora
> soltanto che non si spara più, come lo risolvo?


appunto, un hunting stand non lo metterei a “disused:” perché non lo puoi 
sapere, potrebbe essere usato in qualsiasi momento, finché è utilizzabile. Non 
c’è un servizio che ora è sospeso, come nel caso di una ferrovia o di un 
ristorante.

Ciao, Martin 



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

Re: [Talk-de] Kartendruck hochauflösend

[Martin Koppenhoefer]

sent from a phone

> On 6. Jan 2018, at 12:32, Hartmut Holzgraefe  
> wrote:
> 
> einfach mit dem OpenSeaMap füttern
> kann, man müsste entweder schauen inwieweit man den OpenSeaMap Renderer
> dazu bewegen kann gößerflächige Bereiche zu rendern als 256x256 Pixel
> große Kacheln, oder man geht den klassischen Weg die einzelnen Kacheln
> des gewünschten Bereiches im passenden Zommlevel zu sammeln und dann
> wieder zu einem großen Bild zusammenzufügen.



tiles stitchen ist zwar einfach (z.B. mit bigmap.cgi), aber es liefert nicht 
150dpi, da würden die Schrift und Icons viel zu klein im Ausdruck. Man müsste 
das direkt im Renderer anpassen, und die Icons müssten in entsprechender 
Auflösung oder als Vektoren vorliegen.


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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[marc marc]

L'idée est très intéressante.

Pour les dates, j'en rêve depuis longtemps d'avoir un moyen de connaître 
la source de photos aériennes la plus récente.
Mais est-elle disponible ? pour une imagerie qui a une faible couverture 
(par exemple celle d'un département) on peux imaginer qu'elle est proche 
pour toute la zone.
Mais à l'inverse, j'imagine que celle de Bing n'a pas de date uniforme, 
la maj étant peut-être faite en continu ou par zone.
Du coup cette donnée est-elle dispo ? cad pour une zone donnée, est-il 
possible de connaître la date de l'imagerie ?
je rêve d'un imagery_used:date bien pratique en cas de conflit entre un 
vieux survey et une imagerie sat.

Idem pour la qualité.
je constate régulièrement qu'une même source peut-être de qualité à un 
endroit et médiocre ailleurs, probablement venant de 2 prises de vue 
différentes faite avec du matériel différent.
Il me semble donc difficile d'attribuer une note globale par source.
Par contre, sauf délire de ma part, en éditant les alpes,
j'ai eu un jour un message dans josm me disant que tel couche était 
déclaré la meilleur dans cette zone.
j'ignore si c'est une fonction native de josm ou si cela provient du 
plugin utilisé par mémoriser les décalages d'imageries.
Je n'ai jamais réussi à le reproduire.

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

Re: [Talk-it] appostamenti di caccia non attivi

[Cascafico Giovanni]

Puoi farti la tua mappa che non sia Mapnik con diversi strumenti (qgis,
maperitive ecc) oppure esortare qualche produttore a renderizzare anche dei
disused tematici.

Adattare un database come OSM alle esigenze di Mapnik mi pare sbagliato.

Il metodo del namespace mi sembra funzionale ad un database. Se si rivelerà
tale, i renderizzatori seguiranno.

Il 06/gen/2018 00:55, "demon.box"  ha scritto:

> mi capita ormai sempre più spesso di trovare appostamenti di caccia non
> abbandonati ma palesemente non attivi.
>
> ora il wiki per amenity=hunting_stand
>
> https://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dhunting_stand
>
> ammette questo tag soltanto per un nodo.
>
> vista la fresca discussione sul prefisso disused: sarebbe opportuno
> marcarli
> come
>
> disused:amenity=hunting_stand
>
> ma così facendo sparisce tutto mentre di fatto il capanno esiste ancora
> soltanto che non si spara più, come lo risolvo?
>
> definire il capanno di caccia un building (sono perfettamente d'accordo con
> il wiki) mi sembra in effetti eccessivo...
>
> l'unica soluzione che mi viene ancora in mente è (e forse questa è proprio
> un'eccezione alla regola):
>
> amenity=hunting_stand
> disused=yes
>
> cosa ne pensate?
> oppure pensate sia giusto che dalle mappe sparisca tutto?
>
> per chi mastica di sentieri escursionistici vorrei ricordare quante volte
> nelle descrizioni si citano come punto di riferimento capanni di caccia non
> attivi oppure addirittura abbandonati... a mio parere è giusto che qualcosa
> venga comunuque renderizzato.
> grazie
> --enrico
>
>
>
>
>
> --
> 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: [Talk-it] standardizzazione stradario comunale

[Marcello]

Il 05/01/2018 18:47, totera ha scritto:
> Andrea Musuruane wrote
>> Ho modificato le seguenti pagine della wiki:
>> https://wiki.openstreetmap.org/wiki/IT:Key:name
>> https://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging#name
>> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
>>
>> Le prime due ora fanno riferimento all'ultima, in modo da avere un unico
>> posto dove sono inserite le regole per i nome delle strade.
>>
>> Ho cercato di inserire - in modo sintetico - le informazioni principali
>> riportate dall'ISTAT, evidenziando le eccezioni di OpenStreetMap (nomi NON
>> tutti in maiuscolo, uso di lettere accentante, prima lettera maiuscola,
>> ecc).
> Rispetto alle convenzioni che usavamo la variazione più significativa
> riguarda i nomi composti da giorno e mese.
> Siamo d'accordo ad accogliere questo punto delle direttive Istat, passando
> per il giorno dalle cifre al numero scritto per esteso?
> Se sì, è il caso di implementare una modifica automatica o procediamo
> manualmente?
>
Sull'argomento c'era stata una discussione anche ad aprile,
http://gis.19327.n8.nabble.com/nomi-con-date-tp5894982.html, alla fine
mi sembra che il consenso a seguire la direttiva Istat per le date mi
sembra abbastanza unanime. Sulla decisione maiuscole o minuscole invece
l'Istat non è di aiuto, dato che usa solo il maiuscolo, la pagina wiki
dice che si seguono le regole della lingua italiana, poi però negli
esempi mette i titoli onorifici in maiuscolo. Per facilitare la vita si
era proposto o tutte le iniziali in maiuscolo tranne le preposizioni
(di, del, della, ecc), oppure tutte minuscole, tranne chiaramente i nomi
propri e i termini Via, Piazza, ecc., senza però arrivare ad una scelta.

Personalmente preferisco la prima soluzione, ossia tutte le iniziali in
maiuscolo, ad esempio in quella discussione si era portato l'esempio del
25 aprile, che non è un qualsiasi 25 aprile ma fa riferimento al
Venticinque Aprile anniversario della liberazione, quindi andrebbe
scritto con le iniziali maiuscole. Se ad esempio trovo via dell'ulivo
non so se è riferito genericamente all'insieme degli alberi di ulivo
oppure in quella via esiste un ulivo particolare ai piedi del quale ha
pregato San Francesco. Dato che le regole della lingua italiana sono
molte e in vari casi anche complicate (vedi quando nel cognome c'è anche
la preposizione, in minuscolo per personaggi esistiti prima del XIX
secolo e in maiuscolo dopo) penso che dare un'indicazione semplice da
seguire sia fondamentale, ci saranno dei casi non corretti secondo la
lingua italiana, ma molto probabilmente ce ne sarebbero comunque e non
sarebbe nemmeno facile stabilire se rispettano le nostre regole di
inserimento.

Ciao
Marcello

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

Re: [Talk-it] R: Utente che cancella landuse e crea fiumi

[Volker Schmidt]

Ho parlato al telefono con l'utente e mi ha promesso che si metterà in
contatto con i mappatori della zona, in primo luogo risponderà fra poco ai
commenti. Spero che questo porti a un dialogo positivo con la comunità
locale.

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

[Talk-it] R: Utente che cancella landuse e crea fiumi

[Giuseppe Cassano]

grazie assai. commenterò non appena posso. ciao e grazie di nuovo

Giuseppe Cassano

- Messaggio originale -
Da: "Francesco Pelullo" 
Inviato: ‎06/‎01/‎2018 12:43
A: "openstreetmap list - italiano" 
Oggetto: Re: [Talk-it] Utente che cancella landuse e crea fiumi





Il 06 gen 2018 09:44, "Giuseppe Cassano"  ha 
scritto:



Tale cancellazione, anche se di poco conto, è francamente incomprensibile 
perché senza finalità alcuna.
Approfitto per chiedere a chi è più esperto di me la soluzione a questo 
problemino.
In presenza di queste modifiche come devo  comportarmi? Ritracciare i poligoni 
o cosa?
(Anche perché il lavoro per rirpistinare la situazione precedente può essere 
gravoso, come nel caso del lago comparso all'interno della Foresta di 
Mercadante segnalato nel link di Federico)



Ciao Beppe
La situazione è "sotto controllo", nel senso che tra qualche giorno chiederò al 
DWG di annullare tutti gli edit di questo utente.


Suggerisco di commentare sempre i changeset problematici, spiegando quali siano 
le problematiche, perché il DWG prima di accogliere una richiesta di revert va 
a verificare proprio qual è stata la reazione degli altri mappers all'edit. Se 
nessuno ha commentato, può significare che va tutto bene (o che nessuno si è 
preoccupato).






Grazie per avermi ospitato e godiamoci in serenità questo sabato e domenica


Ciao e W la foresta di Mercadante


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

[Talk-se] Ang. källor för korrigering av mindre sjöar/skogstjärnar

[Jimmy Utterström]

Hej!
Jag sitter och ser över mappningar som gjorts i södra lappland och håller bland 
annat på att korrigera lite större skogsytor som ser ut att ha lagts till utan 
att skapa multipolygoner så att de inomliggande sjöarna renderas korrekt. Jag 
har dock upptäckt en inkorrekt mappning där en mindre skogstjärn har givits 
samma namn som en större intilliggande. Jag funderar dock lite kring vilka 
källor som är acceptabla att ange som "source" när jag senare checkar in min 
korrigering. Det är nämligen så att den användare som lagt till den (gunnar1m) 
har angivit "Yahoo" som tidigare källa. Jag skulle därför vilja ange en ny 
källa så att den person som utförde den ursprungliga mappningen kan kontrollera 
varifrån jag fått uppgifterna från.

I detta fall skulle jag kunna använda "local knowledge" eftersom det är mina 
hemtrakter och jag har hyfsad koll på området,  men bäst vore ju om det gick 
använda exempelvis SMHIs sjöregister som källa. För där finns det korrekta 
uppgifter för tjärnen. Men som jag förstått det så är inte CC BY 4.0 (som SMHI 
använder?) helt kompatibel med OSM, stämmer det? Finns det några andra bättre 
datakällor för sjöar jag kan titta i?

Med vänliga hälsningar,
Jimmy Utterström
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Rafael Avila Coya]

A mí este logo es el que me parece más neutro e inclusivo. Y, como ya 
apuntó alguien, no somos los primeros que tenemos esta idea: Italia, 
Bielorrusia y Australia también usan ya este esquema.


Logos con banderas. Personalmente no me gustan. No me gustan las 
banderas. Pero eso es sólo mi opinión. Lo que no es opinión es que, 
entre gente que tenemos pasión por los mapas, es más probable que 
identifiquemos un país por su silueta y/o código ISO que por su bandera. 
¿Cuántos de aquí saben distinguir la bandera de Polonia de la de 
Austria? Y veis que no me voy muy lejos.


Un saludo cordial,

Rafael.

On 05/01/18 17:32, Miguel Sevilla-Callejo wrote:

Pues ahí va mi propuesta de logo 1.0:
https://imgur.com/4YWPlol

Esta propuesta se basa en el logotipo original de OSM combinando un mapa 
del territorio Español* y sin olvidar el código ISO del país, en este 
caso "ESP"


A ver que os parece, incluso en tamaños pequeños se ve relativamente bien.

* no se ven las plazas africanas, lo siento, pero si los dos grandes 
archipiélagos
* el mapa base es una proyección cónica de Albers para Europa, por eso 
sale "inclinado" el territorio


Seguro que le termino de dar alguna otra vuelta otro día...

Un saludo

Miguel

--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2018-01-03 20:28 GMT+01:00 dazer >:


Los cambios de Verdy_p de octubre no tienen absolutamente nada que
ver con la
plantilla de país. Ni afecta a qué aparece en la página de España. No
necesita contar con ningún consenso para modificar lo que viene a ser un
repositiorio de logos. Se apuntó que es una modificación reciente como
contraargumento a que la bandera es el logo por defecto.

Como apunta dcapillae, la discusión es sobre la página del país, tras
decidir quitar el wikiproyect. La cuestión es si queremos usar ese
logo que
está ahí disponible, u otros, para la página del país España.
Independientemente de la existencia de una comunidad de personas.

La confusión es precisamente la de mezclar comunidad con país.
Ciertamente
la razón por la que este hilo tiene tantas respuestas. Es una
cuestión de
armonizar con el resto del wiki, no de la identidad de la comunidad,
o de
las gentes.



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html


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





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



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

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

[Philippe Verdy]

Le 6 janvier 2018 à 10:58, Alarig Le Lay  a écrit :

> Et il n’y a jamais eu d’IPv6 tunnelisée en prod chez Orange. Ça a
> toujours été du natif.
>

Faux. Et depuis longtemps (pas loin de 15 ans depuis le début de
"l'expérimentation" dont il n'a jamais communiqué aucun résultat ni
réellement communiqué avec les utilisateurs sur le sujet), l'IPv6 est
tunnellisé sur plein de box Orange (ce n'est peut-être pas le cas de tous
les modèles plus récents) et ce tunnel est souvent tombé en panne et d'une
lenteur incroyable et pas conforme au niveau des MTU (support non intégré
de l'autodétection par certains datagrammes ICMP documentés dédiés à la
détection de la fragmentation IP en aval, via un flag non transmis dans les
options IP, ce qui ne permet pas de régler les paramètres de fenêtre TCP
après un démarrage de session), non-respect des paramètres QOS négociés
(Orange décidant seul de la priorité des trafics et passant outre alors
même qu'il n'y a même pas saturation du débit, le filtrage QOS se faisant
sur une liaison non concernée par la saturation), anomalies sérieuses au
niveau du pare-feu interne très basique de ses box, sans compter les bogues
de son serveur DHCP (sur lequel Orange interdit même de supprimer d'anciens
appareils qui s'y sont connectés et ne le sont plus depuis des semaines,
tel qu'un smartphone dont on a changé la version de firmware...), de son
proxy DNS intégré dont la mémoire sature beaucoup trop vite avec moins de
200 entrées dans ses tables ARP (ce qui rend très facile une attaque DOS
extérieure) et qui oublie trop vite des routages de sessions TCP en cours
puis s'avère incapable de faire la moindre nouvelle requête DNS.

Les box Orange ne nettoient pas non plus correctement leurs tables
internes, ce qui oblige à rebooter ses box très souvent, des boxes qui
peuvent mettre, même en fibre avec les box récentes, plus d'une demi-heure
après la synchro avant de se connecter et récupérer une config IP routable
(j'en ai encore fait l'expérience il y a deux jours avec un arrêt brutal et
l'affichage d'un message sur la box demandant de la rebooter et qui a
ensuite mis des heures à pouvoir se reconnecter). Et ce n'est pas du tout
un problème de perte de synchro ou de saturation du débit ou de perte de
trame, du trafic cesse totalement de passer sans raison et n'est ensuite
jamais acquitté (aussi bien positivement que négativement), la box bloque
un point c'est tout en attendant une réponse qui ne viendra jamais. En fait
Orange ne sait pas déboguer lui-même le plus gros de ses firmwares (il
garde le vieux code et le code de base fourni par son fabricant et ne
maintient aucun support avec lui, il ne change que la couche superficielle
et masque aux utilisateurs des tas de paramètres standards pourtant
disponibles dans le firmware original ; Orange fait là tout le contraire
d'OVH qui ouvre tous les paramètres possibles et qui peut régler plus
rapidement et plus finement les paramètres, car OVH n'a développé aucune
surcouche propriétaire pour masquer ce qui est standardisé même si certains
paramètres sont rarement utilisés ou nécessaires).

Orange a également omis de former ses personnels ou ouvrir à son support
externalisé la possibilité de détecter réellement les anomalies de
protocoles ou d'accéder aux journaux d'analyse. Le noyau Linux intégré dans
les box est aussi très vieux et contient des tas de bogues sérieux non
corrigés mais sur lesquels les patches sont connus et disponibles depuis
longtemps. C'est la politique de "sécurité par l'obscurité" pourtant
totalement inefficace aujourd'hui. Pour ces raisons je n'utilise pas les
box Orange directement connecté sur mon réseau local, j'ai mis un routeur
Ethernet-Ethernet ente les deux (avec un firmware opensource et mis à jour
régulièrement et protège effectivement contre la passoire qu'est le
prétendu "pare-feu" interne des box Orange) et seule la box TV d'Orange est
connectée directement à la box fibre et c'est mon routeur qui s'occupe du
Wifi (je n'utilise pas moi-même le Wifi de la box fibre, qui ne sert que
pour les invités temporaires, d'autant plus qu'elle ne les oublie jamais,
sauf avec un "reset usine" qui annule tout paramétrage antérieur, sachant
qu'Orange lui-même fait régulièrement des "reset usine" quand bon lui
semble et sans prévenir et sans qu'on le lui ait demandé).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[François Lacombe]

Ok très bien

Editor-layer-index sur GitHub peut faire l'affaire, je vais voir si je peux
aider JOSM à l'intégrer (si le projet le souhaite).

En revanche on ne traite ici que l'approche "fichier de configuration", qui
plus est spécifique à quelques éditeurs référencés.
Wikidata permettrait également de médiation pour découvrir l’existence de
ces sources.
"Quelles vues aériennes libres (ou autre wms) couvrent un point lat/lng ?
=> Une petite requête spatiale qui confonte aux bbox et j'ai ma réponse"
GitHub ne permet pas ce genre de choses, data.gouv non plus, autre
possibilité ?

Si les couches sont référencées à un autre endroit - comme wikidata -
editor-layer-index pourrait s'y connecter et générer tout de même les
fichiers de config nécessaires


François

2018-01-06 12:07 GMT+01:00 althio :

> 2018-01-06 11:37 GMT+01:00 François Lacombe :
> > Bonjour Althio,
> >
> > Je ne connaissais pas ce projet.
> > Qu'en est-il de son adoption dans les différents éditeurs ?
>
> Il est la référence pour iD, Potlatch 2 et Vespucci. C'est à
> configurer pour JOSM qui maintient une liste à part.
>
> cf. https://github.com/osmlab/editor-layer-index/blob/gh-pages/README.md
> > If you are using iD, Potlatch 2 or Vespucci, you are already using this
> index!
> > For JOSM you can add http://osmlab.github.io/
> editor-layer-index/imagery.xml to the preference key imagery.layers.sites
> in advanced preferences. You probably want to remove the
> https://josm.openstreetmap.de/maps entry or you'll get the same layers
> listed twice.
>
> ___
> 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-it] Utente che cancella landuse e crea fiumi

[Francesco Pelullo]

Il 06 gen 2018 09:44, "Giuseppe Cassano"  ha
scritto:


Tale cancellazione, anche se di poco conto, è francamente incomprensibile
perché senza finalità alcuna.
Approfitto per chiedere a chi è più esperto di me la soluzione a questo
problemino.
In presenza di queste modifiche come devo  comportarmi? Ritracciare i
poligoni o cosa?
(Anche perché il lavoro per rirpistinare la situazione precedente può
essere gravoso, come nel caso del lago comparso all'interno della Foresta
di Mercadante segnalato nel link di Federico)


Ciao Beppe
La situazione è "sotto controllo", nel senso che tra qualche giorno
chiederò al DWG di annullare tutti gli edit di questo utente.

Suggerisco di commentare sempre i changeset problematici, spiegando quali
siano le problematiche, perché il DWG prima di accogliere una richiesta di
revert va a verificare proprio qual è stata la reazione degli altri mappers
all'edit. Se nessuno ha commentato, può significare che va tutto bene (o
che nessuno si è preoccupato).



Grazie per avermi ospitato e godiamoci in serenità questo sabato e domenica


Ciao e W la foresta di Mercadante

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

Re: [OSM-talk-fr] adresses en France et StreetComplete [dérivé de Re: schéma des addr]

[althio]

althio :
>> Il me semble que l'auteur de StreetComplete (application Android de
>> collecte et contribution) aurait besoin d'information sur les
>> pratiques "adresses" en France... de manière à décider si son
>> application devrait ou ne devrait pas proposer des modifications
>> concernant les adresses en France.

Quand je parle de *pratiques "adresses" en France*, je veux faire
référence aux *pratiques _de cartographie sur OSM_ des adresses en
France*.

Pour bien comprendre le contexte et les attentes dans StreetComplete,
il faut vraiment aller sur le ticket
https://github.com/westnordost/StreetComplete/issues/714#issuecomment-353980856

Philippe Verdy :
> Il y a déjà de bons sites pour expliquer les règles compliquées des adresses
> et surtout pour liste des fausses règles contredites par la réalité.
>
> Cela a été fait en anglais d'abord car on a presque tous les cas compliqués
> au Royaume-Uni et toutes les exceptions. Un de ces auteurs est a été
> [...]

Ce n'est pas le fond de ma question, à la limite un lien vers un de
ces sites pour référence aurait pu être intéressant.
Le sujet de ce fil est plutôt : Est-ce que StreetComplete doit adapter
son comportement (=désactiver une quête spécifique) par rapport aux
pratiques de cartographie en France, pour éviter des doublons ou une
baisse de qualité ?

-- althio

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

Re: [Talk-de] Kartendruck hochauflösend

[Hartmut Holzgraefe]

On 06.01.2018 09:01, Markus wrote:

Vielleicht hilft das: http://printmaps-osm.de:8080/

Ja, das ist ein gutes Tool, kann aber nicht die Layer von OpenSeaMap.

Was ich brauche ist ein Rendering-Spezialist - so wie die Geofabrik.
(aber Frederik kann nicht)


Das "Problem" bei OpenSeaMap ist dass diese einen komplett
selbstgeschriebenen eigenen Renderer benutzt, nicht eine der
Standardlösungen wie Mapnik.

Das bedeutet leider auch dass man keinen der bestehenden Druckdienste
(printmaps-osm, maposmatic, ...) einfach mit dem OpenSeaMap füttern
kann, man müsste entweder schauen inwieweit man den OpenSeaMap Renderer
dazu bewegen kann gößerflächige Bereiche zu rendern als 256x256 Pixel
große Kacheln, oder man geht den klassischen Weg die einzelnen Kacheln
des gewünschten Bereiches im passenden Zommlevel zu sammeln und dann
wieder zu einem großen Bild zusammenzufügen.

Kurze Suche im OSM Wiki liefert ein paar Vorschläge zu dem Thema:


https://wiki.openstreetmap.org/wiki/Category:Tile_stitching

Erfahrungen mit den einzelnen Tools habe ich leider nicht ...

--
hartmut

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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[althio]

2018-01-06 11:37 GMT+01:00 François Lacombe :
> Bonjour Althio,
>
> Je ne connaissais pas ce projet.
> Qu'en est-il de son adoption dans les différents éditeurs ?

Il est la référence pour iD, Potlatch 2 et Vespucci. C'est à
configurer pour JOSM qui maintient une liste à part.

cf. https://github.com/osmlab/editor-layer-index/blob/gh-pages/README.md
> If you are using iD, Potlatch 2 or Vespucci, you are already using this index!
> For JOSM you can add http://osmlab.github.io/editor-layer-index/imagery.xml 
> to the preference key imagery.layers.sites in advanced preferences. You 
> probably want to remove the https://josm.openstreetmap.de/maps entry or 
> you'll get the same layers listed twice.

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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[PanierAvide]

Bonjour François,

Pas un expert non plus de Wikidata, mais à priori ça n'a pas encore été 
fait (aucun objet déclaré comme instance de WMS, l'item Q974922). Je ne 
sais pas si Wikidata est l'endroit le plus adapté pour ça, mais en tout 
cas ça a du sens comme proposition de faire un pot commun pour les 
sources d'imageries aériennes. Peut-être que ça peut-être géré comme le 
sont les presets du format h2geo (OSM Contributor, Jungle Bus), où les 
presets sont mis à disposition à travers des GitHub Pages (donc 
déploiement automatique + 0 coût d'infrastructure).


Cordialement,

Adrien.


Le 06/01/2018 à 10:16, François Lacombe a écrit :

Hello à tous,

Hier matin j'ai eu le plaisir de partager un TGV avec un ami lyonnais 
(Alain Ruet) qui contribue également sur OSM et on a eu quelques idées 
ensemble.


Notamment celle d'harmoniser les sources d'orthophoto pour les 
éditeurs, en inventoriant les serveurs WMS disponibles sur Wikidata.
Ainsi JOSM, iD et d'autres pourraient puiser là-dedans pour compléter 
leur liste sans que nous ayons à compléter un fichier pour chaque 
projet (avec un format différent).


Cela permettrait dans un deuxième temps de sourcer les changeset avec 
plus de précisions, par exemple l'année ou la finesse des photos 
(connus de wikidata via la ref qu'on indique dans le changeset).
Un utilisateur qui éditerait des objets avec une vue aérienne moins 
précise (Bing) que celle à partir de laquelle la dernière version a 
été établie (Orthophoto locale) pourrait être averti.


Je lance ça en l'air, ne connaissant pas vraiment la manière de 
déclarer de nouveaux types d'objets dans wikidata. Peut-etre que c'est 
même déjà fait ?

Qu'en pensez-vous ?

*François*


--
PanierAvide
Géomaticien & développeur

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

Re: [Talk-it] "cabina" metano

[scratera]

..prova a leggere qua 
https://wiki.openstreetmap.org/wiki/Tag:pipeline%3Dsubstation



--
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] Organisation des sources photos aeriennes sur Wikidata

[François Lacombe]

Bonjour Althio,

Je ne connaissais pas ce projet.
Qu'en est-il de son adoption dans les différents éditeurs ?
Le gitHub indique que Potlach l'embarque deja

Cette idée d'inventorier les serveurs WMS peut aussi dépasser OSM, et
wikidata est un vecteur de diffusion plutôt universel
On a pas de format de fichier à définir, d'éditeur à créer, d'infra etc...

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 6 janvier 2018 à 11:16, althio  a écrit :

> Bonjour François,
>
> Ma réponse est hors-sujet pour wikidata, mais pour une liste de fonds
> d'imagerie pour OSM il y a :
> https://github.com/osmlab/editor-layer-index
>
> Mais peut-être aviez-vous d'autres idées en tête.
>
> -- althio
>
>
> 2018-01-06 10:16 GMT+01:00 François Lacombe :
> > Hello à tous,
> >
> > Hier matin j'ai eu le plaisir de partager un TGV avec un ami lyonnais
> (Alain
> > Ruet) qui contribue également sur OSM et on a eu quelques idées ensemble.
> >
> > Notamment celle d'harmoniser les sources d'orthophoto pour les éditeurs,
> en
> > inventoriant les serveurs WMS disponibles sur Wikidata.
> > Ainsi JOSM, iD et d'autres pourraient puiser là-dedans pour compléter
> leur
> > liste sans que nous ayons à compléter un fichier pour chaque projet
> (avec un
> > format différent).
> >
> > Cela permettrait dans un deuxième temps de sourcer les changeset avec
> plus
> > de précisions, par exemple l'année ou la finesse des photos (connus de
> > wikidata via la ref qu'on indique dans le changeset).
> > Un utilisateur qui éditerait des objets avec une vue aérienne moins
> précise
> > (Bing) que celle à partir de laquelle la dernière version a été établie
> > (Orthophoto locale) pourrait être averti.
> >
> > Je lance ça en l'air, ne connaissant pas vraiment la manière de déclarer
> de
> > nouveaux types d'objets dans wikidata. Peut-etre que c'est même déjà
> fait ?
> > Qu'en pensez-vous ?
> >
> > François
> >
> > ___
> > 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] Problème IPv6 chez Orange causant des erreurs avec JOSM

[François Lacombe]

Bonjour Alarig

Le 6 janvier 2018 à 10:58, Alarig Le Lay  a écrit :

>
> C’est à cause du POP OTI à Londres qui boucle depuis quelques temps (au
> moins avec HE, il semblerai que ça soit également le cas avec Telia
> désormais).
>

Là ce serait à Marseille.
Vincent à toulouse qui passe par d'autres PNI avec OTI n'a pas ce problème.


> J’avais déjà remonté le problème avec petrus quand je m’en suis rendu
> compte, ça l’avait réparé temporairement. A priori ils n’ont pas appris
> de leurs erreurs.
>

Petrus étais coté 3215 mais là c'est OTI qui a des soucis hardware.
Visiblement c'est assez tricky



>
> Et il n’y a jamais eu d’IPv6 tunnelisée en prod chez Orange. Ça a
> toujours été du natif.
>
+1


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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[althio]

Bonjour François,

Ma réponse est hors-sujet pour wikidata, mais pour une liste de fonds
d'imagerie pour OSM il y a :
https://github.com/osmlab/editor-layer-index

Mais peut-être aviez-vous d'autres idées en tête.

-- althio


2018-01-06 10:16 GMT+01:00 François Lacombe :
> Hello à tous,
>
> Hier matin j'ai eu le plaisir de partager un TGV avec un ami lyonnais (Alain
> Ruet) qui contribue également sur OSM et on a eu quelques idées ensemble.
>
> Notamment celle d'harmoniser les sources d'orthophoto pour les éditeurs, en
> inventoriant les serveurs WMS disponibles sur Wikidata.
> Ainsi JOSM, iD et d'autres pourraient puiser là-dedans pour compléter leur
> liste sans que nous ayons à compléter un fichier pour chaque projet (avec un
> format différent).
>
> Cela permettrait dans un deuxième temps de sourcer les changeset avec plus
> de précisions, par exemple l'année ou la finesse des photos (connus de
> wikidata via la ref qu'on indique dans le changeset).
> Un utilisateur qui éditerait des objets avec une vue aérienne moins précise
> (Bing) que celle à partir de laquelle la dernière version a été établie
> (Orthophoto locale) pourrait être averti.
>
> Je lance ça en l'air, ne connaissant pas vraiment la manière de déclarer de
> nouveaux types d'objets dans wikidata. Peut-etre que c'est même déjà fait ?
> Qu'en pensez-vous ?
>
> François
>
> ___
> 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-it] "cabina" metano

[liste DOT girarsi AT posteo DOT eu]

Il 05/01/2018 20:36, demon.box ha scritto:

ciao, chiedo un parere prima di tutto tecnico.

cos'è esattamente questa "cabina" recintata?







e come la potrei taggare correttamente?
grazie

--enrico




Sicuramente è una stazione, forse per distribuire su altre contdotte, o 
forse di sicurezza, per esempio per chiudere il gas in caso di emergenza 
o per manutenzione sul gasdotto.


Se ci sono aziende o stabilimenti lì vicino che fanno uso abbondante di 
questo gas, può essere una derivazione per loro, o per la zona 
industriale in genere.


Però tecnicamente non so come si chiama.


--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Christian Quest]

Le 5 janvier 2018 à 21:52, Vincent Frison  a
écrit :

>
>
> Le 5 janvier 2018 à 20:21, Christian Quest  a
> écrit :
>
>> Pour moi c'est à éviter car ça fait dépendre ton rendu d'un service tiers
>> dont on ne contrôle pas la disponibilité.
>>
>> Si les tuiles externes d'ombrage ou de courbe de niveau ne sont pas
>> dispo... on fait quoi ?
>>
>> Un serveur de tuile doit fonctionner en autonomie. Sur un client, c'est
>> différent, tu peux mixer les tuiles si tu veux, vu que de toute façon tu
>> dépends en général de tuiles tierces.
>>
>> Je digresse un peu... le recours bien facile aux services et données
>> tiers c'est "pratique", mais casse gueule aussi.
>> Les très nombreux utilisateurs des fonds mapquest en ont fait les
>> frais... ceux qui utilisent les services de mapzen vont le découvrir à la
>> fin de mois (mapzen plie boutique).
>>
>> Comme les médocs, les API c'est bien, en abuser ça craint ;)
>>
>
> Surtout si elles sont périmées :)
>
> D'un point de vue purement serveur c'est vrai qu'il faut éviter de
> dépendre des services extérieures, et si OSM FR était capable de fournir ça
> tout seul ça serait vraiment génial !
>
> Mais d'un point de vue client ça serait quand même bien sympa d'avoir un
> layer supplémentaire pour le relief sur http://tiles.openstreetmap.fr :)
>
> En fait y a déjà l'option Hillshshade (@openskimap.org) sauf que là aucun
> des couches overlays fonctionnent...
>
>
Ok, on va avancer pas à pas alors... plutôt que de vouloir le truc parfait
dès le début ;)

Le truc parfait c'est l'ombrage et les courbes de niveau directement
intégrées dans les tuiles de fond de carte.

On peut démarrer avec 2 overlay:
- courbes de niveau
- ombrage
voire... une couche ombrage+courbes de niveau

Ensuite on intégrera dans les tuiles



> D'ailleurs c'est dommage que cette page ne soit pas facilement accessible
> depuis www.openstreetmap.fr, mais peut-être est ce un choix volontaire ?
>
>
tile.openstreetmap.fr était avant tout destiné à visualiser les tuiles FR,
et puis on a rajouter des trucs dessus... mais on n'a jamais repensé le
tout (et surtout eu la dispo pour ça, parce que des idées ça manque pas).



> Plus globalement je trouve qu'il manque une page (voir un menu) listant
> tous les super projets fait par OSM FR: osmose, les outils pour BANO ou le
> cadastre, le serveur de tuile pour ne citer que ceux que je connais...
>

Tu ne connais pas http://openstreetmap.fr/outils


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

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

[Alarig Le Lay]

On ven.  5 janv. 00:01:19 2018, François Lacombe wrote:
> Update: la connexion en http simple ne passe pas chez Orange, je confirme,
> même sans JOSM.
> 
> Ticket au niveau 3 envoyé
> https://twitter.com/InfosReseaux/status/949052812033478656

C’est à cause du POP OTI à Londres qui boucle depuis quelques temps (au
moins avec HE, il semblerai que ça soit également le cas avec Telia
désormais).
J’avais déjà remonté le problème avec petrus quand je m’en suis rendu
compte, ça l’avait réparé temporairement. A priori ils n’ont pas appris
de leurs erreurs.

Et il n’y a jamais eu d’IPv6 tunnelisée en prod chez Orange. Ça a
toujours été du natif.

-- 
alarig


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

[OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[François Lacombe]

Hello à tous,

Hier matin j'ai eu le plaisir de partager un TGV avec un ami lyonnais
(Alain Ruet) qui contribue également sur OSM et on a eu quelques idées
ensemble.

Notamment celle d'harmoniser les sources d'orthophoto pour les éditeurs, en
inventoriant les serveurs WMS disponibles sur Wikidata.
Ainsi JOSM, iD et d'autres pourraient puiser là-dedans pour compléter leur
liste sans que nous ayons à compléter un fichier pour chaque projet (avec
un format différent).

Cela permettrait dans un deuxième temps de sourcer les changeset avec plus
de précisions, par exemple l'année ou la finesse des photos (connus de
wikidata via la ref qu'on indique dans le changeset).
Un utilisateur qui éditerait des objets avec une vue aérienne moins précise
(Bing) que celle à partir de laquelle la dernière version a été établie
(Orthophoto locale) pourrait être averti.

Je lance ça en l'air, ne connaissant pas vraiment la manière de déclarer de
nouveaux types d'objets dans wikidata. Peut-etre que c'est même déjà fait ?
Qu'en pensez-vous ?

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

Re: [Talk-cz] Jednosměrka

[marek]

Spíš jde o to, jestli to mám správně označeno. V navigaci se to může změnit, 
pokud to nějak zvládne, ale hlavně aby to bylo dobře v mapě zadáno.
 
Marek Polák
 
__

Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic 
Datum: 05.01.2018 22:25
Předmět: Re: [Talk-cz] Jednosměrka


On Fri 2018-01-05 19:58:13, Jiří Komárek wrote:
> Nejsem si 100 % jistý, ale řekl bych, že "chyba" bude v navigaci: zřejmě
> neumí navigovat podle ročních období. Dotaz bych vedl na vývojáře navigace
> (a tady si nejsem jist, zda-li budou ochotní takovouto funkcionalitu přidat.
> Přeci jen, je to dost speciální případ)

Tohle je pro navigaci... celkem problem. Predstavte si ze vyjizdite na
konci brezna...

Spousta navigaci ma predpocitana reseni (aby umeli hledat "hned" a
netrvalo to 10 sekund)... a tam ta podminena jednosmerka nejspis
nepujde rozume udelat :-(.
Pavel



--
(english) http://www.livejournal.com/~pavelmachek 

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html 



--

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


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

[Talk-it] Utente che cancella landuse e crea fiumi

[Giuseppe Cassano]

ciao a chi legge
segnalo il fatto che il nostro amico Marco Petruzzelli CANCELLA poligoni da
me inseriti.
Nel dettaglio zone di un bosco che erano segnalate natural=grassland e
natural=scrub
come inizialmente riportato da Federico

http://nrenner.github.io/achavi/?changeset=55153696

Sono poligoni che avevo tracciato dopo osservazione diretta e non di foto
aeree.
Tale cancellazione, anche se di poco conto, è francamente incomprensibile
perché senza finalità alcuna.
Approfitto per chiedere a chi è più esperto di me la soluzione a questo
problemino.
In presenza di queste modifiche come devo  comportarmi? Ritracciare i
poligoni o cosa?
(Anche perché il lavoro per rirpistinare la situazione precedente può
essere gravoso, come nel caso del lago comparso all'interno della Foresta
di Mercadante segnalato nel link di Federico)
Grazie per avermi ospitato e godiamoci in serenità questo sabato e domenica
peppe cassano


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

[Jérôme Seigneuret]

Bonjour,

ça corrige mon problème également.

Merci

Le 5 janvier 2018 à 15:44, Vincent Bergeot  a écrit :

> Bonjour
>
>
> Le 04/01/2018 à 20:02, Vincent Privat a écrit :
>
>> Le workaround pour ce problème est de positionner à "false" la propriété
>> "prefer.ipv6" dans les options avancées de JOSM.
>>
>
> je confirme que cela fonctionne, merci beaucoup !!!
>
> Bonne journée
>
>
> Vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr