Re: [Talk-pt] Limites de Paróquias ( divisão geográfica de caracter religioso, principalmente católico)

[António Madeira]

Olá a todos.
Já tinha lido esta discussão aqui na mailing list, mas só ontem me
deparei com a situação no mapa.
Considero que se deva retirar esta área, não só porque a tag está mal
utilizada, como a área definida não está correta.
Deixei uma mensagem ao mapeador, à qual se seguiu uma do Topo Lusitania,
mas duvido que haja resposta, uma vez que a pessoa em causa só fez
quatro edições, três delas como teste.
O mais próximo de uma fonte oficial que encontrei foi este mapa da
diocese de Leiria-Fátima:
https://www.leiria-fatima.pt/diocese/mapas-do-territorio/

Sem mais dados que estes, julgo não ser possível mapear com exatidão
estas áreas...


Às 09:33 de 11-04-2019, f.dos.san...@free.fr escreveu:

Olá,

Não  vejo nenhuma objeção em mapear os limites de divisões religiosas, o que 
nao pode ser é, neste caseo, o uso do landuse=religious :
- https://www.openstreetmap.org/way/682732158

Já existam boundary=religious_administration por este efeito :
- https://taginfo.openstreetmap.org/tags/boundary=religious_administration

E com admin_level para distinguir as diversas hierarquias. Nada de bem definido 
ao nível internacional é apena uma discução que pode servir para as paroquias 
portuguesas :
https://wiki.openstreetmap.org/wiki/Talk:Key:boundary#Religious_authority_boundaries

Francisco


- Mail original -
From: "Topo Lusitania Lusitania via Talk-pt" 
To: "OSM Portugal" 
Cc: "Topo Lusitania Lusitania" 
Date: 11/04/2019 13:14:44
Subject: [Talk-pt] Limites de Paróquias ( divisão geográfica de caracter 
religioso, principalmente católico)




Olá


Hoje a mapear na zona de Leiria, encontrei da autoria de 
https://www.openstreetmap.org/user/Paulo%20Adriano os limites da Paróquia da 
Cruz da Areia
https://www.openstreetmap.org/edit?relation=6410611#map=15/39.7247/-8.7990


A pergunta que se põe é: podemos / devemos mapear os limites de divisões 
religiosas, sejam elas quais forem ?


Se em geral as paróquias católicas tendem a seguir as divisões administrativas 
ao nível de freguesia (ou será ao contrário? ;-) ), já as divisões superiores 
(Bispados) não seguem necessariamente as divisões distritais.


Coloca-se pois a pergunta -


Limites de Paróquias ou outro ente religioso - Sim ou não ?
Cumprimentos




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

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



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

[OSM-talk] OpenStreetMap Carto release v4.21.0

[Paul Norman via talk]

Dear all,

Today, v4.21.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include
- Removed unused world_boundaries-spherical.tgz file from scripts

- Switch to osmdata.openstreetmap.de for water & icesheet shapefiles

- Started using ST_PointOnSurface for some label placements

- Adjusted index for military areas

- Adjusted starting zooms for labeling of administrative areas.

- Revert rendering of healthcare key

- Stop place some place labels when the objects become too big or at 
high zooms.


- Only render capes as points and render them like other points.

- Only render ferry lines from ways, not relations

- Improved developer internal documentation



Thanks to all the contributors for this release including Nakaner, a new 
contributor.


For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.20.0...v4.21.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues


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

Re: [Talk-us] Someone from Boston, MA? (off topic - Boston hotel name / address trivia)

[Bill Ricker]

>> This is one of those skyscrapers with a vanity "street" address with
>> no such street.
>> (To confuse matters further, there is also a Copley Place Hotel whose
>> address is NOT Copley Place!)

> Apparently there are even two such hotels.
I should clarify slightly, not that it really matters.

"Copley Place" is an invented name for the new mall/office/hotel
development over the Turnpike air-rights, punning on / borrowing from an
old place name, "Copley Square", which is nearby and is associated with
class.  Two of the four sides of Copley Square are the Boston Public
Library formal entrance and Trinity Church.

