Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary

[Axelos]

Le 15/09/2018 à 00:45, Jérôme Amagat a écrit :
> pour moi, les trunk c'est des presque autoroutes. Des routes qui permettent
> d'aller plus vite que des routes "normales".
> Rien a voir avec les routes pour automobiles, il y a des tag pour indiquer
> les véhicules autorisés ou non et il y a tellement de cas différent avec
> des route pour automobile sauf ..., des "petites" routes réservé au auto,
> des "grande" routes où les vélo peuvent aller... en plus les règle sont
> différentes dans tout les pays.
> highway=trunk n'est pas le seul tag avec highway=* qui pose des soucis...

En fait si j’interprète correctement, c'est la définition des voies
rapides / voies express ?

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

Re: [Talk-us] Address data for Miami Florida United States

[Leif Rasmussen]

Another update on the address data:
I managed to do the address data transformation by splitting the data up
into five files.  The data is now in ready to upload OSM format (except for
data errors).  All duplicates of existing addresses in the OSM database
have automatically been removed, leaving only missing addresses in the
dataset.  This means that the data could be uploaded to the OSM database
without creating duplicate addresses.
The data is available here:
https://drive.google.com/open?id=1DJGNdONqdTXMlA0e550ghsmpotqc4QM4

I split it up into five manageable files with roughly 100,000 points in
each.
The data itself has some minor issues.
1) Many "addr:city" tags are missing.  These can be added in manually
before upload by selecting all addresses with a certain postcode and adding
the city to them.  In the US, postcodes usually only have one city
associated with them, so adding the missing addr:city tags is much easier
because of this.
2) Some other tags are missing from about 50 addresses.  They don't have
"addr:street", "addr:postcode", or "addr:city".  Just "addr:housenumber"
and "addr:state".
Other than that, the data looks great!
I will fix up the wiki page and contact the imports mailing list sometime
this weekend if I can.

Levente Juhász,
Manually adding the addresses would take way too long.  Instead, a tasking
manager project should be created for organizing address upload.  If the
uploader wants, they can merge the data with existing features such as
buildings, but this is not required.  An upload without merging would
simply add all missing addresses around the existing ones.  I was thinking
that the tasks be about 5,000 - 10,000 addresses each.  This should allow
for quick and easy upload, even if Miami does not have very many
contributors interested in helping.
Thanks,
Leif Rasmussen
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Les bretelles

[Philippe Verdy]