The "Westin Copley Place" was part of the Copley Place mall/office
development, is connected by air-bridge, to same, but uses a real street
address (10 Huntington Ave). The "Marriott Copley Place" is actually in the
Copley Place towers (not sure if it's tower 1 or 2?) but uses 110
Huntington Ave as its business address, go figure.

Nearby, the former "Copley Plaza Hotel", now  "Fairmont Copley Plaza" is
actually on Copley Square, while the "Copley Square Hotel" confusingly is
not, it's up a side street, 47 Huntington  (with side entrance on Exeter St
connecting to Copley Square's plaza; 2nd oldest in Boston).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Someone from Boston, MA?

[Wolfgang Zenker]

Thanks, this was quite helpful.

* Bill Ricker  [190430 05:47]:
> On Mon, Apr 29, 2019 at 11:12 PM Kevin Kenny  wrote:
>> On Mon, Apr 29, 2019 at 11:01 PM Kevin Kenny  wrote:
>>> I'm not a Bostonian, but I've been to Copley Place.
>>> Copley Place is a named building: 
>>> https://www.openstreetmap.org/way/240501783

> This local Bostonian concurs.

> This is one of those skyscrapers with a vanity "street" address with
> no such street.
> (To confuse matters further, there is also a Copley Place Hotel whose
> address is NOT Copley Place!)

Apparently there are even two such hotels.

>> more information https://en.wikipedia.org/wiki/Copley_Place - the
>> building complex, in addition to the shopping mall, has office
>> buildings (tenants include the German and Canadian consulates, on the
>> fourth and fifth floors respectively of tower 3), hotels and a parking
>> garage, all connected.

> (and all-weather connections to adjacent malls and hotels too, and to
> two T (metro) lines and Amtrak rail.)
> (used to have a Cinema, but iirc it got consolidated out of existence?)

>> I'm not familiar enough with indoor mapping to be able to direct you
>> how to map a suite within the towers.

> A Consulate might prefer we not map the interior access?
> That level of detail is fine for retail but ... government entities
> can attract untoward attention.

I have no clue of indoor mapping myself, so I just placed two nodes in
what I estimated to be the rough location of tower 3 and tagged them as
the Canadian and German consulates.

Greetings,
Wolfgang
( lyx @ osm )

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

Re: [Talk-cl] Consulta: Cómo puedo visualizar una polilinea en openstreetmap?

[Pablo Silva]

Tengo un archivo CSV, donde tanto la latitud como longitud estan expresadas
en  grados

Por ejemplo:  33.2006806°, 070.6690639°

Atte., Pablo

On Wed, May 1, 2019 at 1:14 PM Julio Costa Zambelli <
julio.co...@openstreetmap.cl> wrote:

> Hola Pablo,
>
> ¿En que formato tienes ese conjunto de coordenadas?
>
> Saludos,
>
> Julio Costa Zambelli
> Fundación OpenStreetMap Chile
>
> julio.co...@openstreetmap.cl
>
> https://www.openstreetmap.cl/
> Cel: +56(9)89981083
>
>
> On Wed, 1 May 2019 at 11:09, Pablo Silva  wrote:
>
>> Hola
>>
>>  Tengo un conjunto de coordenadas que me gustaria visualizar en
>> openstreetmap, no he logrado descubrir como hacerlo, asi que
>> les pido apoyo por favor
>>
>>
>> Atte., Pablo
>> ___
>> Talk-cl mailing list
>> Talk-cl@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cl
>>
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [OSM-talk-fr] éditeur ID

[François Lacombe]

Bonsoir Jean-Yvon

Je partage ton constat, ils affichent bien leur position de ne pas prendre
en compte le wiki.
Ici encore dans cet échange où je leur suggérait de s'apuyer sur les Data
Items (récent ajout qui implément wikidata pour les tags sur le wiki)
https://github.com/openstreetmap/iD/issues/6206

"Sorry, but I'm really not interested in adding anything wiki as a critical
dependency on how iD works."

Certes le wiki n'a pas réponse à tout et manque parfois de fraicheur, mais
tout de même
Le problème c'est que iD rend aussi beaucoup de services et offre un
éditeur de qualité accessible et didactique. On ne peut pas lui enlever
Ce n'est pas une raison pour tout accepter

Issue ouverte pour location=kiosk
https://github.com/openstreetmap/iD/issues/6283

Bonne soirée

François

Le mer. 1 mai 2019 à 19:36,  a écrit :

> Récemment HebdOSM signalait que Frederik protestait contre la manière
> d'agir des deux développeurs d'ID.
>
> Développeurs d'un des deux principaux éditeurs d'OSM mais qui fonctionnent
> au doigt mouillé sans tenir compte des listes de discussion ou du Wiki.
>
> Dernièrement je suis tombé sur une intersection entre un ruisseau et une
> route correctement signalée par Osmose.
>
> J'édite la route. ID me propose de mettre un nœud simple_brunnel.
>
> Effectivement ça ne mérite pas plus.
>
> Sauf que maintenant Osmose râle car bridge ne doit pas être utilisé sur
> les points comme l'indique le Wiki
> .
>
> En cherchant j'ai trouvé une proposition datant de 2014 et a priori jamais
> passée par un vote :
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Simple_one_node_culvert_or_bridge
>
> Je pourrais entrer un ticket pour signaler le problème côté Osmose. Sauf
> que c'est ID qui ne respecte pas la communauté, pas Osmose.
>
> Dans ce cas précis, proposer un vote pourrait donner une légitimité pour
> un tag qui a été utilisé essentiellement en 2014-2015 (date de la
> proposition) et surtout en Autriche .
>
> 2008 1
> 2013 1
> 2014 153
> 2015 250
> 2016 33
> 2017 85
> 2018 25
> 2019 13
>
>
> Autre problèmes rencontrés avec ID, liste non exhaustive ça va de soi :
>
> - sur associatedStreet il propose address alors que le wiki dit de
> privilégier housenumber (et par défaut ne propose pas non plus de relation
> de type associatedStreet)
>
> - sur bus stop/platform il propose network allors qu'Osmose dit de ne pas
> utiliser network sur ces objets.
>
> - il propose location=kiosk alors que cette valeur est dépréciée
>
> - sur d'autres objets il va proposer aussi bien choix_numéro_1 que
> choix-numéro-1 et le débutant va choisir au petit bonheur.
>
> Comme vous le voyiez beaucoup des problèmes vient du fait que les deux
> développeurs payés ne tiennent pas compte de la communauté. Avec le risque
> que ce soit les visions des entreprise pour lesquelles travaillent les deux
> développeurs qui décident de l'avenir d'OSM.
>
> Un point à aborder lors du SotM monde à Heidelberg ?
>
> Jean-Yvon
> ___
> 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-br] Importar arquivos shapefile no OSM

[Gerald Weber]

Oi Giovanna

você precisa instalar um plugin chamado opendata no JOSM
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData

abraço

Gerald

On Wed, 1 May 2019 at 17:49, giotome  wrote:

> Olá, estou tentanto importar arquivos shapefile no OSM, tentei com o
> Editor Potlatch e com o JOSM mas não funcionou ainda! Alguém teria alguma
> dica ou passo a passo de como posso fazer essa importação?
>
> Muito obrigada,
>
> Giovanna ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Importar arquivos shapefile no OSM

[Alexandre Oliveira]

No JOSM basta abrir e selecionar o arquivo para abrir. Aparece algum
erro quando você tenta abrir o arquivo?

On 5/1/19, giotome  wrote:
> Olá, estou tentanto importar arquivos shapefile no OSM, tentei com o Editor
> Potlatch e com o JOSM mas não funcionou ainda! Alguém teria alguma dica ou
> passo a passo de como posso fazer essa importação?
>
> Muito obrigada,
>
> Giovanna


-- 
Atenciosamente,
Alexandre Oliveira.

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

[Talk-br] Importar arquivos shapefile no OSM

[giotome]

Olá, estou tentanto importar arquivos shapefile no OSM, tentei com o Editor Potlatch e com o JOSM mas não funcionou ainda! Alguém teria alguma dica ou passo a passo de como posso fazer essa importação?

Muito obrigada, 

Giovanna

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

Re: [Talk-ca] Importing buildings in Canada

[Begin Daniel]

Bonjour Tim,
Je ne sais pas si Pierre souhaite fusionner les approches, mais il démontre un 
intérêt à programmer. Pour ma part, je n’aime pas beaucoup programmer (python, 
scripts SQL, etc.), mais j’aime bien développer des processus (d’où 
l’utilisation de FME). 

Je vais rendre à terme la documentation du processus (de l’algorithme) et des 
exemples sur Github. Par la suite, ceux qui sont intéressés à développer 
l’application en open source seront les bienvenus et je serai heureux de 
répondre aux questions et d’en discuter :-)

Daniel 

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Tuesday, April 30, 2019 13:30
To: talk-ca@openstreetmap.org; Begin Daniel; Pierre Béland
Subject: Re: [Talk-ca] Importing buildings in Canada

Bonjour Daniel,

C'est une bonne nouvelle ! Pierre et moi avons déjà commencé à en parler 
dans des messages privés, et Pierre y a déjà beaucoup réfléchi - en 
partie d'un ancien projet, si je comprends bien. Il a également déjà 
publié ses approches précédentes sur github il y a quelques jours.

Voyons comment nous pouvons fusionner tes approches et celles de Pierre 
pour en tirer le meilleur parti pour le processus d'importation. Ce 
serait bien si nous pouvions trouver des méthodes d'orthogonalisation et 
  de simplification pour toutes les données OSM nouvellement importées 
(et peut-être même déjà existantes).

Tim

On 2019-04-30 12:07, Begin Daniel wrote:
Based on previous comments I improved the application and everything
seems right now. I’ll start publishing results/documentation in
following days J