Les "*_link" ne s'appliquent qu'à des vraies bretelles, des voies sans
adresse la plupart du temps et sans nom et sans demi-tour possible, le plus
souvent à voie unique et sens unique. Leur longueurs est assez faible pour
être intégré comme élément secondaire de la voie majeure à laquelle elles
donnent accès ou permettent de sortir. Cela ne s'applique pas aux giratoire
puisque le demi-tour est possible justement par ces giratoires, et sur une
bretelle de sortie il n'y a aucun cédez-le-passage ou stop à l'entrée (il
peut y en avoir en sortie et il y en a en fait la plupart du temps) ou à la
sortie (sur une bretelle d'entrée il y a un cédez-le-passage ou stop
éventuellement en sortie masi souvent unoiquement en fin de voie
d'accélération quand il faut se rabattre à gauche sur la voie principale.

Je ne pense pas qu'il y ait la moindre ambiguité en terme de conduite ou
routage, la seule issue de ces bretelles d'entrée est unique, c'est la
voire principale. Les bretelles de sortie ont aussi une voie de
"préparation" (mettant souvent fin à une zone d'arrêt) pour tourner à
droite et une signalisation en amont et là aussi une seule direction
possible de cette voie à l'entrée, même si la sortie est un carrefour avec
stop ou cédez-le-passage (ce qui n'est pas toujours le cas dans les
bretelles de jonction entre deux autoroutes par exemple où les voies
d'accélération continuent sans fusionner et s'ajoutent au compte des voies
totales de la route principale.

Le cas des secondary_link ou tertiary_link est plus ambigu : difficile de
les qualifier comme "bretelles" quand il y a des accès privés latéraux (ou
tout autres highway=service) et surtout s'il y a des adresses, des
parkings, des garages. et encore plus si les arrêts sont autorisés ou
bordées de stationnement, même si c'est une voie unique en sens unique.

Je ne vois pas l'intérêt de faire la différence selon le type de voie
secondaire que ces bretelles interconnectent : on peut toujours regarder ce
qu'il y a au noeud d'extrémité, mais la plupart du temps c'est une
intersection ou un giratoire avec très souvent plusieurs types possibles.



Le ven. 14 sept. 2018 à 23:52, djakk djakk  a écrit :

> Oui, en fait il s’agit du type de la voie qui est 2ème dans le classement
> des voiries que connecte la bretelle : motorway vers secondary, tertiary et
> primary -> on retiendra primary.
>
>
> djakk
>
>
> Le ven. 14 sept. 2018 à 23:23, Philippe Verdy  a
> écrit :
>
>> on a déjà les clés destination=* et sinon ces bretelles aboutissent à une
>> extrémité sur plusieurs routes de type différent à leur jonction. Je vois
>> mal comment désigner le type de l'autre côté quand il peut y en avoir
>> plusieurs (souvent aussi la destination est vers un rond-point, mais il
>> hérite de la typologie le plus importante des voies connectées).
>> On ne peut pas tout mettre dans un tag et en pratique ces bretelles font
>> partie de la voie principale qu'elles connectent. Le seul fait de voir un
>> "*_link" signifie déjà qu'il y a une connexion entre deux types, on connait
>> l'un et l'autre est un type inférieur.
>>
>> Le ven. 14 sept. 2018 à 21:40, djakk djakk  a
>> écrit :
>>
>>> Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer
>>> la valeur de highway=*_link ? (En pratique c’est fait fréquemment en France)
>>>
>>>
>>> djakk
>>>
>>> Le ven. 14 sept. 2018 à 18:46, djakk djakk  a
>>> écrit :
>>>
 Salut !

 Une autre chose me tarabusce au sujet des routes dans osm, c’est
 l’absence d’info sur le type de route joint par une bretelle
 (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une
 autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary ? On
 ne sait pas directement.

 Et je trouve cette information plus importante. En effet, si on relie
 une autoroute à une autoroute, ou si on relie une autoroute à une tertiary,
 on pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
 Impossible en l’état actuel.

 Du coup je propose link_from et link_to : pour une bretelle dans le
 sens autoroute vers tertiary, on aura link_from=motorway et
 link_to=tertiary.

 djakk

 ___
>>> 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] Classification des highway - trunk comme super-primary

[Jérôme Amagat]

La définition de ces "trunk" est un sujet récurent sur cette liste. Le
sujet revient, plusieurs personnes donnent leur avis, les avis ne sont pas
compatible et puis la discussion n'aboutit a rien.
Je pense que plusieurs personnes dont moi, ne voit pas pourquoi reperdre
son temps dans cette discussion qui est sans fin :(
Il y a peu de temps le sujet a été aussi abordé sur la liste talk en
anglais (j'ai pas lu je sais pas trop ce qui a été dit).
pour moi, il faut une décision au niveau mondial avec un vote pour que les
choses soient claires et que chaque pays n'ai pas sa définition.

allez, je donne mon avis :) :
je vois pas pourquoi les trunk serait des super-primary sinon pourquoi
appeler les primary des "primary" :)
pour moi, les trunk c'est des presque autoroutes. Des routes qui permettent
d'aller plus vite que des routes "normales".
Rien a voir avec les routes pour automobiles, il y a des tag pour indiquer
les véhicules autorisés ou non et il y a tellement de cas différent avec
des route pour automobile sauf ..., des "petites" routes réservé au auto,
des "grande" routes où les vélo peuvent aller... en plus les règle sont
différentes dans tout les pays.
highway=trunk n'est pas le seul tag avec highway=* qui pose des soucis...

Le ven. 14 sept. 2018 à 18:52, djakk djakk  a écrit :

> Oui j’ai été complètement cavalier dans ma manière de faire ! Cela me
> travaille à chaque fois que je regarde une carte osm :)
> C’est pas comme si la situation précédente était satisfaisante: il y avait
> de nombreuses guerres d’édition car la définition FR était ambiguë.
> Je serai très attentif à mes messages privés sur osm et au “revert”, je ne
> partirai pas dans des guerres d’édition, je verrai qui est “chaud” sur le
> sujet. (Car si pas de réponse sur la mailing-list, c’est que personne n’est
> intéressé par le sujet ... sur la mailing-list mais tout le monde n’est pas
> sur la ML !)
>
> djakk
>
>
> Le ven. 14 sept. 2018 à 11:31, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> oui en effet @Axelos   Dans ce cas j'avoue que ça
>> aurait une utilité. Sachant que c'est comme un raccourci une voie à 110
>> permet l'accès au véhicule agricoles que le permet pas les voies avec
>> panneau C107. C'est là tous le problème. On se retrouve donc avec des
>> panneaux pour autoriser les engin agricole à rouler...
>>
>> Les routes pour automobile impose le même mode de fonctionnement q'une
>> autoroute. Les trunck en France ont été défini sur une logique de vitesse
>> en sur le fait d'avoir au moins de voies séparé par terre-plein central...
>>
>> Bref ça fait bien longtemps que l'on discute de définir un modèle
>> présentant des exemples de cas pour définir des logiques (interurbaines ou
>> extraurbaines) mais faire un tableau et le valider en ayant l'accord de la
>> plus part n'est pas simple.
>>
>> On doit bien pouvoir identifier des cas où cela est utile de choisir un
>> certains type de clé. Sans devoir uniquement se baser sur un référentiel où
>> la volonté d'une commune à monter qu'une voie est un axe majeur quand ce
>> n'est pas le cas.
>>
>> A défaut d'explications clair et d'une logique bien défini on se retrouve
>> à voir tout et son contraire...
>>
>> Si l'on veut améliorer ce système il faudrait encore en définir un modèle
>> plus clair (ne serait ce que pour notre territoire) car ce sujet revient
>> sans cesse sans y répondre ou avec des réponse complètement contraire.
>>
>> Ce travail a déjà été initié mais sans aboutir il me semble car la
>> priorité avait été donner pour compléter les voies manquante et adjoindre
>> les noms pour le projet BANO. Maintenant, c'est classification ont deux
>> objectifs:
>> - le routing
>> - l'accessibilité
>>
>> La base ne sert pas à définir une logique de règlementaire (sinon c'est
>> une autre clé)
>>
>> Si l'on veut aussi définir des règles pour choisir comment taguer les
>> voies non classifiées et les chemins et voie de service.
>> Pour les chemins je crois que réglementairement il n'y a pas lieux d'y
>> mettre des panneaux de sortie et entrée de ville.
>> Merci de me confirmer ce sujet si vous en avait l'occassion.
>>
>> Que voulons nous et quelles limites on y met?
>> Bonne journée.
>>
>>
>> Le jeu. 13 sept. 2018 à 19:44, Axelos  a écrit :
>>
>>> Le 13/09/2018 à 16:03, Christian Rogel a écrit :
>>> >> Le 12 sept. 2018 à 20:10, JB  a écrit :
>>> >>
>>> >> Pas de réponse = accord de tous ? Je pense plutôt l'inverse. Le sujet
>>> a été discuté, rediscuté plusieurs et encore plusieurs fois ces dernières
>>> années. Tu as tenté de relancer la discussion sans grande réussite il y a
>>> quelques mois, si je ne me trompe pas. Ça n'a pas l'air de prendre cette
>>> fois-ci non-plus. Laisser les choses telles qu'elles sont, ce qui semble le
>>> compromis le plus stable ou au mieux le moins bancal, t'empêchera-t-il
>>> de dormir tranquille ?
>>> >> Je pense que le panier de crabes est mieux ainsi, en équilibre, que
>>> si on le retourne une fois encore. Je pense que 

Re: [OSM-talk-be] moped_*=* tag on the border relation with France

[Ruben]

On Fri, 14 Sep 2018 14:36:12 +0200, Jakka  wrote:
> Must this be adapted and who can do this ?
> Possible on other border Relation to ?
> 
> Where did I see it.
> detail border Menen.
> https://www.openstreetmap.org/#map=22/50.78637416053381/3.1269890021261264
> see relation "default Belgium, Flanders, highway default values 1 lid"
> relation 6900538
> def:highway=cycleway;access:moped_a:conditional
> def:highway=cycleway;access:moped_b:conditional
> 
> -was missing --> moped_P

moped_p is pretty new. So yes, it's not in the "defaults" relation yet.

Realisticallly, I don't think anyone actually uses these defaults relations. 
But I'm the one who created them for Belgium, so I can add moped_p.

> -capital letter or not ??? _A or _a; _B or_b; _P or_p
> 
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Belgium
> see notes:
> moped in Belgium actually comprises three vehicle classes: "moped_A", 
> "moped_B" and "moped_P", cycleways may allow any combination of them 
> (including none at all), depending on the signs used, and the road the 
> cycleway belongs to.
> use in Belgium:
> capitalletter
> http://overpass-turbo.eu/s/BSF
> versus lowercase
> http://overpass-turbo.eu/s/BSG

I dislike capital letters in keys*, so I always use moped_a, not moped_A.

More interesting queries are:
ABP: https://overpass-turbo.eu/s/BTF
abp: https://overpass-turbo.eu/s/BTG
Those queries match all keys that contain moped_[abpABP], like oneway:moped_a, 
and not only moped_a.
And they work on Belgium, not on the currently visible region.

It would be easy to retag everything to either capital or no capital with 
Level0, if that would be desirable. Biggest issue would probably be reaching a 
consensus.

* Except when it's a name, like ref:De_Lijn=123456

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

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Oui, en fait il s’agit du type de la voie qui est 2ème dans le classement
des voiries que connecte la bretelle : motorway vers secondary, tertiary et
primary -> on retiendra primary.


djakk


Le ven. 14 sept. 2018 à 23:23, Philippe Verdy  a écrit :

> on a déjà les clés destination=* et sinon ces bretelles aboutissent à une
> extrémité sur plusieurs routes de type différent à leur jonction. Je vois
> mal comment désigner le type de l'autre côté quand il peut y en avoir
> plusieurs (souvent aussi la destination est vers un rond-point, mais il
> hérite de la typologie le plus importante des voies connectées).
> On ne peut pas tout mettre dans un tag et en pratique ces bretelles font
> partie de la voie principale qu'elles connectent. Le seul fait de voir un
> "*_link" signifie déjà qu'il y a une connexion entre deux types, on connait
> l'un et l'autre est un type inférieur.
>
> Le ven. 14 sept. 2018 à 21:40, djakk djakk  a
> écrit :
>
>> Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la
>> valeur de highway=*_link ? (En pratique c’est fait fréquemment en France)
>>
>>
>> djakk
>>
>> Le ven. 14 sept. 2018 à 18:46, djakk djakk  a
>> écrit :
>>
>>> Salut !
>>>
>>> Une autre chose me tarabusce au sujet des routes dans osm, c’est
>>> l’absence d’info sur le type de route joint par une bretelle
>>> (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une
>>> autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary ? On
>>> ne sait pas directement.
>>>
>>> Et je trouve cette information plus importante. En effet, si on relie
>>> une autoroute à une autoroute, ou si on relie une autoroute à une tertiary,
>>> on pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
>>> Impossible en l’état actuel.
>>>
>>> Du coup je propose link_from et link_to : pour une bretelle dans le sens
>>> autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.
>>>
>>> djakk
>>>
>>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Io ci ho trafficato un po' ed ho trovato parecchi name non aggiornati.
Fareste un revert per tornare alla situazione coerente name/brand, ma con
entrambi non più esistenti?

Sulla qualità dell'operator trovate i file di raffinazione in github [1]...
io vedo problemi solo su qualche maiuscolo.
Sul garbage-in, garbage-out lo sentivo trentanni fa. Credo sia un dogma
superato.

[1]
https://github.com/cascafico/OSM-ItalyFuelStations/blob/master/openrefine_operations.json

Il 14 set 2018 7:08 PM, "Martin Koppenhoefer"  ha
scritto:



2018-09-14 15:45 GMT+02:00 Carmine Massarelli :

> Che ne pensate se inserissimo anche gli orari?
> E' ancora valida questa autorizzazione? https://wiki.openstreetmap.org
> /wiki/Importazione_distributori_metano



io mi fermerei con l'import. Troviamo errori su errori e non abbiamo
nemmeno visto la meta dei dati che abbiamo presi e buttati dentro
cecamente, e adesso aggiungiamo anche altro di questa qualità? Per me no.
Sembra il db MISE sia un db come il nostro (UGC), solo che la gente che ci
contribuisce sembra lo faccia per dovere e non per piacere  ;-)  e
apparentemente non ci sta nessuno che mette ordine ;-)

Ciao,
Martin

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

Re: [OSM-talk-fr] Les bretelles

[Philippe Verdy]

on a déjà les clés destination=* et sinon ces bretelles aboutissent à une
extrémité sur plusieurs routes de type différent à leur jonction. Je vois
mal comment désigner le type de l'autre côté quand il peut y en avoir
plusieurs (souvent aussi la destination est vers un rond-point, mais il
hérite de la typologie le plus importante des voies connectées).
On ne peut pas tout mettre dans un tag et en pratique ces bretelles font
partie de la voie principale qu'elles connectent. Le seul fait de voir un
"*_link" signifie déjà qu'il y a une connexion entre deux types, on connait
l'un et l'autre est un type inférieur.

Le ven. 14 sept. 2018 à 21:40, djakk djakk  a écrit :

> Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la
> valeur de highway=*_link ? (En pratique c’est fait fréquemment en France)
>
>
> djakk
>
> Le ven. 14 sept. 2018 à 18:46, djakk djakk  a
> écrit :
>
>> Salut !
>>
>> Une autre chose me tarabusce au sujet des routes dans osm, c’est
>> l’absence d’info sur le type de route joint par une bretelle
>> (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une
>> autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary ? On
>> ne sait pas directement.
>>
>> Et je trouve cette information plus importante. En effet, si on relie une
>> autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on
>> pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
>> Impossible en l’état actuel.
>>
>> Du coup je propose link_from et link_to : pour une bretelle dans le sens
>> autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.
>>
>> djakk
>>
>> ___
> 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] Vetorização de matas no OSM com Sentinel-2

[Paulo Carvalho]

O problema, Sérgio, quando se usa uma fórmula, efetivamente estás resumindo
duas variáveis a uma variável só.  Pela forma da mancha no crossplot B11
versus NDVI, a correlação entre elas não é linear, ou seja, elas não
informam a mesma coisa.  Pelo contrário, temos que aumentar a
dimensionalidade.  Seria importante vermos como os pontos se agrupam.
Talvez haja até bem mais do que duas classes.

Em sex, 14 de set de 2018 às 17:10, Sérgio V.  escreveu:

> Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único
> pixel"
>
>
> A coisa que me intriga ainda é que estava reexaminando as imagens e
> histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que
> pode ser confirmada na alta resolução do Bing.
>
> E os histogramas me parecem ainda indicar que apontam para a confirmação da
> formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de
> classes e diferenciação de:
>
> 1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)
>
> 2)forest  (mais jovem, mais úmida, mais ativa em clorofila)
>
> 3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para
> "null").
>
>
> Imagens junto com histogramas correspondentes do caso B11 x
> ((1-NDVI)*4000):
>
> https://i.imgur.com/4uKNw1r.jpg
>
> É a mesma área que peguei como exemplo desde o início, porque tem todos os
> tipos que poderiam interferir, e dá pra examinar se o resultado distingue
> bem wood e forest do resto:
>
> wood; forest; river; pond; campos ralos; farmland; estradas; ...
>
> Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos,
> de vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood
> variam mais no espectro: há área velhas e algumas em crescimento. Então há
> mistura das 2 classes.
>
> Já no B11 se destacam bem claramente entre si: uma não invade a margem de
> valores da outra.
>
>
> Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200),
> daria pra usar só B11.
>
>
> -No Cerrado, por exemplo, bastou usar só B11, não tem mata jovem/forest,
> nem mais úmida, deu pra usar só B11:
>
> água no B11 (~50a600) ;  wood(~1000a1300).
>
> É que também os tipos são de vegetação do Cerrado são diferentes, matas
> mais secas, mais castigadas, do que as matas mais úmidas da Mata Atlântica.
> Acho sempre vão apresentar valores um tanto diferentes tendendo pro mais
> seco.
>
>
> https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Cerrado_.28vetorizado_e_100.25_validado_para_OSM.29
>
>
> -Já na Amazônia, úmida mas também com áreas de mata velha, a ponderação
> teve que ser não x4000, mas x500, para B11 + ((1- NDVI ) * 500 ):
>
>
> https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Amaz.C3.B4nia_.28vetorizado_e_100.25_validado_para_OSM.29
>
>
> Claro, se tivesse um índice ou fórmula única pra usar em todos biomas
> igualmente, seria melhor sem dúvida.
>
> Não sei se é possível.
>
>
> No scatterplot ainda vou ver como identificar os grupos ali dentro da
> mancha.
>
> Ainda vou ver o que vc indicou mais.
>
> Obrigado!
>
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
>
> --
> *De:* Paulo Carvalho 
> *Enviado:* sexta-feira, 14 de setembro de 2018 13:45
> *Para:* OSM talk-br
> *Assunto:* Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2
>
> Oi, Sérgio, vamos lá...
>
> Em sex, 14 de set de 2018 às 12:25, Sérgio V. 
> escreveu:
>
> Bom dia Paulo, pessoal.
>
> Fiz upscaling pra ver crossplot/scatterplot, com 549x549 px =   301.401
> pixels (pontos);
>  - Imagem original tava com 10.980x10.980 px = 120.560.400 pixels :
> 120.560.400 pontos, inviável, processador e RAM assobiaram.
>
>
> Perfeito. Não se faz análise exploratória dos dados com tantos pontos.
> 120M de amostras é impossível mesmo.  E mesmo se fosse viável, daria para
> ver pouco.
>
>
> E abri os histogramas.
>
> Obtive os seguintes gráficos (em jpg no Imgur):
>
> Histograma B11 : https://i.imgur.com/jsvnFjj.jpg
>
>
> Só B11 parece dizer que há duas classes (as duas modas em 1200 e 2000
> aproximadamente).  Não obstante um tanto misturadas.  Mas outra variável
> pode ajudar a desempatar.
>
>
> Histograma NDVI : https://i.imgur.com/FrEZGOO.jpg
>
> NDVI parece dizer que há três classes (as modas em 0,2; 0,6 e 0,7).  A
> classe em centrada em 0,2 parece bem separada.
>
>
> Histograma (1-NDVI)*4000 : https://i.imgur.com/TUPi3Tl.jpg
>
>
> Não percas tempo com isso.  Apenas mudou a escala.  Ela continuia
> informando a mesma coisa: que parece haver três classes.
>
>
>
> Scatterplot B11 x NDVI : https://i.imgur.com/z4yPjtY.jpg
> Scatterplot B11 x (1-NDVI)*4000 : https://i.imgur.com/j4WuO7C.jpg
>
>
> Parece interessante, porém só aparece uma mancha negra.  Seria importante
> vermos onde os pontos estão concentrados.  Pontos concentrados são indícios
> de que há uma classe ali.  Há como definir a marca do crossplot para um
> único pixel?  Se não for possível, tenta 

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Grazie a te per le precisazioni su cui concordo pienamente.