We may then start developing an “open source” version of the application.

Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Saturday, April 27, 2019 16:41
*To:* Talk-CA OpenStreetMap
*Cc:* Alasia, Alessandro (STATCAN)
*Subject:* [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing
list to include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some
sort.

We have a couple of groups currently who I think would like to import
what is available in Alberta and Manitoba.  Are we asking them to hold
off until Pierre and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

Thanks John


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


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

Re: [OSM-talk-ie] Walking trails/cycling routes

[Mateusz Konieczny]

28 Apr 2019, 18:23 by webmas...@killyfole.org.uk:

> they are constantly being vandalised, mainly by inexperienced 
> users not understanding the relations and removing/amending ways without also 
> fixing the relations.
>
I would use other word like "broken", "vandalised" implies that it is malicious.

> I was wondering if there was a way to better educate new users in how 
> relations work
>
For start - how iD and JOSM react to user breaking relations in a typical
way? Is it safe to assume that cycling route that was continuous before edit
should almost certainly stay continuous after the edit?

If iD/JOSM validators are currently not spotting such mistakes - it may be 
useful to
suggest adding such detection.

The same with https://wiki.openstreetmap.org/wiki/Osmose 
 and other QA

Maybe iD/JOSM  editors can start displaying such routes in a default map 
rendering
to visually indicate what edit is doing.

If you want to do that but unsure how to start - I can write more how it can be 
done.

> Maybe this could be automated to ping the IRC channel 
> when a relation is broken?
>
In principle it is possible, but I would start from improving existing QA tools
rather than making a new one (I made mistake with creating one[1] that is 
unused because
we have no shortage of QA tools but shortage of mappers interested in fixing 
detected
issues)

[1] https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/

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

[OSM-talk-fr] éditeur ID

[osm . sanspourriel]

Récemment HebdOSM signalait que Frederik protestait contre la manière
d'agir des deux développeurs d'ID.

Développeurs d'un des deux principaux éditeurs d'OSM mais qui
fonctionnent au doigt mouillé sans tenir compte des listes de discussion
ou du Wiki.

Dernièrement je suis tombé sur une intersection entre un ruisseau et une
route correctement signalée par Osmose.

J'édite la route. ID me propose de mettre un nœud simple_brunnel.

Effectivement ça ne mérite pas plus.

Sauf que maintenant Osmose râle car bridge ne doit pas être utilisé sur
les points comme l'indique le Wiki
.

En cherchant j'ai trouvé une proposition datant de 2014 et a priori
jamais passée par un vote :

https://wiki.openstreetmap.org/wiki/Proposed_features/Simple_one_node_culvert_or_bridge

Je pourrais entrer un ticket pour signaler le problème côté Osmose. Sauf
que c'est ID qui ne respecte pas la communauté, pas Osmose.

Dans ce cas précis, proposer un vote pourrait donner une légitimité pour
un tag qui a été utilisé essentiellement en 2014-2015 (date de la
proposition) et surtout en Autriche .

20081
20131
2014153
2015250
201633
201785
201825
201913


Autre problèmes rencontrés avec ID, liste non exhaustive ça va de soi :

- sur associatedStreet il propose address alors que le wiki dit de
privilégier housenumber (et par défaut ne propose pas non plus de
relation de type associatedStreet)

- sur bus stop/platform il propose network allors qu'Osmose dit de ne
pas utiliser network sur ces objets.

- il propose location=kiosk alors que cette valeur est dépréciée

- sur d'autres objets il va proposer aussi bien choix_numéro_1 que
choix-numéro-1 et le débutant va choisir au petit bonheur.

Comme vous le voyiez beaucoup des problèmes vient du fait que les deux
développeurs payés ne tiennent pas compte de la communauté. Avec le
risque que ce soit les visions des entreprise pour lesquelles
travaillent les deux développeurs qui décident de l'avenir d'OSM.

Un point à aborder lors du SotM monde à Heidelberg ?

Jean-Yvon

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

Re: [Talk-cl] Consulta: Cómo puedo visualizar una polilinea en openstreetmap?

[Julio Costa Zambelli]

Hola Pablo,

¿En que formato tienes ese conjunto de coordenadas?

Saludos,

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl

https://www.openstreetmap.cl/
Cel: +56(9)89981083


On Wed, 1 May 2019 at 11:09, Pablo Silva  wrote:

> Hola
>
>  Tengo un conjunto de coordenadas que me gustaria visualizar en
> openstreetmap, no he logrado descubrir como hacerlo, asi que
> les pido apoyo por favor
>
>
> Atte., Pablo
> ___
> Talk-cl mailing list
> Talk-cl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-br] Able to host a tile.osm.org CDN node? (Inglês)

[Nelson A. de Oliveira]

On Wed, May 1, 2019 at 11:45 AM Peter Krauss  wrote:
> Oi gente, como ficou, alguém assumiu a responsabilidade?  Vai precisar de 
> vaquinha?

Já está funcionando no http://www.c3sl.ufpr.br/
Só ainda não foi divulgado.

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

[Talk-cl] Consulta: Cómo puedo visualizar una polilinea en openstreetmap?

[Pablo Silva]

Hola

 Tengo un conjunto de coordenadas que me gustaria visualizar en
openstreetmap, no he logrado descubrir como hacerlo, asi que
les pido apoyo por favor


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

Re: [OSM-talk-fr] Orthos opendata... mise à jour

[Christian Quest]

Le zoom 0... comment dire... il prend un petit peu de temps à se recalculer
(je vois apache bouffer du CPU) et ne sert pas à grande chose ;)

Tu peux ajouter orthohr_2018

Et une couche qui combine tout est dispo et à utiliser en priorité si on
n'a pas besoin de détailler:  tous_fr


Le mer. 1 mai 2019 à 15:03, Vincent Privat  a
écrit :

> C'est pas dispo sur le layer orthohr ? Je ne vois pas de nouvelle zone à
> ajouter sur https://josm.openstreetmap.de/mapsview?entry=Ortho%20HR
>
> Le mer. 1 mai 2019 à 14:46, Vincent Privat  a
> écrit :
>
>> Merci Christian, je vais mettre ça à jour côté JOSM.
>> Par contre j'ai des HTTP 504 pour les liens suivants depuis ce matin:
>> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2017/0/0/0
>> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2016/0/0/0
>> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2015/0/0/0
>> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2014/0/0/0
>> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2013/0/0/0
>>
>> cf.
>> https://josm.openstreetmap.de/jenkins/job/JOSM-Integration/lastCompletedBuild/jdk=JDK8/testReport/
>>
>> Vincent
>>
>> Le mer. 1 mai 2019 à 11:19, Cédric Frayssinet  a
>> écrit :
>>
>>>
>>> Bonjour Christian et grand merci pour ce boulot !
>>>
>>> Est-il possible d'exploiter l'ensemble de ces départements dans une
>>> couche personnalisée d'iD ?
>>> Je suis arrivée à avoir Lyon avec cette URL :
>>> http://wms.openstreetmap.fr/tms/1.0.0/lyon/{zoom}/{x}/{y} mais est-ce
>>> possible pour l'ensemble de la France ?
>>>
>>> Merci, Cédric
>>>
>>>
>>> Le 01/05/2019 à 11:08, Christian Quest a écrit :
>>>
>>> Quelques départements nouveaux sont disponibles ou ont été mis à jour
>>> ces derniers mois.
>>>
>>> Après plusieurs jours de téléchargement (le débit est soit de 60 Mbps
>>> soit limité à 500kbps sans bien comprendre la logique), des heures de
>>> décompression (7z et JPEG2000), de retuilage... c'est maintenant sur
>>> wms.openstreetmap.fr
>>>
>>> Nouveaux départements: 71 et 89 (2018)
>>> Nouvelles versions: 84 (2018)
>>>
>>> J'ai aussi corrigé des dalles qui avaient mal converties et causaient
>>> d'immenses "trous noirs".
>>>
>>> Résultat visible sur
>>> https://umap.openstreetmap.fr/fr/map/ortho-photos-opendata_278682#7/46.058/2.197
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>> ___
>>> Talk-fr mailing 
>>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>> --
>>> Dégooglisé !  - Sociétaire Enercoop
>>> , l'énergie
>>> militante
>>>
>>> Sur Mastodon : @bristow...@framapiaf.org
>>> 
>>>
>>> [image: Promouvoir et soutenir le logiciel libre] 
>>> ___
>>> 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
>


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

Re: [OSM-talk-fr] Îlot central

[Liozone]

Hello

Oui sauf que dans le cas proposé , il s'agit surtout de représenter un 
passage piéton (double en l’occurrence) et le wiki nous oriente alors 
plutôt sur une autre représentation sur la page crossing avec


crossing=island 
 ou plutôt 
crossing:island 
=yes :


   "Un passage avec un petit îlot central pour les piétons au milieu de
   la route.[...]"

https://wiki.openstreetmap.org/wiki/FR:Key:crossing

*/- crossing=island/***pose des problèmes et n'est pas recommandé mais 
par contre


/*- crossing:island=yes*/ (qui ne pose plus de problème) est recommandé 
mais _uniquement __sur la page anglaise_ ...


En regardant les 2 pages, je déduis que *traffic_calming=island* ne 
serait à utiliser justement que lorsqu'il n'y a pas de passage piéton 
(en ponctuel ou segment de highway) et /*crossing:island=yes* /(en 
ponctuel ou sur le passage) quand il y en a un...


Il faudrait en tous les cas accorder/clarifier les pages, non ?

Voili voilou : )**

Lionel/**/(liozone)/*
*/


Le 01/05/2019 à 11:40, Julien djakk a écrit :


Effectivement c’est bien comme dans le wiki j’avais pas tout bien lu 
J’utiliserai cette méthode aussi pour d’autres cas : îlot central 
avant et après une voie de tourne-à-gauche, muret de séparation de 
voie bus, îlot de feu rouge, potelets en plastique qui empêchent de 
tourner à gauche ...


Julien « djakk »



Le mer. 1 mai 2019 à 10:36, > a écrit :


Bonjour comme Axel tu proposes d'utiliser traffic_calming=island
comme indiqué sur le wiki.

Je vois mal comment on pourrait être contre ! On modélise plutôt
qu'on dessine. J'ai d'ailleurs suggéré à Alex de le proposer en
commentant des modifications faites par l'autre contributeur.

Jean-Yvon

Le 01/05/2019 à 10:21, Julien djakk - djakk.geograp...@gmail.com
 a écrit :

Bonjour !

La technique de séparation des chemins est très lourde, du coup
perso je ne l’utilise plus. Et je cherche une technique remplaçante.

J’ai un peu réfléchi, une « way » pourrait représenter toute la
chaussée, et les îlots centraux seraient des objets posés dessus.

Certains pourraient être des points (îlot de feu rouge parisien),
d’autres des lignes, comme l’exemple sur la photo de «
calming_island » -> dans le cas de la ligne, ça impliquerait de
le couper la « way » pour déclarer sur le tronçon de route
concerné « traffic_calming=island. »

Qu’en pensez-vous ?

@+
Julien « djakk »


Le mer. 1 mai 2019 à 08:50, Axel Listes mailto:axe...@broman.fr>> a écrit :

Bonjour les contributeurs,

Un contributeur plutôt expérimenté sur Nancy, représente les
minis
terre-pleins (îlots) centraux par une séparation de deux
chemins (un
chemin par sens de circulation), et cela depuis plusieurs années.

Exemple : https://osm.org/go/0DE4Cdi3D

Depuis, je suis tombé sur une balise qui me semble plus
approprié pour
ce type de représentation, l'usage de traffic_calming=island.
Notamment parce qu'elle décrit plus précisément de quoi il
s'agit sur le
terrain.

http://wiki.osm.org/wiki/Tag:traffic_calming=island

Avez-vous déjà rencontré ce type d'aménagement ? Quel est
selon vous la
meilleure façon de les représenter ?

-- 


L’intégralité de ce courrier électronique est exclusivement
réservé à
l'usage des personnes auxquelles il est destiné. L’auteur ne
donne pas
autorisation pour une quelconque autre exploitation de données,
notamment à des fins de statistiques et de surveillance.

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


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

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


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

Re: [OSM-talk-fr] Orthos opendata... mise à jour

[Vincent Privat]

C'est pas dispo sur le layer orthohr ? Je ne vois pas de nouvelle zone à
ajouter sur https://josm.openstreetmap.de/mapsview?entry=Ortho%20HR

Le mer. 1 mai 2019 à 14:46, Vincent Privat  a
écrit :

> Merci Christian, je vais mettre ça à jour côté JOSM.
> Par contre j'ai des HTTP 504 pour les liens suivants depuis ce matin:
> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2017/0/0/0
> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2016/0/0/0
> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2015/0/0/0
> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2014/0/0/0
> http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2013/0/0/0
>
> cf.
> https://josm.openstreetmap.de/jenkins/job/JOSM-Integration/lastCompletedBuild/jdk=JDK8/testReport/
>
> Vincent
>
> Le mer. 1 mai 2019 à 11:19, Cédric Frayssinet  a
> écrit :
>
>>
>> Bonjour Christian et grand merci pour ce boulot !
>>
>> Est-il possible d'exploiter l'ensemble de ces départements dans une
>> couche personnalisée d'iD ?
>> Je suis arrivée à avoir Lyon avec cette URL :
>> http://wms.openstreetmap.fr/tms/1.0.0/lyon/{zoom}/{x}/{y} mais est-ce
>> possible pour l'ensemble de la France ?
>>
>> Merci, Cédric
>>
>>
>> Le 01/05/2019 à 11:08, Christian Quest a écrit :
>>
>> Quelques départements nouveaux sont disponibles ou ont été mis à jour ces
>> derniers mois.
>>
>> Après plusieurs jours de téléchargement (le débit est soit de 60 Mbps
>> soit limité à 500kbps sans bien comprendre la logique), des heures de
>> décompression (7z et JPEG2000), de retuilage... c'est maintenant sur
>> wms.openstreetmap.fr
>>
>> Nouveaux départements: 71 et 89 (2018)
>> Nouvelles versions: 84 (2018)
>>
>> J'ai aussi corrigé des dalles qui avaient mal converties et causaient
>> d'immenses "trous noirs".
>>
>> Résultat visible sur
>> https://umap.openstreetmap.fr/fr/map/ortho-photos-opendata_278682#7/46.058/2.197
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> --
>> Dégooglisé !  - Sociétaire Enercoop
>> , l'énergie
>> militante
>>
>> Sur Mastodon : @bristow...@framapiaf.org
>> 
>>
>> [image: Promouvoir et soutenir le logiciel libre] 
>> ___
>> 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] Orthos opendata... mise à jour