Ci tengo a chiarire che la mia (/forse un po' rude.../) citazione non era 
assolutamente rivolta "/ad personam/" nei confronti di chicchessia: voleva solo 
essere la considerazione, magari un po' triste ma temo reale, che a volte i 
dadi della sorte ci rifilano dati sbagliati. Amen, succede. E' importante però 
che abbiamo la capacità di identificarli e serenamente scartarli.

Sergio


On 2018-09-14 21:45, Volker Schmidt wrote:
>
> Senza conoscere i dettagli della cosa, mi è venuta in mente una delle 
> prime massime che ho imparato quando, una vita fa, ho incominciato ad 
> occuparmi di informatica (/che ai tempi si chiamava "elaborazione elettronica 
> dei dati"/): "*/Garbage in, garbage out/*", cioè se parti da dati spazzatura, 
> avrai risultati spazzatura, indipendentemente dalla tua bravura...
>
> Grazie per questa annotazione. Io l'avevo pensato, ma non volevo scriverlo in 
> lista.
> La mia critica principale a OSM nella mia zona (Veneto) è che ci sono tanti 
> dati approssimativi o sospetti di errore nel DB che ogni volta che aggiungo 
> dettagli devo anche mettere apposto tutta la zona intorno (o meglio dovrei 
> farlo ...).
> L'idea di base d inserire dati approssimativi o da controllare/correggere 
> dopo è sbagliato per due motivi molto diversi:
> - il numero di mappatori attivi è troppo basso
> - tutti siamo umani e correggere errori nel lavori altrui non è piacevole.
> Ho seguito un po' la discussione su questo import specifico e devo dire che 
> mi sono fatto l'idea che ci sono troppi problemi con la qualità dei dati di 
> partenza.
>
> E un ultima, un po' più fondamentale considerazione: una delle regole di base 
> per la raccolta dati è di non duplicare dati, sempre solo utilizzare link ai 
> dati originali, una regola che tutti gli import in OSM violano alla grande. 
> Dati duplicati soffrono del fondamantal problema di aggiornamanto/modifica 
> non sincronizzata.
>
>
>
> 
>  Virus-free. www.avast.com 
> 
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Address data for Miami Florida United States

[Levente Juhász]

Great stuff, Leif! I will catch up with this project over the weekend and
will provide some input.

I have access to a few workstations with a bunch of memory so I can help
out with converting/processing the input data if needed. Just let me know.
I don't think of the size of these datasets as an issue in terms of
processing (not even the buildings). As you said, splitting them up into
smaller chunks or using a totally different toolset would also work.

Finding enough people to review and put the data on the map will be a
bigger issue in Miami, imho. You guys are planning to implement an entirely
manual approach, correct?

Cheers,
Levente



On Fri, Sep 14, 2018, 4:06 PM Leif Rasmussen <354...@gmail.com> wrote:

> Update on the address data:
> I tried transforming the small data file (550,000 addresses) to OSM
> format, but my computer ran out of memory.  I will try using a more
> powerful computer later.  The transformation worked perfectly on a smaller
> file of 8000 addresses in Miami Beach, however.  I uploaded that sample
> file to a google drive folder
> .
> Simply download the file and drag and drop it into JOSM to view that
> addresses.  The address data source only had "addr:city" for some of the
> addresses, so that tag will have to be added manually based on postcode
> later.
> Thanks,
> Leif Rasmussen
>
> Also, the addresses with numbered street names (4th Street) have not been
> expanded (to eg. "Fourth Street").  The roads in OSM currently have the
> numbered versions (4th Street), so I will just leave the addresses like
> they are now.
>
> On Thu, Sep 13, 2018 at 10:42 AM mangokm40 
> wrote:
>
>> Mr. Rasmussen,
>>
>> Thanks for the offer!  I definitely need help. :)
>>
>> I looked, and failed to find, the layer without unit#.  That's what I
>> thought would be preferred.  Thanks
>> for spotting it.  I don't see why we would search for a specific unit on
>> a map.  When I navigate, I would
>> just want directions to "1234 NW 33rd Ct", not "1234 NW 33rd Ct Apt 6".
>> If you know
>> of a good reason for the unit #s, let me know.  It doesn't matter to me,
>> since I don't need navigation in
>> Miami.  :D
>> If you think 600k points is big, imagine the building footprints. :)
>>  It's available, if required.  Heck, they
>> even make a 3d building layer available.  But I don't think we'll enjoy
>> the size.
>>
>> I knew the license is not a problem.  However, I saved that email just in
>> case it comes up.
>>
>> I'm going to read the info Mr. Juhász provided.  Unfortunately, I'm way
>> behind here.
>> Also, I replied to all b/c I think that's what I'm supposed to do.
>> However, I don't want to 'bug' people on
>> the list.  Hopefully, someone will let me know if this needs to go
>> off-list.
>>
>>
>> (_8'()
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, September 12, 2018 4:17 PM, Leif Rasmussen <
>> 354...@gmail.com> wrote:
>>
>> Hi Mango,
>> I have quite a lot of experience with address imports, and would love to
>> help with Miami.  I have visited Miami several times, and have grown a
>> liking for it.  Adding addresses there would be a real pleasure.
>> There appears to be two address data sets - one with "addr:unit", and one
>> without.  The one with "addr:unit" addresses
>> 
>>  has 1,166,445
>> points, and the one without
>> 
>> has 586,171 points.  Both of these should be considered.  I would suggest
>> importing the one with condos, or "addr:unit" features if the quality is
>> good.  Otherwise, I think that the dataset without addr:unit should be
>> imported.
>> Also, the license seems OK.  According to the Miami-Dade County
>> Buildings Import
>> ,
>> the license is public domain, which they claim is true of all government
>> produced data in Florida.
>> The only issue I see with the data is the size.  My laptop took 5 minutes
>> to open the address points (including addr:unit, so 1,166,445 nodes) and
>> more than 20 minutes to edit a single key.  This could be worked around,
>> though, by splitting up the data.
>> I created a wiki page for the import
>> ,
>> which is a step of the Import Guidelines
>> . Sending a
>> proposal to the local community and imports mailing list will also be
>> needed.
>> I hope that this import will end up working out!
>> Leif Rasmussen
>>
>>
>>
>>
>> (_8'()
>>
>> Sent with ProtonMail  Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>>
> On Wednesday, September 12, 2018 4:17 PM, Leif Rasmussen 

Re: [Talk-pt] Águeda | oficina de dados abertos 11e 12 de outubro

[Marcos Oliveira]

Obrigado pelo aviso!

Miguel Tavares  escreveu no dia sexta, 14/09/2018
à(s) 16:35:

> Comunidade,
>
> para vos informar de nova oficina de dados abertos a realizar em Águeda
> nos dias 11 e 12 de outubro.
>
> Junto panfleto sobre o evento para contextualizar.
>
> Para inscrições directas: *aqui*
> 
>
>
>
> ab,
>
> miguel
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único 
pixel"


A coisa que me intriga ainda é que estava reexaminando as imagens e 
histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que pode 
ser confirmada na alta resolução do Bing.

E os histogramas me parecem ainda indicar que apontam para a confirmação da 
formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de classes e 
diferenciação de:

1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)

2)forest  (mais jovem, mais úmida, mais ativa em clorofila)

3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para "null").


Imagens junto com histogramas correspondentes do caso B11 x ((1-NDVI)*4000):

https://i.imgur.com/4uKNw1r.jpg


É a mesma área que peguei como exemplo desde o início, porque tem todos os 
tipos que poderiam interferir, e dá pra examinar se o resultado distingue bem 
wood e forest do resto:

wood; forest; river; pond; campos ralos; farmland; estradas; ...


Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos, de 
vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood variam 
mais no espectro: há área velhas e algumas em crescimento. Então há mistura das 
2 classes.

Já no B11 se destacam bem claramente entre si: uma não invade a margem de 
valores da outra.


Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200), daria 
pra usar só B11.


-No Cerrado, por exemplo, bastou usar só B11, não tem mata jovem/forest, nem 
mais úmida, deu pra usar só B11:

água no B11 (~50a600) ;  wood(~1000a1300).

É que também os tipos são de vegetação do Cerrado são diferentes, matas mais 
secas, mais castigadas, do que as matas mais úmidas da Mata Atlântica. Acho 
sempre vão apresentar valores um tanto diferentes tendendo pro mais seco.

https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Cerrado_.28vetorizado_e_100.25_validado_para_OSM.29


-Já na Amazônia, úmida mas também com áreas de mata velha, a ponderação teve 
que ser não x4000, mas x500, para B11 + ((1- NDVI ) * 500 ):

https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Amaz.C3.B4nia_.28vetorizado_e_100.25_validado_para_OSM.29


Claro, se tivesse um índice ou fórmula única pra usar em todos biomas 
igualmente, seria melhor sem dúvida.

Não sei se é possível.


No scatterplot ainda vou ver como identificar os grupos ali dentro da mancha.

Ainda vou ver o que vc indicou mais.

Obrigado!



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: sexta-feira, 14 de setembro de 2018 13:45
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

Oi, Sérgio, vamos lá...

Em sex, 14 de set de 2018 às 12:25, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Bom dia Paulo, pessoal.

Fiz upscaling pra ver crossplot/scatterplot, com 549x549 px =   301.401 pixels 
(pontos);
 - Imagem original tava com 10.980x10.980 px = 120.560.400 pixels : 120.560.400 
pontos, inviável, processador e RAM assobiaram.

Perfeito. Não se faz análise exploratória dos dados com tantos pontos. 120M de 
amostras é impossível mesmo.  E mesmo se fosse viável, daria para ver pouco.

E abri os histogramas.

Obtive os seguintes gráficos (em jpg no Imgur):

Histograma B11 : https://i.imgur.com/jsvnFjj.jpg

Só B11 parece dizer que há duas classes (as duas modas em 1200 e 2000 
aproximadamente).  Não obstante um tanto misturadas.  Mas outra variável pode 
ajudar a desempatar.

Histograma NDVI : https://i.imgur.com/FrEZGOO.jpg
NDVI parece dizer que há três classes (as modas em 0,2; 0,6 e 0,7).  A classe 
em centrada em 0,2 parece bem separada.

Histograma (1-NDVI)*4000 : https://i.imgur.com/TUPi3Tl.jpg

Não percas tempo com isso.  Apenas mudou a escala.  Ela continuia informando a 
mesma coisa: que parece haver três classes.


Scatterplot B11 x NDVI : https://i.imgur.com/z4yPjtY.jpg
Scatterplot B11 x (1-NDVI)*4000 : https://i.imgur.com/j4WuO7C.jpg

Parece interessante, porém só aparece uma mancha negra.  Seria importante 
vermos onde os pontos estão concentrados.  Pontos concentrados são indícios de 
que há uma classe ali.  Há como definir a marca do crossplot para um único 
pixel?  Se não for possível, tenta reduzir a quantidade de amostras de ~100k 
para ~5k.

abcs,

PC

(c/ reescale para abranger próximo da área plotada.)

Anomalias de pixels acho que não tem muito.
Nuvem já remove na escolha de imagem, por cloud=0. E verifica com B10 se ainda 
tem alguma mínima.

A questão acho que centraria em encontrar uma referência de base universal 
(imagem original básica; ou algoritmo) para wood e forest, ou wood sozinho:
B11 sozinho ?
NDVI; ou EVI2; sozinhoS ?
Fórmula empírica (podem chamar gambiarra tb) tipo B11 * (1-NDVI)*4000 ?
Algum algoritmo mais pato (depois ainda vou estudar os algoritmos de 
classificação multivariados que vc indicou).

Re: [Talk-it] dataset MISE distributori

[Volker Schmidt]

> Senza conoscere i dettagli della cosa, mi è venuta in mente una delle
> prime massime che ho imparato quando, una vita fa, ho incominciato ad
> occuparmi di informatica (*che ai tempi si chiamava "elaborazione
> elettronica dei dati"*): "*Garbage in, garbage out*", cioè se parti da
> dati spazzatura, avrai risultati spazzatura, indipendentemente dalla tua
> bravura...
>
Grazie per questa annotazione. Io l'avevo pensato, ma non volevo scriverlo
in lista.
La mia critica principale a OSM nella mia zona (Veneto) è che ci sono tanti
dati approssimativi o sospetti di errore nel DB che ogni volta che aggiungo
dettagli devo anche mettere apposto tutta la zona intorno (o meglio dovrei
farlo ...).
L'idea di base d inserire dati approssimativi o da controllare/correggere
dopo è sbagliato per due motivi molto diversi:
- il numero di mappatori attivi è troppo basso
- tutti siamo umani e correggere errori nel lavori altrui non è piacevole.
Ho seguito un po' la discussione su questo import specifico e devo dire che
mi sono fatto l'idea che ci sono troppi problemi con la qualità dei dati di
partenza.

E un ultima, un po' più fondamentale considerazione: una delle regole di
base per la raccolta dati è di non duplicare dati, sempre solo utilizzare
link ai dati originali, una regola che tutti gli import in OSM violano alla
grande. Dati duplicati soffrono del fondamantal problema di
aggiornamanto/modifica non sincronizzata.




Virus-free.
www.avast.com

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

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la
valeur de highway=*_link ? (En pratique c’est fait fréquemment en France)


djakk

Le ven. 14 sept. 2018 à 18:46, djakk djakk  a écrit :

> Salut !
>
> Une autre chose me tarabusce au sujet des routes dans osm, c’est l’absence
> d’info sur le type de route joint par une bretelle (highway=*_link),
> c’est-à-dire qu’on sait qu’une bretelle joint une autoroute mais on n’a pas
> d’info sur l’autre côté ! Primary, secondary ? On ne sait pas directement.
>
> Et je trouve cette information plus importante. En effet, si on relie une
> autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on
> pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
> Impossible en l’état actuel.
>
> Du coup je propose link_from et link_to : pour une bretelle dans le sens
> autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.
>
> djakk
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSRM-talk] Different routing than demo server

[Frédéric Rodrigo]

Hello,

The demo server use in addition private Mapbox real-time traffic data.

Frédéric.


Le 14/09/2018 à 19:43, Jose Florido a écrit :

Hi!

I just deployed your docker images on a new server and started osrm
backed with latest data for Louisiana from Geofabrik.

I am finding a big difference in routing for some cases, compared to
the running demo server at project-osrm.org

For example this route:

http://map.project-osrm.org/?z=10=29.871611%2C-90.144196=29.595770%2C-90.719535=29.949932%2C-90.070116=en=0

http://104.248.79.106:9966/?z=10=29.871611%2C-90.144196=29.595770%2C-90.719535=29.949932%2C-90.070116=en=0

Clearly demo server does a better job routing here.

I am running the docker images right out of the box. MLD algo and
processing data with extract, partition and customize steps. I did not
modify the car.lua profile.

Any idea why is there such a difference?

Thanks!
Jose

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




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

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Senza conoscere i dettagli della cosa, mi è venuta in mente una delle prime 
massime che ho imparato quando, una vita fa, ho incominciato ad occuparmi di 
informatica (/che ai tempi si chiamava "elaborazione elettronica dei dati"/): 
"*/Garbage in, garbage out/*", cioè se parti da dati spazzatura, avrai 
risultati spazzatura, indipendentemente dalla tua bravura...

E sentire il MISE?

Sergio


On 2018-09-14 19:07, Martin Koppenhoefer wrote:
>
>
> 2018-09-14 15:45 GMT+02:00 Carmine Massarelli 
>  >:
>
> Che ne pensate se inserissimo anche gli orari?
> E' ancora valida questa autorizzazione? 
> https://wiki.openstreetmap.org/wiki/Importazione_distributori_metano 
> 
>
>
>
> io mi fermerei con l'import. Troviamo errori su errori e non abbiamo nemmeno 
> visto la meta dei dati che abbiamo presi e buttati dentro cecamente, e adesso 
> aggiungiamo anche altro di questa qualità? Per me no. 
> Sembra il db MISE sia un db come il nostro (UGC), solo che la gente che ci 
> contribuisce sembra lo faccia per dovere e non per piacere  ;-)  e 
> apparentemente non ci sta nessuno che mette ordine ;-)
>
> Ciao,
> Martin
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSRM-talk] Different routing than demo server

[Jose Florido]

Hi!

I just deployed your docker images on a new server and started osrm
backed with latest data for Louisiana from Geofabrik.

I am finding a big difference in routing for some cases, compared to
the running demo server at project-osrm.org

For example this route:

http://map.project-osrm.org/?z=10=29.871611%2C-90.144196=29.595770%2C-90.719535=29.949932%2C-90.070116=en=0

http://104.248.79.106:9966/?z=10=29.871611%2C-90.144196=29.595770%2C-90.719535=29.949932%2C-90.070116=en=0

Clearly demo server does a better job routing here.

I am running the docker images right out of the box. MLD algo and
processing data with extract, partition and customize steps. I did not
modify the car.lua profile.

Any idea why is there such a difference?

Thanks!
Jose

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

Re: [Talk-it] dataset MISE distributori

[Federico Cortese]

On Fri, Sep 14, 2018 at 7:08 PM Martin Koppenhoefer
 wrote:
>
> io mi fermerei con l'import. Troviamo errori su errori e non abbiamo nemmeno 
> visto la meta dei dati che abbiamo presi e buttati dentro cecamente, e adesso 
> aggiungiamo anche altro di questa qualità? Per me no.
> Sembra il db MISE sia un db come il nostro (UGC), solo che la gente che ci 
> contribuisce sembra lo faccia per dovere e non per piacere  ;-)  e 
> apparentemente non ci sta nessuno che mette ordine ;-)
>

Vero, già è stato fatto abbastanza :)

Ciao,
Federico

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

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

2018-09-14 15:45 GMT+02:00 Carmine Massarelli <
carmine.massare...@ba.irsa.cnr.it>:

> Che ne pensate se inserissimo anche gli orari?
> E' ancora valida questa autorizzazione? https://wiki.openstreetmap.org
> /wiki/Importazione_distributori_metano



io mi fermerei con l'import. Troviamo errori su errori e non abbiamo
nemmeno visto la meta dei dati che abbiamo presi e buttati dentro
cecamente, e adesso aggiungiamo anche altro di questa qualità? Per me no.
Sembra il db MISE sia un db come il nostro (UGC), solo che la gente che ci
contribuisce sembra lo faccia per dovere e non per piacere  ;-)  e
apparentemente non ci sta nessuno che mette ordine ;-)

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

Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary

[djakk djakk]

Oui j’ai été complètement cavalier dans ma manière de faire ! Cela me
travaille à chaque fois que je regarde une carte osm :)
C’est pas comme si la situation précédente était satisfaisante: il y avait
de nombreuses guerres d’édition car la définition FR était ambiguë.
Je serai très attentif à mes messages privés sur osm et au “revert”, je ne
partirai pas dans des guerres d’édition, je verrai qui est “chaud” sur le
sujet. (Car si pas de réponse sur la mailing-list, c’est que personne n’est
intéressé par le sujet ... sur la mailing-list mais tout le monde n’est pas
sur la ML !)

djakk


Le ven. 14 sept. 2018 à 11:31, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> oui en effet @Axelos   Dans ce cas j'avoue que ça
> aurait une utilité. Sachant que c'est comme un raccourci une voie à 110
> permet l'accès au véhicule agricoles que le permet pas les voies avec
> panneau C107. C'est là tous le problème. On se retrouve donc avec des
> panneaux pour autoriser les engin agricole à rouler...
>
> Les routes pour automobile impose le même mode de fonctionnement q'une
> autoroute. Les trunck en France ont été défini sur une logique de vitesse
> en sur le fait d'avoir au moins de voies séparé par terre-plein central...
>
> Bref ça fait bien longtemps que l'on discute de définir un modèle
> présentant des exemples de cas pour définir des logiques (interurbaines ou
> extraurbaines) mais faire un tableau et le valider en ayant l'accord de la
> plus part n'est pas simple.
>
> On doit bien pouvoir identifier des cas où cela est utile de choisir un
> certains type de clé. Sans devoir uniquement se baser sur un référentiel où
> la volonté d'une commune à monter qu'une voie est un axe majeur quand ce
> n'est pas le cas.
>
> A défaut d'explications clair et d'une logique bien défini on se retrouve
> à voir tout et son contraire...
>
> Si l'on veut améliorer ce système il faudrait encore en définir un modèle
> plus clair (ne serait ce que pour notre territoire) car ce sujet revient
> sans cesse sans y répondre ou avec des réponse complètement contraire.
>
> Ce travail a déjà été initié mais sans aboutir il me semble car la
> priorité avait été donner pour compléter les voies manquante et adjoindre
> les noms pour le projet BANO. Maintenant, c'est classification ont deux
> objectifs:
> - le routing
> - l'accessibilité
>
> La base ne sert pas à définir une logique de règlementaire (sinon c'est
> une autre clé)
>
> Si l'on veut aussi définir des règles pour choisir comment taguer les
> voies non classifiées et les chemins et voie de service.
> Pour les chemins je crois que réglementairement il n'y a pas lieux d'y
> mettre des panneaux de sortie et entrée de ville.
> Merci de me confirmer ce sujet si vous en avait l'occassion.
>
> Que voulons nous et quelles limites on y met?
> Bonne journée.
>
>
> Le jeu. 13 sept. 2018 à 19:44, Axelos  a écrit :
>
>> Le 13/09/2018 à 16:03, Christian Rogel a écrit :
>> >> Le 12 sept. 2018 à 20:10, JB  a écrit :
>> >>
>> >> Pas de réponse = accord de tous ? Je pense plutôt l'inverse. Le sujet
>> a été discuté, rediscuté plusieurs et encore plusieurs fois ces dernières
>> années. Tu as tenté de relancer la discussion sans grande réussite il y a
>> quelques mois, si je ne me trompe pas. Ça n'a pas l'air de prendre cette
>> fois-ci non-plus. Laisser les choses telles qu'elles sont, ce qui semble le
>> compromis le plus stable ou au mieux le moins bancal, t'empêchera-t-il
>> de dormir tranquille ?
>> >> Je pense que le panier de crabes est mieux ainsi, en équilibre, que si
>> on le retourne une fois encore. Je pense que tu risques de te frotter à des
>> résistances locales à plusieurs endroits, à des conflits d'éditions, qui
>> montent parfois vite en tension lorsque la modification est faite par des
>> contributeurs distants. Es-tu sûr que le jeu en vaille la chandelle ?
>> >> JB.
>> >>
>> >> Le 12/09/2018 à 12:59, djakk djakk a écrit :
>> >>> Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je
>> réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies
>> en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et
>> d’autres cas)
>> >>>
>> >>> djakk
>> >>>
>> >>>
>> >>> Le lun. 10 sept. 2018 à 19:49, djakk djakk > > a écrit :
>> >>> Coucou !
>> >>>
>> >>> Je reviens sur cette histoire de highway=trunk qui diffère selon les
>> pays.
>> >>>
>> >>> Je pense qu’il est important d’avoir pour chaque clé-valeur une
>> définition commune au monde entier (autant que possible ) et qu’un 5e
>> niveau dans la hiérarchie des “highways”
>> >>> serait souhaitable : residential/unclassified - tertiary - secondary
>> - primary - trunk.
>> >>>
>> >>> Du coup, il s’agirait de reprendre pour la France le classement
>> anglais des highways, où le trunk désigne une super-route pas forcément de
>> type autoroutier.
>> >>>
>> >>> Par exemple pour différencier la N12 et la D31 à Ernée (
>> >>> 

[OSM-talk-fr] Les bretelles

[djakk djakk]

Salut !

Une autre chose me tarabusce au sujet des routes dans osm, c’est l’absence
d’info sur le type de route joint par une bretelle (highway=*_link),
c’est-à-dire qu’on sait qu’une bretelle joint une autoroute mais on n’a pas
d’info sur l’autre côté ! Primary, secondary ? On ne sait pas directement.

Et je trouve cette information plus importante. En effet, si on relie une
autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on
pourrait choisir au niveau du rendu de ne pas afficher la bretelle.
Impossible en l’état actuel.

Du coup je propose link_from et link_to : pour une bretelle dans le sens
autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary.

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

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Paulo Carvalho]

Oi, Sérgio, vamos lá...

Em sex, 14 de set de 2018 às 12:25, Sérgio V.  escreveu:

> Bom dia Paulo, pessoal.
>
> Fiz upscaling pra ver crossplot/scatterplot, com 549x549 px =   301.401
> pixels (pontos);
>  - Imagem original tava com 10.980x10.980 px = 120.560.400 pixels :
> 120.560.400 pontos, inviável, processador e RAM assobiaram.
>

Perfeito. Não se faz análise exploratória dos dados com tantos pontos. 120M
de amostras é impossível mesmo.  E mesmo se fosse viável, daria para ver
pouco.


> E abri os histogramas.
>
> Obtive os seguintes gráficos (em jpg no Imgur):
>
> Histograma B11 : https://i.imgur.com/jsvnFjj.jpg
>

Só B11 parece dizer que há duas classes (as duas modas em 1200 e 2000
aproximadamente).  Não obstante um tanto misturadas.  Mas outra variável
pode ajudar a desempatar.


> Histograma NDVI : https://i.imgur.com/FrEZGOO.jpg
>
NDVI parece dizer que há três classes (as modas em 0,2; 0,6 e 0,7).  A
classe em centrada em 0,2 parece bem separada.


> Histograma (1-NDVI)*4000 : https://i.imgur.com/TUPi3Tl.jpg
>

Não percas tempo com isso.  Apenas mudou a escala.  Ela continuia
informando a mesma coisa: que parece haver três classes.


>
> Scatterplot B11 x NDVI : https://i.imgur.com/z4yPjtY.jpg
> Scatterplot B11 x (1-NDVI)*4000 : https://i.imgur.com/j4WuO7C.jpg
>

Parece interessante, porém só aparece uma mancha negra.  Seria importante
vermos onde os pontos estão concentrados.  Pontos concentrados são indícios
de que há uma classe ali.  Há como definir a marca do crossplot para um
único pixel?  Se não for possível, tenta reduzir a quantidade de amostras
de ~100k para ~5k.

abcs,

PC


> (c/ reescale para abranger próximo da área plotada.)
>
> Anomalias de pixels acho que não tem muito.
> Nuvem já remove na escolha de imagem, por cloud=0. E verifica com B10 se
> ainda tem alguma mínima.
>
> A questão acho que centraria em encontrar uma referência de base universal
> (imagem original básica; ou algoritmo) para wood e forest, ou wood sozinho:
> B11 sozinho ?
> NDVI; ou EVI2; sozinhoS ?
> Fórmula empírica (podem chamar gambiarra tb) tipo B11 * (1-NDVI)*4000 ?
> Algum algoritmo mais pato (depois ainda vou estudar os algoritmos de
> classificação multivariados que vc indicou).
> De todo modo, a base da classificação, e possibilidade de
> mapeamento, parte de imagem original e/ou índices mais aptos.
>
> O objetivo a princípio é prático, para o OSM, não tanto científico:
> distinguir 2 classes, wood e forest, com precisão adequada, bastaria.
>
> NDVI e EVI2 exibem imagens muito parecidas; EVI2 indicam que é melhor pra
> mata densa.
> Mas comecei usando o NDVI, só pra eliminar o que não é vegetação; não pra
> fazer classe de vegetação, pois não encontrei valores limite aptos a
> separar classes.
>
> O que o o (1-NDVI) faz é tornar NDVI tudo número positivo, pra poder
> depois multiplicar(potencializar) o B11.
>
> Vi que O NDVI possibilita destacar tudo o que não é vegetação, e remover
> objetos que poderiam ainda ficar misturado no B11; por ter o foco em mapear
> matas.
> O B11 foi que observei de imediato que mais destaca "wood" e "forest"
> entre si. Mas wood é o que mais tem no Brasil. Forest, menos.
>
> Aí no B11, filtrado pelo x (1-NDVI)*4000, era só ver o range, só entre as
> 2, porque o resto já fica separado pelo NDVI.
> (se focar só nas 2, wood e forest; no resto do Brasil quase só wood,
> natural; mas se quiser todo o resto de landcover, mais classes, aí fica
> mais elementos a considerar; também dá, mas de preferência não abordaria
> isso agora):
> -forest (vegetaçao mais nova; mais escura; valores mais baixos)
> -wood (vegetação mais velha, mais clara, valores mais altos)
> E as anomalias (amplificação de anomalias), filtrando manual com "sieve" e
> "neighbors".
> O fato é que o resultado, filtrando, mesmo perdendo informação, aproximou
> da real grupo de wood e forest no terreno.
>
> Este que seria o objetivo: pegar wood e forest, quando há as 2
> co-existindo; separadas entre si, e de todo o resto que não é.
> Quando "não" tem as 2 co-existindo numa região (florestas plantadas é mais
> na região Sul-Sudeste do BR), pegar só mata nativa (wood).
> Alcançando isto, tá feito para o objetivo inicial e prático!
> Claro, ainda se poderia ir tentando encontrar uma formulação que possa ser
> mais abrangente, pegar mais objetos de landcover.
>
> Bom, a ver o que acham.
> Em investigação. Parcialmente já estou satisfeito com os resultados. O
> modo ainda pode ser meio empírico, ou não muito científico, artístico
> digamos, de ir lapidando até fechar os polígonos de classes iguais, mas
> funcionou. Claro, se pudermos facilitar e universalizar, melhor.
>
> Obrigado pelos aportes já dados!
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
>
> --
> *De:* Paulo Carvalho 
> *Enviado:* quinta-feira, 13 de setembro de 2018 14:05
> *Para:* OSM talk-br
> *Assunto:* Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2
>
>
>
> Em qui, 

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Bom dia Paulo, pessoal.

Fiz upscaling pra ver crossplot/scatterplot, com 549x549 px =   301.401 pixels 
(pontos);
 - Imagem original tava com 10.980x10.980 px = 120.560.400 pixels : 120.560.400 
pontos, inviável, processador e RAM assobiaram.
E abri os histogramas.

Obtive os seguintes gráficos (em jpg no Imgur):

Histograma B11 : https://i.imgur.com/jsvnFjj.jpg
Histograma NDVI : https://i.imgur.com/FrEZGOO.jpg
Histograma (1-NDVI)*4000 : https://i.imgur.com/TUPi3Tl.jpg

Scatterplot B11 x NDVI : https://i.imgur.com/z4yPjtY.jpg
Scatterplot B11 x (1-NDVI)*4000 : https://i.imgur.com/j4WuO7C.jpg
(c/ reescale para abranger próximo da área plotada.)

Anomalias de pixels acho que não tem muito.
Nuvem já remove na escolha de imagem, por cloud=0. E verifica com B10 se ainda 
tem alguma mínima.

A questão acho que centraria em encontrar uma referência de base universal 
(imagem original básica; ou algoritmo) para wood e forest, ou wood sozinho:
B11 sozinho ?
NDVI; ou EVI2; sozinhoS ?
Fórmula empírica (podem chamar gambiarra tb) tipo B11 * (1-NDVI)*4000 ?
Algum algoritmo mais pato (depois ainda vou estudar os algoritmos de 
classificação multivariados que vc indicou).
De todo modo, a base da classificação, e possibilidade de mapeamento, parte de 
imagem original e/ou índices mais aptos.

O objetivo a princípio é prático, para o OSM, não tanto científico: distinguir 
2 classes, wood e forest, com precisão adequada, bastaria.

NDVI e EVI2 exibem imagens muito parecidas; EVI2 indicam que é melhor pra mata 
densa.
Mas comecei usando o NDVI, só pra eliminar o que não é vegetação; não pra fazer 
classe de vegetação, pois não encontrei valores limite aptos a separar classes.

O que o o (1-NDVI) faz é tornar NDVI tudo número positivo, pra poder depois 
multiplicar(potencializar) o B11.

Vi que O NDVI possibilita destacar tudo o que não é vegetação, e remover 
objetos que poderiam ainda ficar misturado no B11; por ter o foco em mapear 
matas.
O B11 foi que observei de imediato que mais destaca "wood" e "forest" entre si. 
Mas wood é o que mais tem no Brasil. Forest, menos.

Aí no B11, filtrado pelo x (1-NDVI)*4000, era só ver o range, só entre as 2, 
porque o resto já fica separado pelo NDVI.
(se focar só nas 2, wood e forest; no resto do Brasil quase só wood, natural; 
mas se quiser todo o resto de landcover, mais classes, aí fica mais elementos a 
considerar; também dá, mas de preferência não abordaria isso agora):
-forest (vegetaçao mais nova; mais escura; valores mais baixos)
-wood (vegetação mais velha, mais clara, valores mais altos)
E as anomalias (amplificação de anomalias), filtrando manual com "sieve" e 
"neighbors".
O fato é que o resultado, filtrando, mesmo perdendo informação, aproximou da 
real grupo de wood e forest no terreno.

Este que seria o objetivo: pegar wood e forest, quando há as 2 co-existindo; 
separadas entre si, e de todo o resto que não é.
Quando "não" tem as 2 co-existindo numa região (florestas plantadas é mais na 
região Sul-Sudeste do BR), pegar só mata nativa (wood).
Alcançando isto, tá feito para o objetivo inicial e prático!
Claro, ainda se poderia ir tentando encontrar uma formulação que possa ser mais 
abrangente, pegar mais objetos de landcover.

Bom, a ver o que acham.
Em investigação. Parcialmente já estou satisfeito com os resultados. O modo 
ainda pode ser meio empírico, ou não muito científico, artístico digamos, de ir 
lapidando até fechar os polígonos de classes iguais, mas funcionou. Claro, se 
pudermos facilitar e universalizar, melhor.

Obrigado pelos aportes já dados!



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: quinta-feira, 13 de setembro de 2018 14:05
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2



Em qui, 13 de set de 2018 às 13:08, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Bom dia pessoal, Paulo e Gerald, obrigado pelos aportes!
Tenho muito interesse em que se possa aprimorar o processo, e/ou facilitar, 
onde possível e necessário.
-Gerald, baixei o artigo, vou olhar mais a fundo, exigirá mais tempo.
-Paulo, infelizmente não apareceu a imagem exemplo que vc enviou, o talk-list 
não exibe imagem, só link. Se puder mandar em link (tipo 
imgur.com:  https://i.imgur.com/n3LV9qJ.jpg), seria ótimo.

Sem figuras?  Precisamos sair da década de 1990!  Aqui, é a figura 11 desse 
artigo: 
https://www.researchgate.net/publication/249553119_Optimizing_4D_fluid_imaging


Estou tomando muito em consideração as suas colocações técnicas.

Claro, quando cruzei B11+((1-NDVI)*4000), o objetivo foi arrastar pra fora tudo 
que não é mata, na Mata Altlâtica.Serviu ali.

Ok.

Não serviu nos outros biomas. Foquei só em forest e wood. Que já me pareceu bem 
identificável pelo B11, só que no B11 mistura perto de valores de água, e é 
mais afetado por sombra. Por isso a de filtra pelo NDVI o que não é matas. Usei 
só B11 e NDV( 

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Jo]

Maintenant que l'on parle de rotondes et les chemins en fourche, qu'est-ce
que vous pensez de ceci:

https://www.youtube.com/watch?v=CsFew4jVuWQ

Je l'ai développé comme prototype en Python et il ne fonctionne pas encore
comme il faut quand il y a une piste cyclable autour de la rotonde, mais
j'aimerais savoir si ça vous paraît utile si ajouté au PT_Assistant.

Le code source est ici:
https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python

Jo

Op vr 14 sep. 2018 om 15:57 schreef Rpnpif :

> Le 14 septembre 2018, Sébastien Dinot a écrit :
>
> > Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas
> nécessaire, qu'on pouvait intégrer le rond-point en entier dans la
> relation. Pour le coup, d'un point de vue topologique, c'est surprenant,
> mais si les outils de routage s'en sortent, ça me va tout aussi bien
> sachant que la tâche est alors grandement facilitée (et que j'ai repéré
> d'autres « mini_roundabout » tout aussi complexes à corriger).
>
> Bonjour,
>
> Je pense aussi que c'est la meilleure solution.
>
> Même si ce n'est pas courant, faire attention aussi aux relations
> "interdiction de tourner" à gauche ou à droite. Elles coupent les
> cheminements, tronçonnant ainsi les ronds-points. Mais, je répète c'est
> rare sur un rond-point.
>
> --
> Alain Rpnpif
>
> ___
> 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] Numéro de tuile ?

[Rpnpif]

Le 14 septembre 2018, marc marc a écrit :

> dans FF : F12, console réseau, rafraichir la page, tu as alors la liste 
> des urls de toute les tuiles.

Console réseau,puis cliquer sur le bouton Images.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Rpnpif]

Le 14 septembre 2018, Sébastien Dinot a écrit :

> Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas 
> nécessaire, qu'on pouvait intégrer le rond-point en entier dans la relation. 
> Pour le coup, d'un point de vue topologique, c'est surprenant, mais si les 
> outils de routage s'en sortent, ça me va tout aussi bien sachant que la tâche 
> est alors grandement facilitée (et que j'ai repéré d'autres « mini_roundabout 
> » tout aussi complexes à corriger).

Bonjour,

Je pense aussi que c'est la meilleure solution.

Même si ce n'est pas courant, faire attention aussi aux relations
"interdiction de tourner" à gauche ou à droite. Elles coupent les
cheminements, tronçonnant ainsi les ronds-points. Mais, je répète c'est
rare sur un rond-point.

-- 
Alain Rpnpif

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

[Talk-it] dataset MISE distributori

[Carmine Massarelli]

Che ne pensate se inserissimo anche gli orari?
E' ancora valida questa autorizzazione? 
https://wiki.openstreetmap.org/wiki/Importazione_distributori_metano


Carmine

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

[OSM-talk-be] moped_*=* tag on the border relation with France

[Jakka]

Hi,

Must this be adapted and who can do this ?
Possible on other border Relation to ?

Where did I see it.
detail border Menen.
https://www.openstreetmap.org/#map=22/50.78637416053381/3.1269890021261264
see relation "default Belgium, Flanders, highway default values 1 lid"
relation 6900538
def:highway=cycleway;access:moped_a:conditional
def:highway=cycleway;access:moped_b:conditional

-was missing --> moped_P
-capital letter or not ??? _A or _a; _B or_b; _P or_p

https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Belgium
see notes:
moped in Belgium actually comprises three vehicle classes: "moped_A", 
"moped_B" and "moped_P", cycleways may allow any combination of them 
(including none at all), depending on the signs used, and the road the 
cycleway belongs to.

use in Belgium:
capitalletter
http://overpass-turbo.eu/s/BSF
versus lowercase
http://overpass-turbo.eu/s/BSG


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

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Jo]

Je suis toujours disponible pour faire un Google Hangout. Ça fait déjà un
bon moment (été 2017) que je considère de faire des Hangout en ligne avec
pour sujet le transport en commun. J'avoue que les seuls villes où j'ai été
en France sont Caen, Strasbourg, Dunkerque et Avignon. Paris aussi, mais je
ne me rappelle plus si j'ai déjà cartographié des lignes de bus là-bas.

Pour les autres villes je me base sur l'existant et je 'répare' les
interruptions dans les itinéraires, ou les chemins empruntés en contresens
de sens unique.

Je dois regarder le greffon reltoolbox que tu mentionnes. Pour l'instant
PT_Assistant ne s'occupe pas de relations route_master ni des noms données
aux itinéraires. Ici en Belgique j'avais créé des scripts python qui
génèrent ces noms et les relations route_master basé sur les données des
opérateurs. Les relations route aussi, avec tous les arrêts dedans dans la
bonne ordre.

Cet été l'idée était d'avoir un projet pour un site Django qui ferait
quelque chose de comparable pour les données GTFS, mais le projet a échoué,
malheureusement.

Jo

Op vr 14 sep. 2018 om 14:07 schreef Jérôme Seigneuret <
jerome.seigneu...@gmail.com>:

> Pour revenir dessus, si tu es toujours sur Montpellier on peut faire un
> sujet là dessus en réunion OSM ou ailleurs. Pur le reste sous JOSM comme tu
> le site il y a un plugin indispensable pour exploiter les relations
> proporement* reltoolbox *et une feuille de style dédié. On dévie un peu
> du sujet initial mais le but et de faire une super relation pour les lignes
> et de faire des relation pour les itinéraire A > B; B < C; A > C ... les
> lettres restes les points terminaux. J'ai aussi initié le travail de
> conversion mais j'ai pas pris le temps de le finir. Autant dire que c'est
> pas d'aujourd'hui
> https://www.openstreetmap.org/user/jseigneuret/diary/35497
>
> Le ven. 14 sept. 2018 à 12:03, Jo  a écrit :
>
>> C'est vrai, à Montpellier j'ai pris "trop de foin sur ma fourchette". J'y
>> ai commencé avec beaucoup de volonté, mais c'était échec total et après une
>> semaine j'ai abandonné. Trop de conflits d'édtion. Il ne m'est toujours pas
>> claire vers quel système on veut aller là-bas. Si c'est d'avoir des NOEUDS
>>
>> highway=bus_stop
>> public_transport=platform
>> bus=yes
>>
>> ou
>>
>> railway=tram_stop
>> public_transport=platform
>> tram=yes
>>
>> je veux bien aider avec la conversion.
>>
>> Si c'est pour finir avec des noeuds
>> public_transport=stop_position
>>
>> et des WAYS
>>
>> public_transport=platform
>>
>> j'abandonne.
>>
>> Il ne m'est toujours pas clair quel est le but et quoi faire des noeuds
>>
>> public_transport=pole
>>
>> Mais bon, une des choses que je fais également c'est de découper les
>> rotondes et ce n'est pas apprécié, donc il est probablement mieux que je
>> vais quelque part d'autre.
>>
>> Pour les rendre 'fermés' (avec JOSM):
>>
>> Ctrl-f
>> "junction=roundabout inview"
>> c
>>
>> Jo
>>
>>
>>
>> Op vr 14 sep. 2018 om 11:05 schreef Jérôme Seigneuret <
>> jerome.seigneu...@gmail.com>:
>>
>>> Salut,
>>> Pour faire simple, Quand tu crées des relations pour les itinéraires
>>> (exemple transport en commun en bus) et éviter d’annoncer que tu fais le
>>> tour du rond-point quand c'est pas le cas.
>>>
>>> Après il faut faire ça correctement.
>>>
>>>
>>> https://www.openstreetmap.org/search?query=montpellier#map=19/43.61322/3.85909=T
>>>
>>> Ici c'est un cas typique de découpe sans que les tronçons soit mis à
>>> jour dans la relation.
>>>
>>> Bonne journée
>>>
>>> Le ven. 14 sept. 2018 à 09:10, Jo  a écrit :
>>>

 Op vr 14 sep. 2018 om 09:05 schreef Sébastien Dinot <
 sebastien.di...@free.fr>:

> Bonjour,
>
> - Mail original -
> > Pas forcement, moi-même j'ai commencé à représenter des itinéraires
> > de bus en découpant les giratoires, tout simplement car cela m'a
> > semblé plus logique ainsi.
> > Le but étant de retranscrire le cheminement du bus.
>
> Idem.
>
> > Bon ensuite j'ai compris que la pratique veut que l'on découpe pas
> > les giratoires, je me suis adapté et en effet c'est plus simple à
> > gérer ainsi.
>
> Idem.
>
> Il se trouve qu'en début de semaine, j'ai passé un long moment à
> transformer un « mini_roundabout » sur lequel venaient se greffaient 4
> voies simples en « roundabout » (ce qu'il était clairement) avec les
> jonctions en Y. Mon problème n'avait pas été la création du rond-point et
> des axes en eux-mêmes, mais le découpage du rond-point et la modification
> des nombreux trajets de bus qui passaient par ce rond-point en m'assurant
> qu'au final, je n'avais cassé aucune relation.
>
> Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas
> nécessaire, qu'on pouvait intégrer le rond-point en entier dans la
> relation. Pour le coup, d'un point de vue topologique, c'est surprenant,
> mais si les outils de routage s'en sortent, ça me va tout aussi bien

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Jérôme Seigneuret]

Pour revenir dessus, si tu es toujours sur Montpellier on peut faire un
sujet là dessus en réunion OSM ou ailleurs. Pur le reste sous JOSM comme tu
le site il y a un plugin indispensable pour exploiter les relations
proporement* reltoolbox *et une feuille de style dédié. On dévie un peu du
sujet initial mais le but et de faire une super relation pour les lignes et
de faire des relation pour les itinéraire A > B; B < C; A > C ... les
lettres restes les points terminaux. J'ai aussi initié le travail de
conversion mais j'ai pas pris le temps de le finir. Autant dire que c'est
pas d'aujourd'hui https://www.openstreetmap.org/user/jseigneuret/diary/35497

Le ven. 14 sept. 2018 à 12:03, Jo  a écrit :

> C'est vrai, à Montpellier j'ai pris "trop de foin sur ma fourchette". J'y
> ai commencé avec beaucoup de volonté, mais c'était échec total et après une
> semaine j'ai abandonné. Trop de conflits d'édtion. Il ne m'est toujours pas
> claire vers quel système on veut aller là-bas. Si c'est d'avoir des NOEUDS
>
> highway=bus_stop
> public_transport=platform
> bus=yes
>
> ou
>
> railway=tram_stop
> public_transport=platform
> tram=yes
>
> je veux bien aider avec la conversion.
>
> Si c'est pour finir avec des noeuds
> public_transport=stop_position
>
> et des WAYS
>
> public_transport=platform
>
> j'abandonne.
>
> Il ne m'est toujours pas clair quel est le but et quoi faire des noeuds
>
> public_transport=pole
>
> Mais bon, une des choses que je fais également c'est de découper les
> rotondes et ce n'est pas apprécié, donc il est probablement mieux que je
> vais quelque part d'autre.
>
> Pour les rendre 'fermés' (avec JOSM):
>
> Ctrl-f
> "junction=roundabout inview"
> c
>
> Jo
>
>
>
> Op vr 14 sep. 2018 om 11:05 schreef Jérôme Seigneuret <
> jerome.seigneu...@gmail.com>:
>
>> Salut,
>> Pour faire simple, Quand tu crées des relations pour les itinéraires
>> (exemple transport en commun en bus) et éviter d’annoncer que tu fais le
>> tour du rond-point quand c'est pas le cas.
>>
>> Après il faut faire ça correctement.
>>
>>
>> https://www.openstreetmap.org/search?query=montpellier#map=19/43.61322/3.85909=T
>>
>> Ici c'est un cas typique de découpe sans que les tronçons soit mis à jour
>> dans la relation.
>>
>> Bonne journée
>>
>> Le ven. 14 sept. 2018 à 09:10, Jo  a écrit :
>>
>>>
>>> Op vr 14 sep. 2018 om 09:05 schreef Sébastien Dinot <
>>> sebastien.di...@free.fr>:
>>>
 Bonjour,

 - Mail original -
 > Pas forcement, moi-même j'ai commencé à représenter des itinéraires
 > de bus en découpant les giratoires, tout simplement car cela m'a
 > semblé plus logique ainsi.
 > Le but étant de retranscrire le cheminement du bus.

 Idem.

 > Bon ensuite j'ai compris que la pratique veut que l'on découpe pas
 > les giratoires, je me suis adapté et en effet c'est plus simple à
 > gérer ainsi.

 Idem.

 Il se trouve qu'en début de semaine, j'ai passé un long moment à
 transformer un « mini_roundabout » sur lequel venaient se greffaient 4
 voies simples en « roundabout » (ce qu'il était clairement) avec les
 jonctions en Y. Mon problème n'avait pas été la création du rond-point et
 des axes en eux-mêmes, mais le découpage du rond-point et la modification
 des nombreux trajets de bus qui passaient par ce rond-point en m'assurant
 qu'au final, je n'avais cassé aucune relation.

 Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas
 nécessaire, qu'on pouvait intégrer le rond-point en entier dans la
 relation. Pour le coup, d'un point de vue topologique, c'est surprenant,
 mais si les outils de routage s'en sortent, ça me va tout aussi bien
 sachant que la tâche est alors grandement facilitée (et que j'ai repéré
 d'autres « mini_roundabout » tout aussi complexes à corriger).

>>>
>>> Je veux bien vous démontrer que cette tache est rendu triviale avec le
>>> greffon PT_Assistant.
>>>
>>> Polyglot
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>>
>

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

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[David Crochet]

Bonjour

Avant on intégrer l'emprise  au sol d'un ensemble de bâtiment
Maintenant on indique l'emprise au sol de chaque structure d'un ensemble 
de bâtiment pour individualiser la définition jusqu'à son adresse 
adminsitrative

Ensuite on modifiera les éléments pour y intégrer les élément 3D

Avant on intégrait une représentation linéaire des voies  ferrée quels 
que soit le nombre de voies de circulation
maintenant on définit les relations et les voies telles qu'elles 
existent dans la réalité avec la signalisation afférente



Et pour ma part les giratoires, c'est pareil. Je définie la réalité du 
terrain, et donc du parcours de la ligne de transport en commun comme tel.


Cordialement

--

David Crochet


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

Re: [Talk-es] Gestor de Tareas

[Rafael Avila Coya]

Gracias, Alejandro, por el trabajo de mantenimiento del Gestor de Tareas,

Un saludo,

Rafael.

On 13/09/18 18:38, Alejandro S. wrote:

Ya vuelve a funcionar.


Atentamente,
   Alejandro Suárez


On Wed, 12 Sep 2018 at 20:01, dcapillae > wrote:


Hola.

No me es posible acceder al gestor de tareas. El navegador me
devuelve un
mensaje de error informando de que no es posible establecer conexión
con el
servidor. Ocurre desde el día de ayer (2018-09-12) al menos. Imagino
que no
soy el único que tiene esta misma incidencia.

Quedo a la espera de que se solucione o de que alguien con más
conocimientos
pueda informarnos del problema. Hay varios proyectos de importación
en curso
y dependemos del buen funcionamiento del gestor de tareas.

Gracias por vuestra colaboración.




-
Daniel Capilla
OSM user: dcapillae
--
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] Rond-points à la découpe. Pourquoi ?

[Jo]

C'est vrai, à Montpellier j'ai pris "trop de foin sur ma fourchette". J'y
ai commencé avec beaucoup de volonté, mais c'était échec total et après une
semaine j'ai abandonné. Trop de conflits d'édtion. Il ne m'est toujours pas
claire vers quel système on veut aller là-bas. Si c'est d'avoir des NOEUDS

highway=bus_stop
public_transport=platform
bus=yes

ou

railway=tram_stop
public_transport=platform
tram=yes

je veux bien aider avec la conversion.

Si c'est pour finir avec des noeuds
public_transport=stop_position

et des WAYS

public_transport=platform

j'abandonne.

Il ne m'est toujours pas clair quel est le but et quoi faire des noeuds

public_transport=pole

Mais bon, une des choses que je fais également c'est de découper les
rotondes et ce n'est pas apprécié, donc il est probablement mieux que je
vais quelque part d'autre.

Pour les rendre 'fermés' (avec JOSM):

Ctrl-f
"junction=roundabout inview"
c

Jo



Op vr 14 sep. 2018 om 11:05 schreef Jérôme Seigneuret <
jerome.seigneu...@gmail.com>:

> Salut,
> Pour faire simple, Quand tu crées des relations pour les itinéraires
> (exemple transport en commun en bus) et éviter d’annoncer que tu fais le
> tour du rond-point quand c'est pas le cas.
>
> Après il faut faire ça correctement.
>
>
> https://www.openstreetmap.org/search?query=montpellier#map=19/43.61322/3.85909=T
>
> Ici c'est un cas typique de découpe sans que les tronçons soit mis à jour
> dans la relation.
>
> Bonne journée
>
> Le ven. 14 sept. 2018 à 09:10, Jo  a écrit :
>
>>
>> Op vr 14 sep. 2018 om 09:05 schreef Sébastien Dinot <
>> sebastien.di...@free.fr>:
>>
>>> Bonjour,
>>>
>>> - Mail original -
>>> > Pas forcement, moi-même j'ai commencé à représenter des itinéraires
>>> > de bus en découpant les giratoires, tout simplement car cela m'a
>>> > semblé plus logique ainsi.
>>> > Le but étant de retranscrire le cheminement du bus.
>>>
>>> Idem.
>>>
>>> > Bon ensuite j'ai compris que la pratique veut que l'on découpe pas
>>> > les giratoires, je me suis adapté et en effet c'est plus simple à
>>> > gérer ainsi.
>>>
>>> Idem.
>>>
>>> Il se trouve qu'en début de semaine, j'ai passé un long moment à
>>> transformer un « mini_roundabout » sur lequel venaient se greffaient 4
>>> voies simples en « roundabout » (ce qu'il était clairement) avec les
>>> jonctions en Y. Mon problème n'avait pas été la création du rond-point et
>>> des axes en eux-mêmes, mais le découpage du rond-point et la modification
>>> des nombreux trajets de bus qui passaient par ce rond-point en m'assurant
>>> qu'au final, je n'avais cassé aucune relation.
>>>
>>> Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas
>>> nécessaire, qu'on pouvait intégrer le rond-point en entier dans la
>>> relation. Pour le coup, d'un point de vue topologique, c'est surprenant,
>>> mais si les outils de routage s'en sortent, ça me va tout aussi bien
>>> sachant que la tâche est alors grandement facilitée (et que j'ai repéré
>>> d'autres « mini_roundabout » tout aussi complexes à corriger).
>>>
>>
>> Je veux bien vous démontrer que cette tache est rendu triviale avec le
>> greffon PT_Assistant.
>>
>> Polyglot
>> ___
>> 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

Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary

[Jérôme Seigneuret]

oui en effet @Axelos   Dans ce cas j'avoue que ça aurait
une utilité. Sachant que c'est comme un raccourci une voie à 110 permet
l'accès au véhicule agricoles que le permet pas les voies avec panneau
C107. C'est là tous le problème. On se retrouve donc avec des panneaux pour
autoriser les engin agricole à rouler...

Les routes pour automobile impose le même mode de fonctionnement q'une
autoroute. Les trunck en France ont été défini sur une logique de vitesse
en sur le fait d'avoir au moins de voies séparé par terre-plein central...

Bref ça fait bien longtemps que l'on discute de définir un modèle
présentant des exemples de cas pour définir des logiques (interurbaines ou
extraurbaines) mais faire un tableau et le valider en ayant l'accord de la
plus part n'est pas simple.

On doit bien pouvoir identifier des cas où cela est utile de choisir un
certains type de clé. Sans devoir uniquement se baser sur un référentiel où
la volonté d'une commune à monter qu'une voie est un axe majeur quand ce
n'est pas le cas.

A défaut d'explications clair et d'une logique bien défini on se retrouve à
voir tout et son contraire...

Si l'on veut améliorer ce système il faudrait encore en définir un modèle
plus clair (ne serait ce que pour notre territoire) car ce sujet revient
sans cesse sans y répondre ou avec des réponse complètement contraire.

Ce travail a déjà été initié mais sans aboutir il me semble car la priorité
avait été donner pour compléter les voies manquante et adjoindre les noms
pour le projet BANO. Maintenant, c'est classification ont deux objectifs:
- le routing
- l'accessibilité

La base ne sert pas à définir une logique de règlementaire (sinon c'est une
autre clé)

Si l'on veut aussi définir des règles pour choisir comment taguer les voies
non classifiées et les chemins et voie de service.
Pour les chemins je crois que réglementairement il n'y a pas lieux d'y
mettre des panneaux de sortie et entrée de ville.
Merci de me confirmer ce sujet si vous en avait l'occassion.

Que voulons nous et quelles limites on y met?
Bonne journée.


Le jeu. 13 sept. 2018 à 19:44, Axelos  a écrit :

> Le 13/09/2018 à 16:03, Christian Rogel a écrit :
> >> Le 12 sept. 2018 à 20:10, JB  a écrit :
> >>
> >> Pas de réponse = accord de tous ? Je pense plutôt l'inverse. Le sujet a
> été discuté, rediscuté plusieurs et encore plusieurs fois ces dernières
> années. Tu as tenté de relancer la discussion sans grande réussite il y a
> quelques mois, si je ne me trompe pas. Ça n'a pas l'air de prendre cette
> fois-ci non-plus. Laisser les choses telles qu'elles sont, ce qui semble le
> compromis le plus stable ou au mieux le moins bancal, t'empêchera-t-il
> de dormir tranquille ?
> >> Je pense que le panier de crabes est mieux ainsi, en équilibre, que si
> on le retourne une fois encore. Je pense que tu risques de te frotter à des
> résistances locales à plusieurs endroits, à des conflits d'éditions, qui
> montent parfois vite en tension lorsque la modification est faite par des
> contributeurs distants. Es-tu sûr que le jeu en vaille la chandelle ?
> >> JB.
> >>
> >> Le 12/09/2018 à 12:59, djakk djakk a écrit :
> >>> Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je
> réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies
> en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et
> d’autres cas)
> >>>
> >>> djakk
> >>>
> >>>
> >>> Le lun. 10 sept. 2018 à 19:49, djakk djakk  > a écrit :
> >>> Coucou !
> >>>
> >>> Je reviens sur cette histoire de highway=trunk qui diffère selon les
> pays.
> >>>
> >>> Je pense qu’il est important d’avoir pour chaque clé-valeur une
> définition commune au monde entier (autant que possible ) et qu’un 5e
> niveau dans la hiérarchie des “highways”
> >>> serait souhaitable : residential/unclassified - tertiary - secondary -
> primary - trunk.
> >>>
> >>> Du coup, il s’agirait de reprendre pour la France le classement
> anglais des highways, où le trunk désigne une super-route pas forcément de
> type autoroutier.
> >>>
> >>> Par exemple pour différencier la N12 et la D31 à Ernée (
> >>> https://www.openstreetmap.org/#map=12/48.3017/-0.9306 <
> https://www.openstreetmap.org/#map=12/48.3017/-0.9306> ) la N12 serait à
> mettre en trunk - comme à priori toutes les nationales restant en France.
> >>>
> >>> Pour retrouver les informations actuellement fournies par le trunk
> français : la classification administrative avec le panneau “route pour
> automobiles”, on a la clé-valeur “motorroad=yes”.
> >>> Il faut inventer une nouvelle clé pour désigner une route dénivelée
> (pas de carrefours à niveau) : at_grade=no ou junctionS=interchangeS (utile
> pour les cas où la route ressemble à une route pour automobiles dénivelée,
> mais ça n’en est pas une officiellement, exemple : la N12 au niveau de
> Goussainville :
> >>> https://www.openstreetmap.org/#map=16/48.7718/1.5526 <
> https://www.openstreetmap.org/#map=16/48.7718/1.5526>
> >
> 

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Jérôme Seigneuret]

Salut,
Pour faire simple, Quand tu crées des relations pour les itinéraires
(exemple transport en commun en bus) et éviter d’annoncer que tu fais le
tour du rond-point quand c'est pas le cas.

Après il faut faire ça correctement.

https://www.openstreetmap.org/search?query=montpellier#map=19/43.61322/3.85909=T

Ici c'est un cas typique de découpe sans que les tronçons soit mis à jour
dans la relation.

Bonne journée

Le ven. 14 sept. 2018 à 09:10, Jo  a écrit :

>
> Op vr 14 sep. 2018 om 09:05 schreef Sébastien Dinot <
> sebastien.di...@free.fr>:
>
>> Bonjour,
>>
>> - Mail original -
>> > Pas forcement, moi-même j'ai commencé à représenter des itinéraires
>> > de bus en découpant les giratoires, tout simplement car cela m'a
>> > semblé plus logique ainsi.
>> > Le but étant de retranscrire le cheminement du bus.
>>
>> Idem.
>>
>> > Bon ensuite j'ai compris que la pratique veut que l'on découpe pas
>> > les giratoires, je me suis adapté et en effet c'est plus simple à
>> > gérer ainsi.
>>
>> Idem.
>>
>> Il se trouve qu'en début de semaine, j'ai passé un long moment à
>> transformer un « mini_roundabout » sur lequel venaient se greffaient 4
>> voies simples en « roundabout » (ce qu'il était clairement) avec les
>> jonctions en Y. Mon problème n'avait pas été la création du rond-point et
>> des axes en eux-mêmes, mais le découpage du rond-point et la modification
>> des nombreux trajets de bus qui passaient par ce rond-point en m'assurant
>> qu'au final, je n'avais cassé aucune relation.
>>
>> Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas
>> nécessaire, qu'on pouvait intégrer le rond-point en entier dans la
>> relation. Pour le coup, d'un point de vue topologique, c'est surprenant,
>> mais si les outils de routage s'en sortent, ça me va tout aussi bien
>> sachant que la tâche est alors grandement facilitée (et que j'ai repéré
>> d'autres « mini_roundabout » tout aussi complexes à corriger).
>>
>
> Je veux bien vous démontrer que cette tache est rendu triviale avec le
> greffon PT_Assistant.
>
> Polyglot
> ___
> 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

Re: [Talk-cz] Fody na www.openstreetmap.cz

[<0174]

Ahoj,
KČT to rozlišuje na silniční/terénní, tak bych silniční nechal.
https://www.kct.cz/cms/turisticke-znaceni-kct-cykloznaceni
Vojta

Dne pá 14. 9. 2018 7:18 uživatel Tom Ka  napsal:

> Dne 13. září 2018 16:41 Mirek Dlask  napsal(a):
> > S rozdělením na 'znaceni' a 'rozcestnik' souhlas.
>
> OK
>
> > 'silnicni' pro 'znaceni' určitě ne. Celá trasa Greenway Jizera je značena
> > malými tabulkami 'znaceni' a rozhodně nevede celá jen po silnici. Je bez
> > pásového značení. Nevede jen po silnici  a nedá se celá projet na
> silničním
> > kole.
> > Žluté cyklorozcestníky vídám opravdu jen u silnic, i když ukazují na
> odbočku
> > na polní (lesní) cestu.
>
> > Ale rozdělení na silniční - trekové - gravel bike - MTB bych u fotek
> vůbec
> > neřešil.
> tohle neni o rozliseni pro co je to urcene ale pro 2 rozdilne zpusoby
> znaceni. Zkusil jsem to hodit do tabulky s prikladem obrazku at je to
> nazorne a jednoznacne:
>
> http://merlin.fit.vutbr.cz/tmp/tagovani-fody.html
>
> Pokud jsem na nejakou variantu zapomel, dejte vedet, pridam. Jinak
> souhlasim, ze 'silnicni' neni idealni nazev tagu - on se klidne muze
> jmenovat 'ABCDE' ale nic vystiznejsiho mne nenapadlo, pokud mate
> nejaky nazev, sem s nim - zavedene 'cyklo' i kdyz je v tomto okamziku
> taky nevystizne/nepresne bych spise nerad menil z historickych duvodu.
>
> A jeste pro jistotu - rozlisit ty zpusoby znaceni v terenu potrebuji
> ve Fody (mozna v OSM, to ted netusim) aby bylo mozne na to aplikovat
> ruzna pravidla (napr. jeden rozcestnik ma ref, druhy ma cislo tras(y)
> apod.). Do tabulky jsem pridal i sloupec pro tagovani OSM, ale prvni
> bych rad doresil jedno (Fody), pak muzeme diskutovat o OSM at se to
> nemicha dohromady, pak je v tom jeste vetsi zmatek.
>
> Bye
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Numéro de tuile ?

[Hélène PETIT]

Merci !

Le 14/09/2018 à 10:36, marc marc a écrit :

dans FF : F12, console réseau, rafraichir la page, tu as alors la liste
des urls de toute les tuiles.

sinon perso je charge l'endroit dans josm, tu actives le fond de carte
osm.org, clic droit, info sur la tuile

Le 14. 09. 18 à 10:27, Hélène PETIT a écrit :

C'est quoi le truc pour connaître le numéro d'une tuile affichée dans
OpenStreetMAp.org ?

___
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] Numéro de tuile ?

[osm . sanspourriel]

Autre possibilité : https://tile-b.openstreetmap.fr/

click droit, la partie variable de l'url c'est la même que celle que tu cherches.

 

Jean-Yvon
 

Gesendet: Freitag, 14. September 2018 um 10:36 Uhr
Von: "marc marc - marc_marc_...@hotmail.com" 
An: "talk-fr@openstreetmap.org" 
Betreff: Re: [OSM-talk-fr] Numéro de tuile ?

dans FF : F12, console réseau, rafraichir la page, tu as alors la liste
des urls de toute les tuiles.

sinon perso je charge l'endroit dans josm, tu actives le fond de carte
osm.org, clic droit, info sur la tuile

Le 14. 09. 18 à 10:27, Hélène PETIT a écrit :
> C'est quoi le truc pour connaître le numéro d'une tuile affichée dans
> OpenStreetMAp.org ?
___
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] Numéro de tuile ?

[marc marc]

dans FF : F12, console réseau, rafraichir la page, tu as alors la liste 
des urls de toute les tuiles.

sinon perso je charge l'endroit dans josm, tu actives le fond de carte 
osm.org, clic droit, info sur la tuile

Le 14. 09. 18 à 10:27, Hélène PETIT a écrit :
> C'est quoi le truc pour connaître le numéro d'une tuile affichée dans 
> OpenStreetMAp.org ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Numéro de tuile ?

[Hélène PETIT]

C'est quoi le truc pour connaître le numéro d'une tuile affichée dans 
OpenStreetMAp.org ?


Merci !

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

Re: [Talk-cat] GeoBirres OSM

[Felip Manyer i Ballester]

Bon dia a tots,

des de Perpinyà us desitjo una bona trobada.

-- 
Salut i mapes,
 
Felip.

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

Re: [Talk-cz] Uklid OSM CZ wiki

[Jan Dudík]

K tomu ještě obsah
https://wiki.openstreetmap.org/wiki/Category:Czech_Republic.


---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195


čt 13. 9. 2018 v 9:50 odesílatel Tom Ka  napsal:

> No ja se na to zkousel divat, a prijde mi, ze je to prace dost. Jestli
> jsi ochoten se toho ujmout, muzes teda pro zacatek udelat nekde treba
> sdileny google doc nebo neco podobneho se seznamem vsech stranek v
> cestina na OSM wiki, ktere nejsou popisem konkretniho tagu?
>
> Krome obsahu by bylo asi uzitecne zkontrolovat a poladit i provazani
> co se tyka kategorizace pripadne chybejicich odkazu at uz na koncovych
> strankach nebo na rozcestnicich.
>
> Prave to, ze uz vstupni zadani "zkontrolovat ceskou OSM wiki" neni moc
> exaktni je podle mne prvni prekazka.
>
> Nejake odkazy kdyz jsem se tim prograboval:
>
> Cs kategorie:
>
> https://wiki.openstreetmap.org/w/index.php?title=Special:Categories=Cruzeiro_do_Sul%2C_Rio_Grande_do_Sul
> Stranky zacinajici na Cs:
>
> https://wiki.openstreetmap.org/w/index.php?title=Special%3APrefixIndex=Cs%3A=0
>
> Bye
>
>
>
> Dne 12. září 2018 15:28 Dalibor Jelínek  napsal(a):
> > Ahoj,
> > není mi úplně jasné, co tím myslíš.
> > Těch stránek, které nejsou popisem klíčů nebo tagů, je
> > fakt jen pár. To může někdo projít za den.
> >
> > Jinak ty překlady stránek klíčů a značek už více než rok neaktualizuji,
> > takže některé jsou rozsynchronizované s anglickým textem.
> >
> > Dalibor
> >
> >> -Original Message-
> >> From: Tom Ka [mailto:tomas.kaspa...@gmail.com]
> >> Sent: Wednesday, September 12, 2018 2:24 PM
> >> To: OpenStreetMap Czech Republic 
> >> Subject: [Talk-cz] Uklid OSM CZ wiki
> >>
> >> Ahoj,
> >>
> >> kdyz se toho Dalibor chytil, tak vykopavam znovu jako nove vlakno.
> >> Podle mne je aktualni stav CZ wiki (mimo preklady klicu, tam si to asi
> Dalibor
> >> hlidal dobre) dost neuspokojivy v tom, ze obsahuje zastarale a nespravne
> >> informace. Moje predstava je dat dohromady seznam stranek - asi dle
> >> kategorie
> >> https://wiki.openstreetmap.org/wiki/Category:Cs:Czech_Documentation a
> >> pak pozadat dobrovolniky (1 nebo 2 na stranku) o verifikaci a
> aktualizaci
> >> (pripadne info do talk-cz, ze je to sice spatne ale neni jasne co je
> spravny
> >> text/info).
> >>
> >> Co vy na to?
> >>
> >> Dalibore - tebe jsem myslel prave na tu spravu a hlidani lidi, co kdo
> dela apod
> >> (+ klidne i kontroly). Sel by jsi do toho? Ja uz to casove nedam...
> >>
> >> Bye
> >>
> >> ___
> >> Talk-cz mailing list
> >> Talk-cz@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-cz
> >> https://openstreetmap.cz/talkcz
> >
> >
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > https://openstreetmap.cz/talkcz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cat] GeoBirres OSM

[Esther Mingot]

Bon dia!

compteu amb mi, així ens veiem les cares i serà més fàcil veure com heu fet tot 
el tema del transport públic ;-)

Salut i birres!


Sólo la verdad nos hará libres


De: Carlos Sánchez 
Enviado: jueves, 13 de septiembre de 2018 19:01
Para: OpenStreetMap in catalan
Asunto: Re: [Talk-cat] GeoBirres OSM

Jo surto a les 18:00 així que espero arribar abans de les 19h.

El jue., 13 sept. 2018 13:19, JOAQUIN GARCIA 
mailto:joaquin.garc...@gmail.com>> escribió:
Per si algú no li ha arribat encara per un altre canal., Us recordo que demà a 
partir de les 4 de la tarda és el dia per veure'n les cares.

Salut i Mapes, JQN

El jue., 30 ago. 2018 a las 9:48, JOAQUIN GARCIA 
(mailto:joaquin.garc...@gmail.com>>) escribió:
Bon dia a tots:

Al grup de Telegram ens vam proposar que féssim una trobada per dos motius

1. Que feia molt que no ens veiem o no ens hem vist cara a cara mai
2. Hi ha molta gent nova que és millor sentir-se fer-nos costat entre tots.

És per això que he proposat fer una trobada al lloc on col·laboro on tinc accés 
a diferents sales, incloent-hi la sala d'informàtica, per si voleu ficar-vos en 
farina.

https://www.openstreetmap.org/node/5658455709

Es tractaria de debatre, de parlar de projectes de futur, de resoldre dubtes, 
etc.

La sessió serà de tarda, de 4 a 8, amb la intenció que la gent vingui quan pugi.

Us deixo l'enllaç, perquè seleccioneu dia i us apunteu

https://doodle.com/poll/vkzx89r46a3ictp7

Salut i Mapes, JQN

--
Joaquín García Martínez

joaquin.garc...@gmail.com

Tlf. 629187135



--
Joaquín García Martínez

joaquin.garc...@gmail.com

Tlf. 629187135

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

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
  Libre de virus. 
www.avast.com
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Jo]

Op vr 14 sep. 2018 om 09:05 schreef Sébastien Dinot :

> Bonjour,
>
> - Mail original -
> > Pas forcement, moi-même j'ai commencé à représenter des itinéraires
> > de bus en découpant les giratoires, tout simplement car cela m'a
> > semblé plus logique ainsi.
> > Le but étant de retranscrire le cheminement du bus.
>
> Idem.
>
> > Bon ensuite j'ai compris que la pratique veut que l'on découpe pas
> > les giratoires, je me suis adapté et en effet c'est plus simple à
> > gérer ainsi.
>
> Idem.
>
> Il se trouve qu'en début de semaine, j'ai passé un long moment à
> transformer un « mini_roundabout » sur lequel venaient se greffaient 4
> voies simples en « roundabout » (ce qu'il était clairement) avec les
> jonctions en Y. Mon problème n'avait pas été la création du rond-point et
> des axes en eux-mêmes, mais le découpage du rond-point et la modification
> des nombreux trajets de bus qui passaient par ce rond-point en m'assurant
> qu'au final, je n'avais cassé aucune relation.
>
> Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas
> nécessaire, qu'on pouvait intégrer le rond-point en entier dans la
> relation. Pour le coup, d'un point de vue topologique, c'est surprenant,
> mais si les outils de routage s'en sortent, ça me va tout aussi bien
> sachant que la tâche est alors grandement facilitée (et que j'ai repéré
> d'autres « mini_roundabout » tout aussi complexes à corriger).
>

Je veux bien vous démontrer que cette tache est rendu triviale avec le
greffon PT_Assistant.

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

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[Jo]

junction=roundabout sur un way veut dire que ce way fait partie d'un
giratoire. Si le premier noeud et le dernier noeud de ce way sont le même,
c'est un closed way, comme tu le préfères pour les rotondes, mais ce n'est
pas obligatoire.

Si je découpe des rond-points, ce n'est pas aléatoire comme tu sembles
insinuer. Le but est toujours de créer des relations transports en
commun/cyclisme/randonnée qui sont continues décrivant exactement ce que
fait le bus, sans calculation répétitive nécessaire.

Jo

Op vr 14 sep. 2018 om 07:11 schreef Axelos :

> Bonjour,
>
> Le 14/09/2018 à 00:16, marc marc a écrit :
> > tag pour le rendu : afficher qu'un morceau du rond-point utilisé par un
> > trajet de de bus au lieu d'afficher l'ensemble du rond-point.
> > on a dàjà mainte fois évoqué la galère de maintenance que cela constitue
> > mais je pense que c'est peine perdue
>
> Pas forcement, moi-même j'ai commencé à représenter des itinéraires de
> bus en découpant les giratoires, tout simplement car cela m'a semblé
> plus logique ainsi.
> Le but étant de retranscrire le cheminement du bus.
>
> Bon ensuite j'ai compris que la pratique veut que l'on découpe pas les
> giratoires, je me suis adapté et en effet c'est plus simple à gérer ainsi.
>
> ___
> 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] Rond-points à la découpe. Pourquoi ?

[Sébastien Dinot]

Bonjour,

- Mail original -
> Pas forcement, moi-même j'ai commencé à représenter des itinéraires
> de bus en découpant les giratoires, tout simplement car cela m'a
> semblé plus logique ainsi.
> Le but étant de retranscrire le cheminement du bus.

Idem.

> Bon ensuite j'ai compris que la pratique veut que l'on découpe pas
> les giratoires, je me suis adapté et en effet c'est plus simple à
> gérer ainsi.

Idem.

Il se trouve qu'en début de semaine, j'ai passé un long moment à transformer un 
« mini_roundabout » sur lequel venaient se greffaient 4 voies simples en « 
roundabout » (ce qu'il était clairement) avec les jonctions en Y. Mon problème 
n'avait pas été la création du rond-point et des axes en eux-mêmes, mais le 
découpage du rond-point et la modification des nombreux trajets de bus qui 
passaient par ce rond-point en m'assurant qu'au final, je n'avais cassé aucune 
relation.

Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était pas 
nécessaire, qu'on pouvait intégrer le rond-point en entier dans la relation. 
Pour le coup, d'un point de vue topologique, c'est surprenant, mais si les 
outils de routage s'en sortent, ça me va tout aussi bien sachant que la tâche 
est alors grandement facilitée (et que j'ai repéré d'autres « mini_roundabout » 
tout aussi complexes à corriger).

Sébastien

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


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

Re: [Talk-cz] Fody na www.openstreetmap.cz

[Milan Cerny]

Na jihu Čech je spousta KČT cyklotras, od Lipna po Železnou Rudu. Jen je nemáme 
zmapované, nebo jsou tagované jako silniční.
To je prostor pro nápravu.
Další věc je zobrazení těchto cyklotras, třeba bílá trasa se snad nikde 
nezobrazuje. Ale to už jsme někde jinde.

Milan 

__
> Od: "majka" 
> Komu: talk-cz@openstreetmap.org
> Datum: 13.09.2018 16:27
> Předmět: Re: [Talk-cz] Fody na www.openstreetmap.cz
>
>On Thu, 13 Sep 2018 at 16:21, o...@kub.cz  wrote:
>
>> Kdysi jsem se o tom bavil s klukama s KČT a rozdíl mezi tím jeslti je
>> cyklostezka "žlutopruhová" nebo pomocí "silničních rozcestníků" je čistě v
>> tom kdo se o ní stará. KČT má (nepřekvapivě) ty žlutopruhový, nějaká
>> organizace obecní samosprávny instaluje ty silniční. V tom jaká je
>> sjízdnost rozdíl není (i když pochopitelně z povahy věci ty silniční budou
>> spíše na silnice žeano).
>>
>Neano:
>Protože fakt jsem u nás na jihu na pásové značení cyklotrasy nenarazila, a
>to ani tam, kde by to člověk tak nějak čekal - např.
>https://osm.fit.vutbr.cz/fody/files/11765.jpg nebo
>https://osm.fit.vutbr.cz/fody/files/11763.jpg (kvalita cesty na panoramě
>
>nebo
>třeba tady, také panorama
>
> ).
>
>Patrně proto, že se toho u nás chytila "Nadace jihočeské cyklostezky".
>Netuším zda pod sebou mají vše...
>
>Majka
>
>
>--
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>
>

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