[Vincent Privat]

Merci Christian, je vais mettre ça à jour côté JOSM.
Par contre j'ai des HTTP 504 pour les liens suivants depuis ce matin:
http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2017/0/0/0
http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2016/0/0/0
http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2015/0/0/0
http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2014/0/0/0
http://wms.openstreetmap.fr/tms/1.0.0/orthohr_2013/0/0/0

cf.
https://josm.openstreetmap.de/jenkins/job/JOSM-Integration/lastCompletedBuild/jdk=JDK8/testReport/

Vincent

Le mer. 1 mai 2019 à 11:19, Cédric Frayssinet  a
écrit :

>
> Bonjour Christian et grand merci pour ce boulot !
>
> Est-il possible d'exploiter l'ensemble de ces départements dans une couche
> personnalisée d'iD ?
> Je suis arrivée à avoir Lyon avec cette URL :
> http://wms.openstreetmap.fr/tms/1.0.0/lyon/{zoom}/{x}/{y} mais est-ce
> possible pour l'ensemble de la France ?
>
> Merci, Cédric
>
>
> Le 01/05/2019 à 11:08, Christian Quest a écrit :
>
> Quelques départements nouveaux sont disponibles ou ont été mis à jour ces
> derniers mois.
>
> Après plusieurs jours de téléchargement (le débit est soit de 60 Mbps soit
> limité à 500kbps sans bien comprendre la logique), des heures de
> décompression (7z et JPEG2000), de retuilage... c'est maintenant sur
> wms.openstreetmap.fr
>
> Nouveaux départements: 71 et 89 (2018)
> Nouvelles versions: 84 (2018)
>
> J'ai aussi corrigé des dalles qui avaient mal converties et causaient
> d'immenses "trous noirs".
>
> Résultat visible sur
> https://umap.openstreetmap.fr/fr/map/ortho-photos-opendata_278682#7/46.058/2.197
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> Dégooglisé !  - Sociétaire Enercoop
> , l'énergie
> militante
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> 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] motor_vehicle da imagery?

[Andrea Musuruane]

Ciao Daniele,
grazie per aver scritto ad Amazon Logistics.

Mi spiace però constatare che Amazon abbia fornito una risposta
precompilata. Se questo è il livello di interazione che vogliono avere con
la comunità OSM, direi che proprio non ci siamo :-(

Ciao,

Andrea


On Tue, Apr 30, 2019 at 10:29 AM Daniele Santini 
wrote:

> Il mar 30 apr 2019, 10:01  ha scritto:
>
>  Non ho capito però se qualcuno ha
> già scritto a osm-edit-escalati...@amazon.com
>
>
> L'ho fatto io. Questa è la risposta:
>
>> My team is working in Italy and our edits are made based on driver
>> feedback or from driver GPS traces. Due to legal constraints of
>> representing drivers information we were not adding this as a source in
>> changeset comments. We are working with our legal team to clear this
>> constraint and be as transparent as possible. Before making any changes to
>> OSM we also verify the drivers information with sources available in OSM
>> such as Satellite imagery and Street Level imagery for confirmation. Hope
>> this answers your question on adding motor vehicle access for Unmaintained
>> Track roads.
>
>
> --
> Daniele Santini
> http://www.dsantini.it
> ___
> 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-GB] RFC: Solar panel mapping in the UK

[Russ Garrett]

On Wed, 1 May 2019 at 11:36, Jez Nicholson  wrote:
> BTW...shouldn't the points on the map reduce when I filter?

They should but I'm still working on that feature.

-- 
Russ Garrett
r...@garrett.co.uk

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

Re: [Talk-GB] RFC: Solar panel mapping in the UK

[Jez Nicholson]

...using Simon Willison's datasette + your map plugin, I gather.

https://repd.ru.dev/repd/repd?solar_mounting_type__exact=Ground_status__exact=Operational_type__exact=Solar+Photovoltaics

BTW...shouldn't the points on the map reduce when I filter?

On Wed, May 1, 2019 at 11:07 AM Russ Garrett  wrote:

> I've made the REPD dataset browsable on a map here, which should make
> it easier to correlate with OSM: https://repd.ru.dev/repd/repd
>
> Russ
>
> On Thu, 11 Apr 2019 at 11:00, SK53  wrote:
> >
> > I'll quickly add my responses on the thread:
> >
> > REPD issues. All of Rob's points taken, but we mustn't forget that OSM
> data have always been acquired and refined iteratively. Of course data from
> REPD has to be taken with a pinch of salt, but at least for now it's very
> useful for hunting for missing installations. In practice I've found most
> REPD installations relatively easy to resolve (but see below for an
> exception). Russ does compute a power output for those sites which don't
> have the output explicitly tagged, so there is the potential to compare the
> REPD output and a computed value based on area.
> > ML & Solar Farms. Tyler Busby has been working to identify rooftop solar
> using machine learning. He has a MapRoulette challenge running for Austn
> Texas at the moment. I imagine it might be possible to reuse some of his
> techniques to identify individual rows of panels within solar farms, which
> could improve power estimation from OSM data.
> > Sections in Installations.  Exceptions, such as single installations
> with multiple sites certainly exist too. I recently mapped panels on the
> site of the former Asfordby super pit. There are two groups of panels which
> a Geograph photographer calls, on the basis of photos of ancillary
> electrical plant, Asfordby A and Asfordby B. There are also photos of
> Asfordby C. As usual more can be learned from on-the-ground visits, but as
> above this is for future refinement.
> > Rooftop angles. I had a futile attempt to try & calculate roof angles
> from Lidar data. The 1 m resolution doesn't seem to be adequate. Maximum
> roof height is more reliable (available for instance via the  dataset).
> Estimating the height of eaves can be done from Lidar, but it's fairly
> fuzzy. I think using rules of thumb for different periods of construction
> may be just as fruitful (perhaps 9 foot ceilings for pre-WWII, 8 foot for
> interwar housing, and 7 foot 6 thereafter, with 1-1.5 feet between floors).
> Counting courses of bricks would give a more precise measure and only needs
> to be done for basic ranges of housing. Most local archives are likely to
> have architects drawings for houses built as council housing which is
> perhaps a third of the total stock. However a basic estimation of eave
> level from 5-6 m will not be hugely out. See next bullet for a suitable tag.
> > Other tags. After much faffing about, and on Russ' advice, I have now
> moved to using location=roof instead of generator:place or
> generator:location. This doesn't work if the generator tags are placed on
> the building as is the case for some places in the West Midlands, but as
> these result in gross over-estimation of likely output I'd regard this as
> an interim stage of mapping. I'm still using generator:orientation, but
> this may also be more unwieldy than required, and obviously relates to
> solar installations only. Modules are tagged generator:solar:modules which
> at least unambiguously shows that it relates to the panels, so despite the
> unwieldiness something similar for angle would be clear. (As an aside I
> don't think we have any UK solar farms with panels mounted on heliostats,
> but they certainly exist in Spain, for instance at Almaraz).
> > Power tagging. One thing which has become clear is in mapping groups of
> panels within a solar farm and retagging the outline as power=plant isthat
> the use of generator: and plant: tags is unfortunate. Most of them would
> work just fine as they were originally with power.
> > Solar arrays vs solar panels. The current tagging largely seems to fail
> to distinguish between a large array of solar panels and single panels
> consisting of a few modules. I really don't think we want to end up having
> to map each group of panels individually so it would be nice to have a
> better way of distinguishing them other than location=roof and overall
> area. Perhaps less than half the area of an array of panels will be the
> actual footprint of panels. Also I'd be unsurprised if some don't map
> solar-powered rubbish bins, parking meters, road signs with power=generator
> too.
> >
> > Lastly big thanks to Jez, Dan, and especially Russ for his updates to
> OpenInfraMap which really help with the mapping.
> >
> > Jerry
> >
> > On Wed, 10 Apr 2019 at 23:01, Dan S  wrote:
> >>
> >> Hi all,
> >>
> >> Thanks for the comments on solar panel mapping. (Plenty of mapping
> >> happening already: thousands of UK solar panels added to the 

Re: [Talk-GB] RFC: Solar panel mapping in the UK

[Russ Garrett]

I've made the REPD dataset browsable on a map here, which should make
it easier to correlate with OSM: https://repd.ru.dev/repd/repd

Russ

On Thu, 11 Apr 2019 at 11:00, SK53  wrote:
>
> I'll quickly add my responses on the thread:
>
> REPD issues. All of Rob's points taken, but we mustn't forget that OSM data 
> have always been acquired and refined iteratively. Of course data from REPD 
> has to be taken with a pinch of salt, but at least for now it's very useful 
> for hunting for missing installations. In practice I've found most REPD 
> installations relatively easy to resolve (but see below for an exception). 
> Russ does compute a power output for those sites which don't have the output 
> explicitly tagged, so there is the potential to compare the REPD output and a 
> computed value based on area.
> ML & Solar Farms. Tyler Busby has been working to identify rooftop solar 
> using machine learning. He has a MapRoulette challenge running for Austn 
> Texas at the moment. I imagine it might be possible to reuse some of his 
> techniques to identify individual rows of panels within solar farms, which 
> could improve power estimation from OSM data.
> Sections in Installations.  Exceptions, such as single installations with 
> multiple sites certainly exist too. I recently mapped panels on the site of 
> the former Asfordby super pit. There are two groups of panels which a 
> Geograph photographer calls, on the basis of photos of ancillary electrical 
> plant, Asfordby A and Asfordby B. There are also photos of Asfordby C. As 
> usual more can be learned from on-the-ground visits, but as above this is for 
> future refinement.
> Rooftop angles. I had a futile attempt to try & calculate roof angles from 
> Lidar data. The 1 m resolution doesn't seem to be adequate. Maximum roof 
> height is more reliable (available for instance via the  dataset). Estimating 
> the height of eaves can be done from Lidar, but it's fairly fuzzy. I think 
> using rules of thumb for different periods of construction may be just as 
> fruitful (perhaps 9 foot ceilings for pre-WWII, 8 foot for interwar housing, 
> and 7 foot 6 thereafter, with 1-1.5 feet between floors). Counting courses of 
> bricks would give a more precise measure and only needs to be done for basic 
> ranges of housing. Most local archives are likely to have architects drawings 
> for houses built as council housing which is perhaps a third of the total 
> stock. However a basic estimation of eave level from 5-6 m will not be hugely 
> out. See next bullet for a suitable tag.
> Other tags. After much faffing about, and on Russ' advice, I have now moved 
> to using location=roof instead of generator:place or generator:location. This 
> doesn't work if the generator tags are placed on the building as is the case 
> for some places in the West Midlands, but as these result in gross 
> over-estimation of likely output I'd regard this as an interim stage of 
> mapping. I'm still using generator:orientation, but this may also be more 
> unwieldy than required, and obviously relates to solar installations only. 
> Modules are tagged generator:solar:modules which at least unambiguously shows 
> that it relates to the panels, so despite the unwieldiness something similar 
> for angle would be clear. (As an aside I don't think we have any UK solar 
> farms with panels mounted on heliostats, but they certainly exist in Spain, 
> for instance at Almaraz).
> Power tagging. One thing which has become clear is in mapping groups of 
> panels within a solar farm and retagging the outline as power=plant isthat 
> the use of generator: and plant: tags is unfortunate. Most of them would work 
> just fine as they were originally with power.
> Solar arrays vs solar panels. The current tagging largely seems to fail to 
> distinguish between a large array of solar panels and single panels 
> consisting of a few modules. I really don't think we want to end up having to 
> map each group of panels individually so it would be nice to have a better 
> way of distinguishing them other than location=roof and overall area. Perhaps 
> less than half the area of an array of panels will be the actual footprint of 
> panels. Also I'd be unsurprised if some don't map solar-powered rubbish bins, 
> parking meters, road signs with power=generator too.
>
> Lastly big thanks to Jez, Dan, and especially Russ for his updates to 
> OpenInfraMap which really help with the mapping.
>
> Jerry
>
> On Wed, 10 Apr 2019 at 23:01, Dan S  wrote:
>>
>> Hi all,
>>
>> Thanks for the comments on solar panel mapping. (Plenty of mapping
>> happening already: thousands of UK solar panels added to the database
>> in the past month.) A few small responses:
>>
>> SOLAR FARMS:
>>
>> I'll defer to Russ's tagging advice about solar farms: power=plant
>> polygon (or sometimes multipolygon) as the outline of a solar farm,
>> with power=generator areas contained within it for the blocks of
>> panels. Previously, I was 

Re: [OSM-talk-fr] Îlot central

[Julien djakk]

Effectivement c’est bien comme dans le wiki j’avais pas tout bien lu 
J’utiliserai cette méthode aussi pour d’autres cas : îlot central avant et
après une voie de tourne-à-gauche, muret de séparation de voie bus, îlot de
feu rouge, potelets en plastique qui empêchent de tourner à gauche ...

Julien « djakk »



Le mer. 1 mai 2019 à 10:36,  a écrit :

> Bonjour comme Axel tu proposes d'utiliser traffic_calming=island comme
> indiqué sur le wiki.
>
> Je vois mal comment on pourrait être contre ! On modélise plutôt qu'on
> dessine. J'ai d'ailleurs suggéré à Alex de le proposer en commentant des
> modifications faites par l'autre contributeur.
>
> Jean-Yvon
> Le 01/05/2019 à 10:21, Julien djakk - djakk.geograp...@gmail.com a écrit :
>
> Bonjour !
>
> La technique de séparation des chemins est très lourde, du coup perso je
> ne l’utilise plus. Et je cherche une technique remplaçante.
>
> J’ai un peu réfléchi, une « way » pourrait représenter toute la chaussée,
> et les îlots centraux seraient des objets posés dessus.
>
> Certains pourraient être des points (îlot de feu rouge parisien), d’autres
> des lignes, comme l’exemple sur la photo de « calming_island » -> dans le
> cas de la ligne, ça impliquerait de le couper la « way » pour déclarer sur
> le tronçon de route concerné « traffic_calming=island. »
>
> Qu’en pensez-vous ?
>
> @+
> Julien « djakk »
>
>
> Le mer. 1 mai 2019 à 08:50, Axel Listes  a écrit :
>
>> Bonjour les contributeurs,
>>
>> Un contributeur plutôt expérimenté sur Nancy, représente les minis
>> terre-pleins (îlots) centraux par une séparation de deux chemins (un
>> chemin par sens de circulation), et cela depuis plusieurs années.
>>
>> Exemple : https://osm.org/go/0DE4Cdi3D
>>
>> Depuis, je suis tombé sur une balise qui me semble plus approprié pour
>> ce type de représentation, l'usage de traffic_calming=island.
>> Notamment parce qu'elle décrit plus précisément de quoi il s'agit sur le
>> terrain.
>>
>> http://wiki.osm.org/wiki/Tag:traffic_calming=island
>>
>> Avez-vous déjà rencontré ce type d'aménagement ? Quel est selon vous la
>> meilleure façon de les représenter ?
>>
>> --
>>
>> L’intégralité de ce courrier électronique est exclusivement réservé à
>> l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas
>> autorisation pour une quelconque autre exploitation de données,
>> notamment à des fins de statistiques et de surveillance.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Orthos opendata... mise à jour

[Cédric Frayssinet]

Bonjour Christian et grand merci pour ce boulot !

Est-il possible d'exploiter l'ensemble de ces départements dans une
couche personnalisée d'iD ?
Je suis arrivée à avoir Lyon avec cette URL :
http://wms.openstreetmap.fr/tms/1.0.0/lyon/{zoom}/{x}/{y} mais est-ce
possible pour l'ensemble de la France ?

Merci, Cédric


Le 01/05/2019 à 11:08, Christian Quest a écrit :
> Quelques départements nouveaux sont disponibles ou ont été mis à jour
> ces derniers mois.
>
> Après plusieurs jours de téléchargement (le débit est soit de 60 Mbps
> soit limité à 500kbps sans bien comprendre la logique), des heures de
> décompression (7z et JPEG2000), de retuilage... c'est maintenant sur
> wms.openstreetmap.fr 
>
> Nouveaux départements: 71 et 89 (2018)
> Nouvelles versions: 84 (2018)
>
> J'ai aussi corrigé des dalles qui avaient mal converties et causaient
> d'immenses "trous noirs".
>
> Résultat visible sur
> https://umap.openstreetmap.fr/fr/map/ortho-photos-opendata_278682#7/46.058/2.197
>
> -- 
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

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

Promouvoir et soutenir le logiciel libre 

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

[OSM-talk-fr] Orthos opendata... mise à jour

[Christian Quest]

Quelques départements nouveaux sont disponibles ou ont été mis à jour ces
derniers mois.

Après plusieurs jours de téléchargement (le débit est soit de 60 Mbps soit
limité à 500kbps sans bien comprendre la logique), des heures de
décompression (7z et JPEG2000), de retuilage... c'est maintenant sur
wms.openstreetmap.fr

Nouveaux départements: 71 et 89 (2018)
Nouvelles versions: 84 (2018)

J'ai aussi corrigé des dalles qui avaient mal converties et causaient
d'immenses "trous noirs".

Résultat visible sur
https://umap.openstreetmap.fr/fr/map/ortho-photos-opendata_278682#7/46.058/2.197

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

Re: [Talk-de] Idee: OSM-Wikicamp/OSM-Wikiwochenende - Sommercamp in Essen

[Christopher Lorenz]

Hallo,

für das angesprochene Sommercamp im Essener Linuxhotel gibt es eine
Wiki-Seite [1]. Hier findet ihr erste Infos und könnt ausführlich eure
Themenvorschläge oder Ideen, nicht nur rund ums Wiki, eintragen. Die
Anmeldung für die Übernachtungsgäste erfolgt zentral im Wiki des FOSSGIS
e.V. [2]. Es sind aktuell noch 11 Betten frei. Für eine bessere Planung
ist es hilfreich, sich auch als Tagesgast anzumelden, wenn ihr nicht im
Linuxhotel übernachten wollt.

freundliche Grüße,

Christopher

[1] https://wiki.openstreetmap.org/wiki/SommerCamp_2019
[2] https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2019_Nummer_12

On 20.04.19 14:48, Michael Reichert wrote:
> Hallo,
>
> ich bin jetzt schon ein paar Jahre bei OSM dabei und fast genauso lange
> gibt es Gemecker über die Mängel und Schwachstellen des OSM-Wikis.
>
> Auf dem OSM-Samstag 2018 in Bonn hatte ich eine Diskussion zu dem Thema
> angestoßen. Auf der FOSSGIS-Konferenz 2019 gab es einen Vortrag von
> raubraupe und auf dem OSM-Samstag einen Vortrag von raubraupe und erneut
> eine Diskussion zu dem Thema. Diskutieren allein macht das Wiki aber
> nicht besser. Um den wortreichen Diskussionen mal ein paar Taten folgen
> zu lassen, schlage ich vor, dass sich Freiwillige, die das Wiki
> *inhaltlich* als Autoren verbessern wollen, ein Wochenende
> zusammensetzen und gemeinsam durch das Wiki stöbern und Seiten
> bearbeiten, archivieren oder zum Löschen vorschlagen.
>
> Der FOSSGIS e.V. veranstaltet zweimal pro Jahr ein "Hacking Event" im
> Linuxhotel in Essen als Arbeitstreffen und Hackweekend für die OSM- und
> GIS-Community. Genau diese Location kann der FOSSGIS e.V. für ein
> OSM-Wikicamp ein Wochenende buchen. Teilnehmer müssten dann nur ihre
> Anreise zahlen. Übernachtung und Verpflegung würde der FOSSGIS e.V. tragen.
>
> Meiner Meinung nach gibt es im Wiki genug zu tun. Hier mal eine paar
> Baustellen, die mir auf die Schnelle einfallen:
>
> (1) In unserem Wiki gibt es eine ganze Reihe an Seiten, die eine
> Einführung in ein Thema bieten. Es gibt auch weiterhin sicherlich Bedarf
> für eine ganze Reihe davon; sie müssen aber auch einigermaßen aktuell
> sein. Es braucht keine Dokumentation für (neue) Mapper (mehr), die
> direkt von der deutschen Startseite aus verlinkt ist und einem
> Interessierten sagt, dass er ohne GPS-Gerät bei OSM nicht viel tun kann
> [1]. Wer sich von der Startseite aus durchhangelt, sollte auf hilfreiche
> Inhalte stoßen und nicht auf auf ein verstaubtes Bücherregal.
>
> (2) In unserem Wiki findet sich viel Dokumentation über das Setup oder
> die Nutzung von Software. Jedoch gibt es genügend Seiten, die man
> entweder aktualisieren, archivieren oder löschen sollte. Beispiele:
>
> https://wiki.openstreetmap.org/wiki/DE:Erstelle_und_benutze_deine_eigene_Slippy-Map
> https://wiki.openstreetmap.org/wiki/Creating_your_own_tiles
>
> (3) Die Sprachversionen einzelner Seiten entwickeln sich im Laufe der
> Zeit auseinander, weil kein Autor alle Sprachen beherrscht. Das
> Synchronisieren von Seiten ist ein weiteres mögliches Betätigungsfeld
> auf dieser Veranstaltung. Ziel ist nicht, die Seiten vollständig
> deckungsgleich zu bekommen. Bei bestimmten inhaltlichen Widersprüchen
> muss zuerst auf den einschlägigen Mailinglisten ein Konsens gefunden
> werden. Kleinere Differenzen lassen sich jedoch ad-hoc entscheiden.
>
> Bestimmte Änderungen lassen sich im Wiki nicht ad-hoc umsetzen. Hier
> muss der Diskussionsbedarf erkannt und eine Diskussionen auf einer
> geeigneten Mailingliste oder im Forum angestoßen werden. Alternativ kann
> man, wenn der Meinungsunterschied bekannt ist, auch die Uneinigkeit
> dokumentieren. Das wäre beispielsweise bei highway=path vs.
> highway=footway/cycleway auf einer Seite zum Tagging von Radwegen der Fall.
>
> Die Aktion soll nicht auf deutschsprachige Wikiseiten beschränkt sein.
>
> Um illusorischen Vorstellungen vorzubeugen, möchte ich anmerken, dass
> das Wiki danach nicht wie neu aussehen wird. Bestimmte Missstände werden
> wir aber sicherlich verbessern können. Neben der Wiki-Pflege profitiert
> jeder Teilnehmer der Veranstaltung natürlich auch davon, die anderen
> Teilnehmer kennen zu lernen, was dem Zusammenhalt der Community gut tut.
>
> Auch wenn Seiten über Software eine der Baustellen im Wiki sind, ist es
> ausdrücklich nicht erforderlich, programmieren zu können. Kenntnisse der
> deutschen oder englischen Sprache sind viel wichtiger!
>
> Was haltet ihr von meiner Idee? Sollte von eurer Seite Interesse
> bestehen, werde ich beim FOSSGIS e.V. einen Förderantrag [2] stellen,
> die Unterkunft und Verpflegung während dieses Wochenendes zu bezahlen,
> wie der FOSSGIS e.V. das schon für seine zwei Hackweekends dort pro Jahr
> tut. Wer sich, Platz im Terminkalender vorausgesetzt, also vorstellen
> kann, an so einem Wochende teilzunehmen, möge sich bitte hier auf der
> Mailingliste oder in dem parallelen Thread im Forum melden.
> https://forum.openstreetmap.org/viewtopic.php?id=65992
>
> Viele Grüße
>
> Michael

Re: [OSM-talk-fr] Îlot central

[osm . sanspourriel]

Bonjour comme Axel tu proposes d'utiliser traffic_calming=island comme
indiqué sur le wiki.

Je vois mal comment on pourrait être contre ! On modélise plutôt qu'on
dessine. J'ai d'ailleurs suggéré à Alex de le proposer en commentant des
modifications faites par l'autre contributeur.

Jean-Yvon

Le 01/05/2019 à 10:21, Julien djakk - djakk.geograp...@gmail.com a écrit :

Bonjour !

La technique de séparation des chemins est très lourde, du coup perso
je ne l’utilise plus. Et je cherche une technique remplaçante.

J’ai un peu réfléchi, une « way » pourrait représenter toute la
chaussée, et les îlots centraux seraient des objets posés dessus.

Certains pourraient être des points (îlot de feu rouge parisien),
d’autres des lignes, comme l’exemple sur la photo de « calming_island
» -> dans le cas de la ligne, ça impliquerait de le couper la « way »
pour déclarer sur le tronçon de route concerné « traffic_calming=island. »

Qu’en pensez-vous ?

@+
Julien « djakk »


Le mer. 1 mai 2019 à 08:50, Axel Listes mailto:axe...@broman.fr>> a écrit :

Bonjour les contributeurs,

Un contributeur plutôt expérimenté sur Nancy, représente les minis
terre-pleins (îlots) centraux par une séparation de deux chemins (un
chemin par sens de circulation), et cela depuis plusieurs années.

Exemple : https://osm.org/go/0DE4Cdi3D

Depuis, je suis tombé sur une balise qui me semble plus approprié pour
ce type de représentation, l'usage de traffic_calming=island.
Notamment parce qu'elle décrit plus précisément de quoi il s'agit
sur le
terrain.

http://wiki.osm.org/wiki/Tag:traffic_calming=island

Avez-vous déjà rencontré ce type d'aménagement ? Quel est selon
vous la
meilleure façon de les représenter ?

--

L’intégralité de ce courrier électronique est exclusivement réservé à
l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas
autorisation pour une quelconque autre exploitation de données,
notamment à des fins de statistiques et de surveillance.

___
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] Îlot central

[Julien djakk]

Bonjour !

La technique de séparation des chemins est très lourde, du coup perso je ne
l’utilise plus. Et je cherche une technique remplaçante.

J’ai un peu réfléchi, une « way » pourrait représenter toute la chaussée,
et les îlots centraux seraient des objets posés dessus.

Certains pourraient être des points (îlot de feu rouge parisien), d’autres
des lignes, comme l’exemple sur la photo de « calming_island » -> dans le
cas de la ligne, ça impliquerait de le couper la « way » pour déclarer sur
le tronçon de route concerné « traffic_calming=island. »

Qu’en pensez-vous ?

@+
Julien « djakk »


Le mer. 1 mai 2019 à 08:50, Axel Listes  a écrit :

> Bonjour les contributeurs,
>
> Un contributeur plutôt expérimenté sur Nancy, représente les minis
> terre-pleins (îlots) centraux par une séparation de deux chemins (un
> chemin par sens de circulation), et cela depuis plusieurs années.
>
> Exemple : https://osm.org/go/0DE4Cdi3D
>
> Depuis, je suis tombé sur une balise qui me semble plus approprié pour
> ce type de représentation, l'usage de traffic_calming=island.
> Notamment parce qu'elle décrit plus précisément de quoi il s'agit sur le
> terrain.
>
> http://wiki.osm.org/wiki/Tag:traffic_calming=island
>
> Avez-vous déjà rencontré ce type d'aménagement ? Quel est selon vous la
> meilleure façon de les représenter ?
>
> --
>
> L’intégralité de ce courrier électronique est exclusivement réservé à
> l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas
> autorisation pour une quelconque autre exploitation de données,
> notamment à des fins de statistiques et de surveillance.
>
> ___
> 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

[OSM-talk-fr] Îlot central

[Axel Listes]

Bonjour les contributeurs,

Un contributeur plutôt expérimenté sur Nancy, représente les minis
terre-pleins (îlots) centraux par une séparation de deux chemins (un
chemin par sens de circulation), et cela depuis plusieurs années.

Exemple : https://osm.org/go/0DE4Cdi3D

Depuis, je suis tombé sur une balise qui me semble plus approprié pour
ce type de représentation, l'usage de traffic_calming=island.
Notamment parce qu'elle décrit plus précisément de quoi il s'agit sur le
terrain.

http://wiki.osm.org/wiki/Tag:traffic_calming=island

Avez-vous déjà rencontré ce type d'aménagement ? Quel est selon vous la
meilleure façon de les représenter ?

-- 

L’intégralité de ce courrier électronique est exclusivement réservé à
l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas
autorisation pour une quelconque autre exploitation de données,
notamment à des fins de statistiques et de surveillance.

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