Re: [OSM-talk-fr] Borne de puisage

[Philippe Verdy]

Si la couleur n'est pas réglementée, alors autant l'indiquer explicitement
par un tag "color=green/blue/yellow" voire meme "red" si le rouge n'est pas
réservée aux seuls pompiers qui doivent avoir leur propre marquage et clés
d'accès avec la vanne qui va bien pour eux. D'ailleurs je ne suis convaincu
que tous les hydrants incendie soient toujours rouges

Le lun. 29 oct. 2018 à 11:52, Nicolas Moyroud  a écrit :

> Merci Vincent (l'autre !) pour ces précisions.
>
> > Tu en as de ces TOCs toi ;)
> Oui tout plein, mais j'ai même pas envie de me faire soigner !
> > Certaines communes ne respectent pas ce code couleur. Je pense par
> > exemple à Senlis (60) où une bonne proportion des "vrais" poteaux
> > incendie sont du même vert que les bornes de puisage, juste pour une
> > raison esthétique :
> MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le
> rendu ça ! D'après mon contact la réglementation devrait bientôt obliger
> à respecter les codes par catégories d'hydrant. A voir...
> > pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :)
> > ) je suppose qu'une valeur numérique pour ce même tag doit aller. Voir
> > https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.
>
> Pour les jaunes pas forcément évident de connaître la pression si ce
> n'est pas indiqué dessus (mais peut-être que ça l'est
> systématiquement?). Y'a moyen d'indiquer "supérieur à" pour une valeur
> numérique ? J'ai jamais fait ça...
>
> On dirait que Disneyland aime mettre la pression. :-P
>
> Nicolas
>
>
> ___
> 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] opening_hours contre les parcs parisiens

[Megan Parat]

On 10/26/18 2:28 PM, Philippe Verdy wrote:

> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  > a écrit :
>
> On Thu, 25 Oct 2018, Megan Parat wrote:
> [...]
>
> > 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1]
> 17:45-19:00,
> > Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep
> 17:45-20:30, May
> > 01-Aug 31 17:45-21:30
>
> [...]
>
> Là où la page opening_hours laisse penser que la virgule ne peut être
> utilisée que dans les listes (d'années, de mois ou d'heures), la
> spécification complète indique qu'on peut l'utiliser partout où on
> peut
> utiliser le point-virgule :
>
> |  opening_hours = 
> |  :  { 
>  }
> |  any_rule_separator: ';' | ',' | '||'
>
>
> Pas tout à fait :
> * le point-virgule dans un attribut indique une liste non-ordonnée
> (dont les éléments peuvent être librement permutés sans changement
> d'interprétation) : c'est valable normalement pour tout attribut OSM.
> * alors que la virgule impose un ordre de priorité.
>
> De fait les éléments séparés par point-virgules doivent être
> indépendants (ne pas se recouvrir, ou bien être équivalents
> sémantiquement)
>
> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de
> la liste séparée par point-virgule "08:00-17:45" couvre une bonne
> partie du second (qui indique des horaires différents pour certaines
> dates).
>
> Il ne devrait donc pas y avoir de point-virgule du tout dans ton
> exemple, où la virgule dans un liste vient ajouter des éléments
> (ajouter des plages horaires, ou en retirer avec "off")  à la liste en
> modifiant les précédents.

L'ordre a une importance en général :

La spécification explique que la syntaxe générale d'opening_hours est
une liste de sélecteurs séparés par des points-virgules. Les horaires
retenus pour une date correspondent au *dernier* sélecteur valide. (cf.
explication pour time_domain sur la page
https://wiki.openstreetmap.org/wiki/FR:opening_hours/specification)

L'intérêt de la virgule est de pouvoir écrire par exemple '08:00-18:00,
Fr 20:00-24:00'. Avec une virgule, pour le vendredi, c'est ouvert de 8h
à 18h, puis de 20h à minuit. Avec un point-virgule, c'est ouvert
seulement de 20h à minuit car la deuxième règle est valable pour ce
jour, et ainsi prend précédence. (cf. explication de
additional_rule_separator §1)

> La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie
> séparée par des virgules (une fois le point-virgule converti en
> virgule) contient les éléments suivants, qui doivent être lus dans
> l'ordre, chaque élément modifiant le calendrier:
> - au départ (liste vide), par défaut tout est fermé, tous les jours
> quelque soit l'heure
> - "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage
> horaire (cela remplace la fermeture
Correct pour le moment.
> - "PH" : n'indique aucune plage horaire, donc veut dire que cela
> ajoute l'ouverture toute la journée (24/24) des jours fériés
> - "Sa" : n'indique aucune plage horaire, donc veut dire  que cela
> ajoute l'ouverture toute la journée (24/24) de tous les samedis
> (fériés ou pas)
> - "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de
> 8h à 9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24
> si c'est férié, sinon ouvert seulement de 9h à 17h45)

La virgule est aussi utilisée pour les énumérations d'années, mois,
jours de la semaines, etc... (eg. 'Mo,We,Fr 08:00-18:00'). (cf. les
définitions de weekday_sequence, monthday_selector et year_selector)

Normalement, cette règle devrait prendre précédence sur les précédentes
si elle s'applique. Ça n'a pas trop de sens car c'est fermé par défaut.
C'est pour ça que si la règle définit une fermeture, celle ci se content
de supprimer la plage horaire. Donc pour '08:00-18:00; Mo 08:00-12:00
off', c'est ouvert le Lundi de midi à 18h. (cf. l'explication de
 (closed) )

C'est pour ça qu'il y a un point-virgule et non une virgule. Car le
comportement est le même et l'outil d'évaluation préfère le premier (car
il est moins complexe je suppose).

> - "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage
> horaire tous les jours de entre le 1er du mois de mars et le dernier
> dimanche de mars (n'a pas d'effet sur les dimanches fériée de mars,
> mais les autres dimanches non fériés de mars ont une ouverture allongée)
> - etc. (autres plages horaires ajoutées pour d'autres dates)
>
Elle s'applique pour les dimanches fériés car c'est la dernière qui
correspond et on utilise des virgules.
> Cette liste ne peut pas être librement permutée (notamment entre les
> éléments contenant des "off" et ceux qui sont "on" par défaut), mais
> peut être permutée entre deux éléments "on" s'il n'y a aucun élément
> "off" entre les deux.
>
> Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF
> le 4e (Su 08:00-09:00) qui est "off".
>
> Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que
> tu voulais mettre des 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 11:17, Sergio Manzi  wrote:
> 
> Prova anche a fare un overpass-turbo per taxon (puoi limitarti ai nodes) su 
> Vienna, Londra o Parigi e vedi cosa salta fuori.


guardando l’andamento è ancora molto più chiaro che taxon quasi non è stato 
usato tranne 2 imports:



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

Re: [Talk-GB] Fwd: Open MasterMap progress since Policy Announcement

[Rob Nickerson]

Yeah those dates did not tally with the proposed delivery plan (PDF) on
their website. Hence I didn't mention it in my initial email as I was
already doubting it. May have been an earlier aspiration that got put back
to allow more consultation. Disappointingly slow but gives us a bit more
time to come up with plans of what we might or might not do with the new
data.



Thanks,
*Rob*


On Thu, 18 Oct 2018 at 12:26, SK53  wrote:
>
>> Anna Powell-Smith reports that some of these commitments have recently
>> disappeared from the text:
>> https://twitter.com/darkgreener/status/1052228644318392320
>>
>> On Fri, 12 Oct 2018 at 19:36, Rob Nickerson 
>> wrote:
>>
>>> Hi all,
>>>
>>> Recap: The Ordnance Survey are working with the new Geospatial
>>> Commission on opening up access to more of their data.
>>>
>>> 
>>>
>>>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-gb-westmidlands] Mappa Mercia thursday

[Rob Nickerson]

Hi all,

First Thursday of the month this week which means Mappa Mercia meeting. Are
you able to join us this Thursday? The Bull, Price Street, Birmingham. From
around 7:30pm.

Thanks,
*Rob*
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-es] semanarioOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Hola, el semanario Nº 431, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10846/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[OSM-co] semanarioOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Hola, el semanario Nº 431, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10846/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[Talk-cl] semanarioOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Hola, el semanario Nº 431, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10846/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

[talk-latam] semanarioOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Hola, el semanario Nº 431, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10846/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-cu] semanarioOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Hola, el semanario Nº 431, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/10846/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

Re: [OSM-talk-fr] Migrer les amenity=swimming_pool (le retour)

[Noémie Lehuby]

Hello,

J'ai fait une passe sur les amenity=swimming_pool (ainsi que les 
leisure=swimming_pool) avec phone, website et wikidata.
J'ai aussi essayé opening_hours mais ce n'est pas assez discriminant, il 
y avait beaucoup de faux positifs (où le bassin et la piscine sont 
présents tous les deux, tous deux avec les tags opening_hours, pas 
toujours avec les mêmes valeurs d'ailleurs).


--
Noémie Lehuby

Le 27/10/2018 à 19:28, Paul Desgranges a écrit :
Normalement tu ne devrais plus trouver de "amenity=swimming_pool ayant 
un tag leisure/name/building", puisque justement c'était l'étape d'avant


Par contre j'ai cherché à l'instant les "amenity=swimming_pool" de 
type node seulement sur overpass-turbo https://overpass-turbo.eu/s/D9Q
et les premiers cas regardés ne peuvent pas être transformés 
directement en "leisure=swimming_pool"  !
- https://www.openstreetmap.org/node/1820461288 celui-ci c'est un 
"leisure=sports_centre + sport=swimming"
- https://www.openstreetmap.org/node/3648626536 celui-ci c'est un 
"leisure=sports_centre + sport=swimming"
- https://www.openstreetmap.org/node/1904181893 celui-ci c'est un 
bassin, mais il est déjà taggué comme bassin, et il est à coté d'un 
établissement qui n'est
pas taggué comme  "leisure=sports_centre + sport=swimming", et c'est 
plutôt ça qu'il faudrait faire du coup

-  et les autres que j'ai regardé aussi ...

Donc je crains que la conversion massive soit un peu risquée.

Il faudrait au moins couper en deux le traitement :
 - les nodes d'un coté (il y en a 102 
), par nature on ne peut pas 
connaître leur superficie :  j'ai l'impression qu'il faudrait regarder 
chacun des cas ? et dans n'y aurait-il pas un outil qui permettrait de 
se répartir la charge ?
 - les ways d'un autre coté (il y en a 6120 
), il faut les traiter en fonction de 
leur superficie
   -- les grandes superficies sont à regarder au cas par cas (par 
exemple https://www.openstreetmap.org/way/129407009

 est à transformer en "leisure=swimming_area")
   -- les petites superficies je ne sais pas en fait, regarder si on 
ne peut pas exploiter la présence d'un autre tag : 'phone=*' ou 
'access=customers' ou 'covered=yes' ?



Je pars une semaine, donc je ne pourrais pas participer à la suite de 
ceci la semaine prochaine en tout cas.

A bientôt
Paul



>Le 27/10/2018 /à 17:51:09 2018/, Marc marc a écrit :
> J'avais déjà passé en revue le critère des 2000m2 mais
> il peux toujours y avoir de nouveaux cas entre temps.
>De toute façon, je proposais de le faire avec ceinture
>et bretelles. et donc ces cas sont ignorés dans ma correction.
>Si personne n'a plus d'objection, je ferrai la conversion
> des amenity=swimming_pool n'ayant pas de tag leisure/name/building,
>ayant une surface < 2000m2 et situé en France
>en leisure=swimming_pool

Le 27/10/2018 à 15:55, Paul Desgranges a écrit :
Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il 
n'y a plus de "amenity=swimming_pool + name=*" ni de 
"amenity=swimming_pool + building=*" (sauf erreur ?)
(l'occasion à chaque fois de faire un peu de micromapping autour de 
ces établissements...)


Ce que je n'ai pas fait, c'est le traitement de tous les 
"amenity=swimming_pool" qui auraient une surperficie assez grande 
pour suspecter un "leisure=sports_centre",
cela reste une étape supplémentaire à faire avant le changement 
massif des autres "amenity=swimming_pool" ?


Bonne journée
Paul




je regarde de mon coté tous les cas qui sont exclus de l'édition de 
masse

Si je devais le faire

1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine'
'Piscine privée' pour mettre ça dans la "description"
2- J'enlèverais du traitement massif tout ce qui peut l'être (comme
mentionné) :   les amenity=swimming_pool nommés (sauf les noms 
m. ci-dessus à traiter individuellement)   les 
amenity=swimming_pool qui sont aussi building

  les amenity=swimming_pool qui sont aussi leisure=sports_centre
 Car tous ceux là ont vocation à devenir des "leisure=sports_centre
sports=swimming name=... building=...", (sauf exception donc avec une

vérification visuelle)

3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi
leisure=*
et puisque tu es partant pour le reste, que moi je considère bcp 
plus risqué, et bien ça se complète pas trop mal




___
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

[OSM-talk-be] osm - arlon - training course / evangelism

[Pierre Parmentier]

As suggested by Joost Schouppe, I give you here more info about

On Monday 23 October 2018, I delivered my first hours of evangelism on
OpenStreetMap.

Regular visitors to the Espace public numérique (EPN) of Arlon as well as
people particularly interested in the subject, such as members of the
Association Les Sentiers de Grande Randonnée, were present.

For three hours in the morning and again three hours in the afternoon, I
talked and showed screens about the 'use' of OpenStreetMap in everyday
life. The means of 'contributing' and participating in the database will be
explained on 6 and 27 November.

Let me say that it was difficult for me to speak of all the elements that I
had promised myself to explain. Time is short with OpenStreetMap! The
audience had a very varied computer experience. For some people, the use of
the mouse was still unclear in all situations. But many interesting and
constructive questions have been raised. And at the end of each session, we
did not reach half of the program! But all visitors received a brief
program (paper and PDF) as well as a clear list of all the websites I
planned to visit.

Very, very beautiful experience! More details after the next two steps.

All with the support of some contributors of the Pays d'Arlon
 and the manager of
the EPN.

Regards.

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

Re: [OSM-talk-fr] Suivi de l'état du bâti par rapport au cadastre

[marc marc]

Bonjour,

Le 29. 10. 18 à 18:19, Gautier Pelloux-Prayer a écrit :
> Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
> ne pas en rajouter un nouveau ?!

hasard de calendrier, hier je me disais que je venais de trouver l'avant 
dernière pièce manquante pour faire "un peu mieux que "trop à la main"
https://github.com/sebastien-bugzilla/BatiOsm
http://forum.openstreetmap.fr/viewtopic.php?f=5=1762
l'autre pièce manquante c'était la tienne :)

> https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par 
> commune, afin de connaître de quand date le dernier import du cadastre 
> réalisé. Cela permet de détecter :

double bravo !
- d'avoir eu l'idée et de l'avoir fait
- d'avoir éviter de recoder tous les briques au profit d'une utilisation 
de l'existant (cela permet qu'une amélioration des ces briques profite 
aussi à ton interface)

> - les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
> vectoriel disponible)

j'ai pas trop compris comment on obtenait cette liste.
il y a l'air d'avoir 0.3% de commune concernée.
mais soit elles sont trop petite pour les trouver avec le zoom affichant 
la France entière, soit j'ai raté qlq chose :)

> - les communes qui n'ont /a priori/ jamais été importés, mais où du bâti 
> existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés 
> à la main (IGN, Bing)… mais il manque 90+% du bâti.

l'outil BatiOsm (ou une comparaison sommaire entre le nombre de bâtiment 
osm et celui dans l'extract cadastre osm.fr) permettrait de se faire une 
idée des communes où le manque est le plus criant.
On peux aussi encore plus sommairement se baser sur la présence ou non 
de l'extract sur le serveur.

> - et sinon la date d'import des autres villes (en se basant sur le tag 
> /source/ des bâtiments).

cette méthode histoire étant de + en + dépréciée,
une futur amélioration pourrait tenir compte de la date de modif ou 
d'analyser l'historique (même si c'est bcp plus long)

> les fichiers Etalab

l'an passé il était urgent d'attendre.
quel est la situation actuelle ? quelqu'un les utilise ?
sur le wiki, si c'est documenté, c'est "sous le radar"
dans les pages concernant le cadastre

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

[Talk-br] RES: Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Thierry Jean]

Peter, como conversamos por telefone, não Podemos incomodar mais quem já está 
sendo muito prestativo conosco. O conjunto da declaração mais as precisões do 
email enviado do endereço profissional é suficiente. Para as próximas 
prefeituras, procuraremos ter um documento padrão que seja mais claro de bate 
pronto. Conversei com amigos dos USA que me disseram que tem um email já é 
suficiente.

Anderson, creio que você pode continuar o trabalho.

Thierry Jean

Enviado do Email para Windows 10

De: Peter Krauss
Enviado:domingo, 28 de outubro de 2018 14:50
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / 
Importação de numeração predial

Olá, que bom, está avançando!
hum... Parece que houve boa intensão e disposição de fazer a coisa certa, mas 
por hora meu entendimento é que ainda não expressou o que foi solicitado. A 
frase "Em complemento, concordamos com a disponibilização dos dados de 
mapeamento do IPPUC sob os termos da liença ODC Open Database License" 
infelizmente não consta no texto assinado.

Sugiro fortemente que se produza um novo documento seguindo o modelo de 
Declaração de licenciamento 
ODbL
Ideal é depois registrar num cartório eletrônico oficial, tal como este  (se 
reclamarem eu pago!)

- - -
PS: é muito importante conscientizar os titulares de direitos sobre os dados 
abertos de interesse da OSM Brasil...  A abertura efetiva e sem riscos para o 
OSM depende da declaração de licença ODbL ou declaração de dedicação ao domínio 
público (CC0), e não existe outra opção simples e segura, são apenas estas duas:
* Declaração de licenciamento 
CC0
* Declaração de licenciamento 
ODbL



On Fri, Oct 26, 2018 at 10:32 PM santamariense 
mailto:imagens...@gmail.com>> wrote:
Olá pessoal,

Conseguiu-se autorização formal do Instituto de Pesquisa e
Planejamento Urbano de Curitiba quanto a cedência dos dados de
cartografia para o OSM disponibilizados em
http://ippuc.org.br/geodownloads/geo.htm e a declaração está
disponível em 
https://wiki.openstreetmap.org/wiki/File:Declara%C3%A7%C3%A3o_de_Ced%C3%AAncia_de_dados_IPPUC.pdf

Gostaria que analisassem a declaração e dessem um feedback, caso
alguém discorde que sim, está suficientemente claro que os dados podem
ser importados para o OSM.

A ideia principal, e para isso estou sendo incumbido, é importar a
numeração predial da cidade que está disponível em "Lotes -
(julho/2018)". Não é disponível o shapefile de prédios, mas sim dos
lotes. A proposta é transformar a área do lote em ponto no centroide
do seu respectivo lote, e realocar cada um dos pontos gerados para a
proximidade da rua onde o endereço está localizado, ou seja, dentro do
prédio, porém, mais próximo de onde provavelmente esteja a porta de
entrada dele.

Conforme as boas práticas, será mantido o histórico dos endereços já
mapeados no OSM, inclusive suas coordenadas, sem haver duplicação de
objetos na base de dados do OSM.

A documentação está sendo feita em
https://wiki.openstreetmap.org/wiki/Curitiba/Importa%C3%A7%C3%A3o_IPPUC

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

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

Re: [OSM-talk-fr] Borne de puisage

[Gwenaël Jouvin]

Bonsoir,

Merci pour ce tuyau (d’arrosage) !

J’ai récemment ajouté un « poteau incendie » dont je me demandais pourquoi il 
était vert et si peu visible dans l’ombre… ce serait donc une borne de puisage 
? Pourtant, c’est physiquement un poteau utilisé ailleurs pour les points d’eau 
incendie de la région.
J’avais aussi ajouté color=green :-)

Pour les véritables poteaux incendie, attention j’en ai déjà vu avec un 
demi-capot jaune et l’autre rouge, impossible de savoir si c’est de la haute 
pression dedans.
Il y a également ce document qui permet d’apprendre un peu : 
http://www.sdis17.fr/sites/sdis17/files/fichiers/rddeci.pdf

Pour les points d’aspiration, ceci conviendrait-il ?
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dsuction_point


Gwenaël


Le 29/10/2018 à 11:55, Nicolas Moyroud a écrit :
> Merci Vincent (l'autre !) pour ces précisions.
> 
>> Tu en as de ces TOCs toi ;) 
> Oui tout plein, mais j'ai même pas envie de me faire soigner !
>> Certaines communes ne respectent pas ce code couleur. Je pense par exemple à 
>> Senlis (60) où une bonne proportion des "vrais" poteaux incendie sont du 
>> même vert que les bornes de puisage, juste pour une raison esthétique : 
> MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le rendu ça 
> ! D'après mon contact la réglementation devrait bientôt obliger à respecter 
> les codes par catégories d'hydrant. A voir...
>> pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) ) je 
>> suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
>> https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.
> 
> Pour les jaunes pas forcément évident de connaître la pression si ce n'est 
> pas indiqué dessus (mais peut-être que ça l'est systématiquement?). Y'a moyen 
> d'indiquer "supérieur à" pour une valeur numérique ? J'ai jamais fait ça...
> 
> On dirait que Disneyland aime mettre la pression. :-P
> 
> Nicolas
> 
> 
> ___
> 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-ca] hebdoOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

[OSM-talk-fr] hebdoOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

[Talk-ht] hebdoOSM Nº 431 2018-10-16-2018-10-22

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

Re: [Talk-it] Editing di strada all'interno di un bosco

[Max1234Ita]

IMHO, dipende dai casi.

Per quanto ho potuto imparare col tempo, potrebbe andar bene anche unire i
due boschi e tracciare la way della strada attraverso di essi: è un modo
spiccio e pratico se il bosco è piccolo(*).


Però mi vengono in mente anche casi in cui gestire il bosco come entità
singola è a dir poco complicato.
Ad esempio, se avete mai provato a mappare qualche zona appenninica (in
Umbria, ad esempio), avrete sicuramente incontrato qualche foresta estesa
descritta da un enorme multipoligono con almeno una dozzina di way con ruolo
"Outer" e decine di "inner" (*).

Fare una modifica in un caso del genere richiede molto impegno e pazienza
perchè rompere la relazione in un qualche punto "fuori vista"  è
facilissimo... trovare il problema e ricostruirla invece lo è un po' meno. 
I messaggi d'errore di JOSM aiutano ma bisogna riuscire ad interpretarli
perchè non sono propriamente user-friendly.


Per questo, in casi del genere, nel mappare boschi e foreste io tendo a
sfruttare le strade -quando ci sono- come riferimento per separare due
grandi aree , così da avere oggetti un po' più gestibili. 
Da evitare , però, il far coincidere i nodi della strada con quelli delle
aree che esse separano o, peggio ancora, usare la strada come membro outer
di un multipoligono che descrive il contorno della foresta: questa soluzione
è semplice da implementare ma un incubo da manutenere!

Max




(*) per una limitazione dovuta alle API di OSM, la singola way può contenere
al massimo 2000 nodi. Oltre quella cifra occorre proseguire con un'altra e
combinare le due in una relazione di tipo "mutlipoligono";  l'ultimo nodo di
ogni outer way deve coincidere col primo nodo della successiva (l'ultimo
dell'ultima col primo della prima, nel cso di aree chiuse), o saranno
generati errori di validazione non sempre facili da scovare e sistemare...



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

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

[OSM-talk-fr] Suivi de l'état du bâti par rapport au cadastre

[Gautier Pelloux-Prayer]

Bonjour,

Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
ne pas en rajouter un nouveau ?!


https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par 
commune, afin de connaître de quand date le dernier import du cadastre 
réalisé. Cela permet de détecter :


- les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
vectoriel disponible)


- les communes qui n'ont /a priori/ jamais été importés, mais où du bâti 
existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés 
à la main (IGN, Bing)… mais il manque 90+% du bâti.


- et sinon la date d'import des autres villes (en se basant sur le tag 
/source/ des bâtiments).


Par ailleurs, le site permet d'ouvrir dans un JOSM préconfiguré le bâti 
d'une commune (généré via https://cadastre.openstreetmap.fr, en 
attendant que les fichiers Etalab soit prêts ?), afin de le mettre à 
jour (via le plugin Conflation, ou la méthode de votre choix..).


En espérant que ça puisse servir à d'autres, je m'en sers 
personnellement pour dégommer du rose et du gris ;-). Retours bienvenus, 
ici ou sur https://gitlab.com/bagage/cadastre-conflation/issues


Bonne journée,

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

Re: [Talk-it] Editing di strada all'interno di un bosco

[Cascafico Giovanni]

Riflette la realtà, non credo ci sia nulla di male. Come esempio, tutto il
territorio nazione sloveno è fatto così, a séguito dell'importazione
landcover.

Il lun 29 ott 2018, 16:15 Alessandro Sarretta 
ha scritto:

> Grazie Giovanni.
>
> In realtà, indipendentemente dall'esatta localizzazione della strada,
> chiedevo essenzialmente se abbia senso lasciare un "buco" nella mappatura
> di un landuse=forest in corrispondenza di una strada. Mi sembra poco utile,
> poco realistico e assai poco gestibile...
>
> Ale
> On 29/10/18 15:44, Cascafico Giovanni wrote:
>
> Verificare la qualità del bosco e della highway con le traccie GPS.
> Aggiustare i nodi del peggiore.
> In assenza/insufficienza di dati GPS, verificare le fonti: di solito gli
> import sono più attendibili e i ricalchi meno, sopratutto in zone montane.
>
> Il lun 29 ott 2018, 15:27 Alessandro Sarretta <
> alessandro.sarre...@gmail.com> ha scritto:
>
>> Buongiorno,
>>
>> in questa zona https://www.openstreetmap.org/#map=18/45.77040/11.35229
>> potete vedere una strada in mezzo a un bosco (che ho percorso lo scorso
>> fine setimana), nel comune di Schio (VI), visibile sia come
>> highway=unclassified, sia come vuoto tra due "ali" di landuse=forest
>>
>> Mi sembrerebbe logico che in questo caso le due parti di forset venissero
>> "unite" e che la strada rimanesse mappata solamente come highway.
>>
>> E' corretto? Qual è la modalità migliore per farlo?
>>
>> Grazie,
>>
>> Ale
>> --
>> --
>>
>> Alessandro Sarretta
>>
>> skype/twitter: alesarrett
>> Web: ilsarrett.wordpress.com
>>
>> Research information:
>>
>>- Google scholar profile
>>
>>- ORCID 
>>- Research Gate
>>
>>- Impactstory 
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
> --
> --
>
> Alessandro Sarretta
>
> skype/twitter: alesarrett
> Web: ilsarrett.wordpress.com
>
> Research information:
>
>- Google scholar profile
>
>- ORCID 
>- Research Gate
>
>- Impactstory 
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Editing di strada all'interno di un bosco

[Alessandro Sarretta]

Grazie Giovanni.

In realtà, indipendentemente dall'esatta localizzazione della strada, 
chiedevo essenzialmente se abbia senso lasciare un "buco" nella 
mappatura di un landuse=forest in corrispondenza di una strada. Mi 
sembra poco utile, poco realistico e assai poco gestibile...


Ale

On 29/10/18 15:44, Cascafico Giovanni wrote:
Verificare la qualità del bosco e della highway con le traccie GPS. 
Aggiustare i nodi del peggiore.
In assenza/insufficienza di dati GPS, verificare le fonti: di solito 
gli import sono più attendibili e i ricalchi meno, sopratutto in zone 
montane.


Il lun 29 ott 2018, 15:27 Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>> 
ha scritto:


Buongiorno,

in questa zona
https://www.openstreetmap.org/#map=18/45.77040/11.35229 potete
vedere una strada in mezzo a un bosco (che ho percorso lo scorso
fine setimana), nel comune di Schio (VI), visibile sia come
highway=unclassified, sia come vuoto tra due "ali" di landuse=forest

Mi sembrerebbe logico che in questo caso le due parti di forset
venissero "unite" e che la strada rimanesse mappata solamente come
highway.

E' corretto? Qual è la modalità migliore per farlo?

Grazie,

Ale

-- 
-- 


Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

  * Google scholar profile

  * ORCID 
  * Research Gate

  * Impactstory 

___
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

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [OSM-talk-fr] opening_hours contre les parcs parisiens

[Francois Gouget]

On Fri, 26 Oct 2018, Philippe Verdy wrote:

> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :
[...]
> Pas tout à fait :
> * le point-virgule dans un attribut indique une liste non-ordonnée (dont
> les éléments peuvent être librement permutés sans changement
> d'interprétation) : c'est valable normalement pour tout attribut OSM.
[...]
> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
> liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
> second (qui indique des horaires différents pour certaines dates).
> 
> Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,

Clairement opening_hours ne suit pas la règle. Mais mieux vaut suivre un 
standard, même pas très uniforme, plutôt que faire autre chose qu'aucune 
application ne saura décoder.

On peut aussi changer la règle mais je ne me lancerai pas là-dedans.


Ce qui est plus intéressant c'est que l'outil d'évaluation semble avoir 
un bug lié au passage à l'heure d'hiver.

  http://openingh.openstreetmap.de/evaluation_tool/

Par exemple pour "10:00-20:00" il affiche bien "open 10:00 to 20:00" 
pour le 2018-10-28 mais sur la même ligne le graphe retarde d'une heure 
et indique 11h à 21h !

On retrouve le même problème pour le passage à l'heure d'été le 
2018-03-25 mais cette fois-ci le graphe a une heure d'avance.

-- 
Francois Gouget   http://fgouget.free.fr/
  All generalizations are false, including this one.
 -- Mark Twain___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] micro-mapping de parkings

[deuzeffe]

On 11/09/2018 21:20, marc marc wrote:

par contre les parking_space sont bien utile, par exemple si on veux 
affiner pour les places PMR ou simplement comme micromapping

Bonjour,

Il semble que les parking_space ne puissent pas être isolés mais 
obligatoirement être "inclus" dans un polygone parking (/Emplacement 
particulier au sein d'un parking/, je cite le wiki).


Sauf que ça me pose un problème lorsque il y a un "parking" constitué 
uniquement de 2-3 places PMR ou pour marquer les places PMR dans un 
parking_lane. Du coup, je crée des parking_space isolés (c'est mal).


Si vous avez des conseils pour mieux faire ce que je fais mal, je suis 
preneuse !


--
deuzeffe


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

Re: [Talk-it] Editing di strada all'interno di un bosco

[Cascafico Giovanni]

Verificare la qualità del bosco e della highway con le traccie GPS.
Aggiustare i nodi del peggiore.
In assenza/insufficienza di dati GPS, verificare le fonti: di solito gli
import sono più attendibili e i ricalchi meno, sopratutto in zone montane.

Il lun 29 ott 2018, 15:27 Alessandro Sarretta 
ha scritto:

> Buongiorno,
>
> in questa zona https://www.openstreetmap.org/#map=18/45.77040/11.35229
> potete vedere una strada in mezzo a un bosco (che ho percorso lo scorso
> fine setimana), nel comune di Schio (VI), visibile sia come
> highway=unclassified, sia come vuoto tra due "ali" di landuse=forest
>
> Mi sembrerebbe logico che in questo caso le due parti di forset venissero
> "unite" e che la strada rimanesse mappata solamente come highway.
>
> E' corretto? Qual è la modalità migliore per farlo?
>
> Grazie,
>
> Ale
> --
> --
>
> Alessandro Sarretta
>
> skype/twitter: alesarrett
> Web: ilsarrett.wordpress.com
>
> Research information:
>
>- Google scholar profile
>
>- ORCID 
>- Research Gate
>
>- Impactstory 
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[majka]

Za mě OK.
On Mon, 29 Oct 2018 at 15:13, Tom Ka  wrote:

> Dalsi restik - po zmene prace s preskakovanymi fotkami (jiz drive) to
> ted pro kontroly nebere fotky oznacene jako 'necitelne', takze se dany
> rozcestnik objevi jako znovu nafotit pokud tam neni zadna jina fotka.
> (nicmene necitelneych neni az tak mnoho, aspon tech povolenych).
>
> OK?
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-it] Editing di strada all'interno di un bosco

[Alessandro Sarretta]

Buongiorno,

in questa zona https://www.openstreetmap.org/#map=18/45.77040/11.35229 
potete vedere una strada in mezzo a un bosco (che ho percorso lo scorso 
fine setimana), nel comune di Schio (VI), visibile sia come 
highway=unclassified, sia come vuoto tra due "ali" di landuse=forest


Mi sembrerebbe logico che in questo caso le due parti di forset 
venissero "unite" e che la strada rimanesse mappata solamente come highway.


E' corretto? Qual è la modalità migliore per farlo?

Grazie,

Ale

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo rozcestníky

[Tom Ka]

po 29. 10. 2018 v 13:18 odesílatel majka  napsal:
> Co je pak tohle za paskvil, to skutečně netuším. Značení s kilometráží?
no resil jsem to ted, kdyz jsem zacal kontrolovat a pravovat tagy. U
techto silnicnich jsem nakonec vychazel zhruba z nasledujiciho:

- je tam smer a vzdalenost -> je to rozcestnik 'ala pesi'
- je to neco, kdy bych na stejnem miste pro pesi ocekaval rozcestnik
-> je to rozcestnik
- je to neco, kdy bych na stejnem miste cekal pro pesi jen znaceni  ->
je to znaceni
-> vse ostatni je znaceni

obavam se ale, ze je to prilis rozmanite na uplne exaktni rozdeleni,
ono to ale asi v realu nebude takovy strasny prusvih.
jinak pripominam https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples,
muzu tam pridat nejake dalsi pripady at je na co se odkazovat a je to
na jednom miste nejak shrnute.

Bye

> V těch chybných rozcestnících - tedy konkrétně u exportu gpx - bych byla pro 
> to, u blíže neurčených rozcestníků (momentálně označených jen id bodu, třeba 
> n5171260568) přidat do názvu minimálně typ, pokud ho to v OSM má - tj. 
> hiking/bicycle/ski, takže by to vypadalo nějak takhle n5171260568 
> (bicycle) nebo n291205540 (ski) , aby bylo lépe vidět, co 
> hledat. Na webu si můžu zobrazit podrobnosti, v tom exportu to vidět v 
> současné době nijak není a může to napovědět v tom, co a kde konkrétně to po 
> okolí musím hledat.

OK, zamyslim ze jestli to nejak jednoduse pujde.

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

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

[Tom Ka]

út 11. 9. 2018 v 18:35 odesílatel majka  napsal:
> Ahoj,
>
> Ale teď dotaz: Jak chceš obecně zacházet s fotkami, které jsou označené jako 
> rozmazané? Nechtělo by je to "zakázat" automaticky? Tedy aby se nebraly jako 
> správné a rozcestník pak jako bezchybný, pokud se jedná o jedinou fotku, 
> kterou to má. Podle mě by ta fotka měla smysl jedině pokud by rozcestník v 
> OSM komplet chyběl, jako upozornění že tam "něco" je.

Dalsi restik - po zmene prace s preskakovanymi fotkami (jiz drive) to
ted pro kontroly nebere fotky oznacene jako 'necitelne', takze se dany
rozcestnik objevi jako znovu nafotit pokud tam neni zadna jina fotka.
(nicmene necitelneych neni az tak mnoho, aspon tech povolenych).

OK?

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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 11:11, Mateusz Konieczny  wrote:
> 
> I would consider it as a tagging for renderer, and it would be preferable to 
> avoid it (tagging
> 
> access on gate should be sufficient). On the other hand it is one of the 
> least harmful ones
> 


It should be discouraged, if there is a restriction through the gate, it should 
go on the gate, not on the way passing through. The result may come close to 
the actual situation but it is still wrong.


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

[Talk-cz] Fody - novinky, drobnosti

[Tom Ka]

Ahoj, par novinek:

- zrusil jsem z tabulkovych vypisu Import ID, tj. ID fotky z
api.osm.cz, vzhledem k tomu, ze to walley vypnul, tak to jiz neni na
co odkazovat, zustalo u detailu fotky, jiz bez prokliku na api.osm.cz
- nove lze zobrazit zakazane fotky per autor napr.:
https://osm.fit.vutbr.cz/fody/?list.disabled=tom.k
- v tabulce odkazu na mapy jsem zrusil odkaz historie a predelal ho
jen na ikonu - tj. fotka ma historii, napr.
https://osm.fit.vutbr.cz/fody/?id=17349
- v ramci pripravy na verifikaci fotek je na stejnem miste jako
historie doplnena ikona verifikace, pokud je fotka verifikovana a
datum verifikace je novejsi nez nejnovejsi uprava. viz.
https://osm.fit.vutbr.cz/fody/?id=17349. Zadavani verifikaci jeste
musim doplnit, tahle je rucne do DB pro ukazku. (po najeti se objevi,
kdo a kdy provedl posledni verifikaci)

Konec hlaseni ;-)

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

Re: [Talk-at] OSM Flyer Bestellung

[Michael Maier]

Hallo Markus,

vielen Dank, dass ihr neue druckt.

Wir in Graz haben noch keine mit korrektem Impressum, bitte 50 Stk. für
uns mitbedenken.

lg,
Michael

On 10/29/18 12:09 PM, scubbx wrote:
> Hallo, liebe Mitmapper und Mitmapperinnen!
> 
> Der OSM-AT Verein wird in Kürze wieder neue OSM - Flyer bestellen.
> (https://github.com/scubbx/osm-at-flyer)
> Falls jemand weiß, dass eine größere Menge benötigt werden wird, kann
> dies jetzt kundgetan werden, dann werden wir diese Menge in der
> Bestellung berücksichtigen.
> 
> Beste Grüße,
> Markus (ScubbX)
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 

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

[Talk-at] Antw: OSM Flyer Bestellung

[Bernhard Holub]

Ahoi!

Ich bin öfters bei Wikipedia-Veranstaltungen und bringe dort gerne den
Flyer unter die Leute.

Mein Bedarf: 200 Stk.
 
lg Bernhard (Dromedar61)




>>> scubbx  29.10.18 12.13 Uhr >>>
Hallo, liebe Mitmapper und Mitmapperinnen!

Der OSM-AT Verein wird in Kürze wieder neue OSM - Flyer bestellen.
(https://github.com/scubbx/osm-at-flyer)
Falls jemand weiß, dass eine größere Menge benötigt werden wird, kann
dies jetzt kundgetan werden, dann werden wir diese Menge in der
Bestellung berücksichtigen.

Beste Grüße,
Markus (ScubbX)


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

Re: [Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo rozcestníky

[majka]

V podstatě šlo o nedorozumění, protože jsem pravý cyklo rozcestník tak jak
je tady chápán v reálu ještě neviděla, resp. pokud jsem byla někde poblíž,
projela jsem to bez povšimnutí.
To, co tady po okolí máme zadané, jsou v lepším případě silniční
rozcestníky nebo se jedná o silniční značení, nejbližší cyklotrasu
spadající pod KČT mám pěkně daleko.
Problém je, že tohle nikde žádný seznam nemá, ani není šance z okolních
"rozcestníků" poznat, kde je něco dalšího vyznačené. Navíc to nemá ani
nějak rozumně určené vzdálenosti - rozcestníky mohou být na dalším rohu,
nebo klidně až po nějakých 10-20 km a mezi tím jen pouhé značení. Některé
trasy ani nic jiného než značení nemají, z některých rozcestníků zase
nejsou vůbec trasy poznat.

I ty "chybné rozcestníky" budou z větší části podle Tvé definice značení,
kde je otázka, jestli to nepřeznačit i v datech. Jen netuším jak, pokud to
nebudu chtít komplet vynechat. Jeden z těch chybějících je třeba tohle

(na Panoramě). V tomhle případě to považuji za ekvivalent ukazatele
 k začátku turistické trasy.

Co je pak tohle  za paskvil,
to skutečně netuším. Značení s kilometráží?

V těch chybných rozcestnících - tedy konkrétně u exportu gpx - bych byla
pro to, u blíže neurčených rozcestníků (momentálně označených jen id
bodu, třeba n5171260568) přidat do názvu minimálně typ, pokud ho to v OSM
má - tj. hiking/bicycle/ski, takže by to vypadalo nějak takhle
n5171260568
(bicycle) nebo n291205540 (ski) , aby bylo lépe vidět,
co hledat. Na webu si můžu zobrazit podrobnosti, v tom exportu to vidět v
současné době nijak není a může to napovědět v tom, co a kde konkrétně to
po okolí musím hledat.

U "advanced" mod bych byla pro to, udělat multi filtr podle typů:
mapa/infotabule/rozcestník/značení/.../ostatní s dodatečným rozlišením pro
rozcestníky a značení jako hiking/bicycle/ski. Tj. každý by si pak mohl
zaškrtat vše, co ho zajímá, a odfiltrovat tak vše ostatní.

Majka

On Mon, 29 Oct 2018 at 11:47, Tom Ka  wrote:

> Ahoj, tak se zacinam pomalu vracet k nekterym restum ve Fody.
>
> - barevne bych rad urdzel "chybne" rozcestniky vsechno v sede jako
> doposud aby to rozumne kontrastovalo s ostatnima vrstvama (primarne
> fotkama nafocenych)
> - za mne bych tam dle aktualni situace cyklo i silnicni nechal, obecne
> chceme aby to lidi fotili
> - sum je podle mne u cyklo primarne kvuli foceni "znaceni", v tom se
> snazim o edukaci aby se nefotilo cokoliv ale podobne jako u pesich jen
> tam, kde ej to nejak dulezite k pochopeni, orientaci nebo jako dukaz,
> ze tam rozcestnik zaneseny v OSM realne neni. S tim souvisi, ze by
> takoveto tabulky znaceni nemely byt zadavany do OSM (muj nazor, ale
> asi tady uz taky probehlo).
>
> Ja (jak dovoli cas) zpracovavam vsechny fotky, primarne ty, ktere to
> vyhodi jako problem, ale uz jsem rikal, ze cyklo ma u mne mensi
> prioritu (ciste proto, ze nejsem s to stihat uplne vsechno, co bych
> chtel).
>
> Zaroven jsme se ted s Marianem bavili, z eby nebylo spatne mit pro
> vrstvu nafocenych (ale tim padem mozna i nenafocenych) lepsi
> 'advanced' mod, kde by se dalo lepe filtrovat co chci a nechci
> sobrazit. Tim by se mozna neco z tvych prani dalo resit.
>
> Zkus tedy prosim jeste preformulovat, ceho by jsi chtela pro sebe
> dosahnout (skryt XX ve vrstve YY protoze mne nezajimaji) a uvidime co
> s tim dal.
>
> Bye
>
> čt 6. 9. 2018 v 13:20 odesílatel majka  napsal:
> >
> > Dávám k úvaze, zda na openstreetmap.cz ve vrstvě chybných rozcestníků
> také zvolna nezačít rozlišovat od sebe turistické rozcestníky a cyklo
> rozcestníky barvou, jako to děláme u rozcestníků vyfocených (příklad tady).
> Případně zda by nebylo lepší je z chybných zcela vynechat (tedy jen
> rozcestníky s pouze bicycle=yes, jako je ten chybějící na tom odkazu) a do
> mapy nezobrazovat jen cyklo rozcestníky, které se spárují.
> >
> > Ve "vyfocených" územích nám ty cyklo rozcestníky v téhle vrstvě trochu
> začínají přidávat šum, a taky nafukují velikost v těch souborech gpx, které
> se vytvářejí.
> >
> > Netuším, jestli chceme uživatele vyzývat k focení stejně, jako u
> turistických rozcestníků. Řekla bych, že se soustavným zpracováním těch
> fotek momentálně nikdo z nás nezabývá, resp. maximálně si autor ty  svoje
> fotky vždy nějak zpracuje sám. Neříkám nezadávat do OSM, nebo nefotit (a
> neukazovat v mapě), ale možná nevykazovat momentálně jako stejnou chybu,
> jako u turistických rozcestníků (tedy chybějící foto a/nebo ref).
> >
> > 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
> 

Re: [OSM-talk] weeklyOSM #431 2018-10-16-2018-10-22

[Simon Poole]

The point mentioning my pull request
https://github.com/openstreetmap/openstreetmap-website/pull/2028 is a
bit misleading: the PR doesn't just add links, it integrates accepting
the ToU in to the signup process.

That said, feedback is welcome, best on the PR.

Simon


Am 27.10.2018 um 16:19 schrieb weeklyteam:
> The weekly round-up of OSM news, issue # 431,
> is now available online in English, giving as always a summary of all things 
> happening in the openstreetmap world:
>
> http://www.weeklyosm.eu/en/archives/10846/
>
> Enjoy!
>
> weeklyOSM? 
> who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
> where?: 
> https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk




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

Re: [Talk-es] Necesidad de poner límites en ciudad.

[Jorge Sanz Sanfructuoso]

En el tema del 50km/h en ciudad. No sé ahora cada enrutador como lo trata
exactamente, pero si no hay puesta velocidad por defecto debería detectar
que esta dentro de ciudad y limitarlo a 50km/h. Eso lo puede detectar si
esta el landuse=residential. Si no lo hace es fallo del enrutador no de
OSM. Lo que sí, cuando se sepa fehacientemente la velocidad es bueno
añadírselo a la vía, pero no porque sea lo normal en ciudad, sino porque se
tengan datos de ello.

Un saludo.

El lun., 29 oct. 2018 a las 12:23, Alejandro Moreno ()
escribió:

> Francisco Javier, en ese caso quién tiene que cambiar su código es el
> enrutador, no OSM para adaptarse al enrutador.
>
> El lun., 29 oct. 2018 a las 12:19, Fco. Javier González Jiménez (<
> fjavier...@hotmail.com>) escribió:
>
>> ¿Los enrutadores no consideran que las vías de categoría superior a
>> residencial es de una velocidad genérica superior a 50 km/h?
>>
>>
>>
>> Aquí tienes un ejemplo de enrutador web:
>> http://brouter.de/brouter-web/#map=13/37.1808/-3.6125/OpenStreetMap
>>
>>
>>
>> Según su configuración las velocidades por defecto son:
>>
>>
>>
>> assign maxspeed_implicit =
>>
>>   switch highway=motorway  999
>>
>>   switch highway=motorway_link 130
>>
>>   switch highway=trunk 250
>>
>>   switch highway=trunk_link100
>>
>>   switch highway=primary|primary_link  100
>>
>>   switch highway=secondary|secondary_link   90
>>
>>   switch highway=tertiary|tertiary_link 80
>>
>>   switch highway=unclassified   50
>>
>>   switch route=ferry10
>>
>>   switch highway=bridleway  10
>>
>>   switch highway=residential|living_street  30
>>
>>   switch highway=service30
>>
>>   switch highway=track|road|path switch tracktype=grade1 30 5
>>
>>   0
>>
>>
>>
>> Como ves todas se pasan de 50 km/h, por eso digo que sería bueno y
>> necesario que a falta de la velocidad límite que pueda haber en la realidad
>> por una señal, al menos, se ponga la genérica cuando se usen las vías
>> primaria, secundaria, terciaria dentro de ciudad.
>>
>>
>>
>> Saludo.
>>
>>
>>
>> *De:* Alejandro Moreno 
>> *Enviado el:* lunes, 29 de octubre de 2018 12:04
>> *Para:* Lista openstreetmap 
>> *Asunto:* Re: [Talk-es] Necesidad de poner límites en ciudad.
>>
>>
>>
>> «más vale poner el límite genérico de 50 a no poner ninguno en el caso de
>> las vías que se les ponga una categoría superior a “residencial” únicamente
>> y dentro de los municipios»
>>
>> Es una mala decisión poner un límite que no está avalado por ninguna
>> señal. Si el límite de velocidad de una calle es el genérico debe ser el
>> enrutador el que gestione ese límite. Si no corres el riesgo de que el
>> límite genérico cambie y no sepamos que max-speed están puesto porque hay
>> una señal y cuales se pusieron para ayudar a los enrutadores.
>>
>>
>>
>> El dom., 28 oct. 2018 a las 15:09, Fco. Javier González Jiménez (<
>> fjavier...@hotmail.com>) escribió:
>>
>> Hola,
>>
>>
>>
>> Gracias yopaseopor. Veo que estamos de acuerdo en que sirvan de
>> referencia para editar y no que se trasladen de forma literal. En Granada
>> es un verdadero desastre lo que se ha hecho con la clasificación de las
>> calles, y podemos ver casi toda la ciudad como de tercera categoría,
>> bastantes de segunda y primera, y no se corresponden a una distribución
>> real, ni lógica, como ya le comenté al usuario que lo hizo y que se negó a
>> corregir. Para él lo que importa es lo que diga el Ayuntamiento y no lo que
>> tienes delante de los ojos ni el trabajo de los que te antecedieron
>> editando, o la norma de OSM de crear redes de distribución que sea:
>> primarias para unir distritos, secundarías para unir barrios, terciarias
>> para las vías principales dentro del barrio. Ya me diréis de qué le sirve a
>> un enrutador tener que elegir entre varias calles si todas tienen la misma
>> categoría…
>>
>>
>>
>> Desde luego lo ideal sería establecer los límites reales y el resto de
>> características de las vías como propones en el caso de la iluminación,
>> pero también de carril bici o bus, número de carriles, etcétera.
>>
>>
>>
>> Creo que cuando usamos la categoría “residencial” los enrutadores toman
>> una velocidad por defecto según se indica en la ley, pero cuando usamos una
>> de categoría superior, que se supone que están para usar en exteriores de
>> municipios, la velocidad por defecto de los  enrutadores va en consonancia
>> a la categoría, por lo que si no se pone ninguna velocidad, los enrutadores
>> pueden usar 80, 90 o 100 km en mitad de la ciudad, por eso propongo, que
>> más vale poner el límite genérico de 50 a no poner ninguno  en el caso de
>> las vías que se les ponga una categoría superior a “residencial” únicamente
>> y dentro de los municipios. Aunque legalmente todo el mundo sabe la
>> velocidad en ciudad, el enrutador te puede calcular la ruta por distancia
>> (ruta más corta) o velocidad (ruta más 

Re: [Talk-es] Necesidad de poner límites en ciudad.

[Alejandro Moreno]

Francisco Javier, en ese caso quién tiene que cambiar su código es el
enrutador, no OSM para adaptarse al enrutador.

El lun., 29 oct. 2018 a las 12:19, Fco. Javier González Jiménez (<
fjavier...@hotmail.com>) escribió:

> ¿Los enrutadores no consideran que las vías de categoría superior a
> residencial es de una velocidad genérica superior a 50 km/h?
>
>
>
> Aquí tienes un ejemplo de enrutador web:
> http://brouter.de/brouter-web/#map=13/37.1808/-3.6125/OpenStreetMap
>
>
>
> Según su configuración las velocidades por defecto son:
>
>
>
> assign maxspeed_implicit =
>
>   switch highway=motorway  999
>
>   switch highway=motorway_link 130
>
>   switch highway=trunk 250
>
>   switch highway=trunk_link100
>
>   switch highway=primary|primary_link  100
>
>   switch highway=secondary|secondary_link   90
>
>   switch highway=tertiary|tertiary_link 80
>
>   switch highway=unclassified   50
>
>   switch route=ferry10
>
>   switch highway=bridleway  10
>
>   switch highway=residential|living_street  30
>
>   switch highway=service30
>
>   switch highway=track|road|path switch tracktype=grade1 30 5
>
>   0
>
>
>
> Como ves todas se pasan de 50 km/h, por eso digo que sería bueno y
> necesario que a falta de la velocidad límite que pueda haber en la realidad
> por una señal, al menos, se ponga la genérica cuando se usen las vías
> primaria, secundaria, terciaria dentro de ciudad.
>
>
>
> Saludo.
>
>
>
> *De:* Alejandro Moreno 
> *Enviado el:* lunes, 29 de octubre de 2018 12:04
> *Para:* Lista openstreetmap 
> *Asunto:* Re: [Talk-es] Necesidad de poner límites en ciudad.
>
>
>
> «más vale poner el límite genérico de 50 a no poner ninguno en el caso de
> las vías que se les ponga una categoría superior a “residencial” únicamente
> y dentro de los municipios»
>
> Es una mala decisión poner un límite que no está avalado por ninguna
> señal. Si el límite de velocidad de una calle es el genérico debe ser el
> enrutador el que gestione ese límite. Si no corres el riesgo de que el
> límite genérico cambie y no sepamos que max-speed están puesto porque hay
> una señal y cuales se pusieron para ayudar a los enrutadores.
>
>
>
> El dom., 28 oct. 2018 a las 15:09, Fco. Javier González Jiménez (<
> fjavier...@hotmail.com>) escribió:
>
> Hola,
>
>
>
> Gracias yopaseopor. Veo que estamos de acuerdo en que sirvan de referencia
> para editar y no que se trasladen de forma literal. En Granada es un
> verdadero desastre lo que se ha hecho con la clasificación de las calles, y
> podemos ver casi toda la ciudad como de tercera categoría, bastantes de
> segunda y primera, y no se corresponden a una distribución real, ni lógica,
> como ya le comenté al usuario que lo hizo y que se negó a corregir. Para él
> lo que importa es lo que diga el Ayuntamiento y no lo que tienes delante de
> los ojos ni el trabajo de los que te antecedieron editando, o la norma de
> OSM de crear redes de distribución que sea: primarias para unir distritos,
> secundarías para unir barrios, terciarias para las vías principales dentro
> del barrio. Ya me diréis de qué le sirve a un enrutador tener que elegir
> entre varias calles si todas tienen la misma categoría…
>
>
>
> Desde luego lo ideal sería establecer los límites reales y el resto de
> características de las vías como propones en el caso de la iluminación,
> pero también de carril bici o bus, número de carriles, etcétera.
>
>
>
> Creo que cuando usamos la categoría “residencial” los enrutadores toman
> una velocidad por defecto según se indica en la ley, pero cuando usamos una
> de categoría superior, que se supone que están para usar en exteriores de
> municipios, la velocidad por defecto de los  enrutadores va en consonancia
> a la categoría, por lo que si no se pone ninguna velocidad, los enrutadores
> pueden usar 80, 90 o 100 km en mitad de la ciudad, por eso propongo, que
> más vale poner el límite genérico de 50 a no poner ninguno  en el caso de
> las vías que se les ponga una categoría superior a “residencial” únicamente
> y dentro de los municipios. Aunque legalmente todo el mundo sabe la
> velocidad en ciudad, el enrutador te puede calcular la ruta por distancia
> (ruta más corta) o velocidad (ruta más rápida), para hacer los cálculos en
> un caso se fija en la distancia, en el otro en cuanto tardas en recorrerla,
> y para eso usa los tipos de vía y límites de velocidad. Cuando no existen
> usa los que tiene puestos por defecto según el tipo de vía.
>
>
>
> Un saludo.
>
>
>
>
>
>
>
> *De:* yo paseopor 
> *Enviado el:* domingo, 28 de octubre de 2018 6:52
> *Para:* Discusión en Español de OpenStreetMap 
> *Asunto:* Re: [Talk-es] Necesidad de poner límites en ciudad.
>
>
>
> El hecho de poner un límite a las calles es útil, pero en este caso tiene
> un problema. Si especificas el límite a 50 km/h y el límite real es a 30 o
> a 40 estarás dando una información 

Re: [Talk-es] Necesidad de poner límites en ciudad.

[Fco . Javier González Jiménez]

¿Los enrutadores no consideran que las vías de categoría superior a residencial 
es de una velocidad genérica superior a 50 km/h?

Aquí tienes un ejemplo de enrutador web: 
http://brouter.de/brouter-web/#map=13/37.1808/-3.6125/OpenStreetMap

Según su configuración las velocidades por defecto son:

assign maxspeed_implicit =
  switch highway=motorway  999
  switch highway=motorway_link 130
  switch highway=trunk 250
  switch highway=trunk_link100
  switch highway=primary|primary_link  100
  switch highway=secondary|secondary_link   90
  switch highway=tertiary|tertiary_link 80
  switch highway=unclassified   50
  switch route=ferry10
  switch highway=bridleway  10
  switch highway=residential|living_street  30
  switch highway=service30
  switch highway=track|road|path switch tracktype=grade1 30 5
  0

Como ves todas se pasan de 50 km/h, por eso digo que sería bueno y necesario 
que a falta de la velocidad límite que pueda haber en la realidad por una 
señal, al menos, se ponga la genérica cuando se usen las vías primaria, 
secundaria, terciaria dentro de ciudad.

Saludo.

De: Alejandro Moreno 
Enviado el: lunes, 29 de octubre de 2018 12:04
Para: Lista openstreetmap 
Asunto: Re: [Talk-es] Necesidad de poner límites en ciudad.

«más vale poner el límite genérico de 50 a no poner ninguno en el caso de las 
vías que se les ponga una categoría superior a “residencial” únicamente y 
dentro de los municipios»
Es una mala decisión poner un límite que no está avalado por ninguna señal. Si 
el límite de velocidad de una calle es el genérico debe ser el enrutador el que 
gestione ese límite. Si no corres el riesgo de que el límite genérico cambie y 
no sepamos que max-speed están puesto porque hay una señal y cuales se pusieron 
para ayudar a los enrutadores.


El dom., 28 oct. 2018 a las 15:09, Fco. Javier González Jiménez 
(mailto:fjavier...@hotmail.com>>) escribió:
Hola,

Gracias yopaseopor. Veo que estamos de acuerdo en que sirvan de referencia para 
editar y no que se trasladen de forma literal. En Granada es un verdadero 
desastre lo que se ha hecho con la clasificación de las calles, y podemos ver 
casi toda la ciudad como de tercera categoría, bastantes de segunda y primera, 
y no se corresponden a una distribución real, ni lógica, como ya le comenté al 
usuario que lo hizo y que se negó a corregir. Para él lo que importa es lo que 
diga el Ayuntamiento y no lo que tienes delante de los ojos ni el trabajo de 
los que te antecedieron editando, o la norma de OSM de crear redes de 
distribución que sea: primarias para unir distritos, secundarías para unir 
barrios, terciarias para las vías principales dentro del barrio. Ya me diréis 
de qué le sirve a un enrutador tener que elegir entre varias calles si todas 
tienen la misma categoría…

Desde luego lo ideal sería establecer los límites reales y el resto de 
características de las vías como propones en el caso de la iluminación, pero 
también de carril bici o bus, número de carriles, etcétera.

Creo que cuando usamos la categoría “residencial” los enrutadores toman una 
velocidad por defecto según se indica en la ley, pero cuando usamos una de 
categoría superior, que se supone que están para usar en exteriores de 
municipios, la velocidad por defecto de los  enrutadores va en consonancia a la 
categoría, por lo que si no se pone ninguna velocidad, los enrutadores pueden 
usar 80, 90 o 100 km en mitad de la ciudad, por eso propongo, que más vale 
poner el límite genérico de 50 a no poner ninguno  en el caso de las vías que 
se les ponga una categoría superior a “residencial” únicamente y dentro de los 
municipios. Aunque legalmente todo el mundo sabe la velocidad en ciudad, el 
enrutador te puede calcular la ruta por distancia (ruta más corta) o velocidad 
(ruta más rápida), para hacer los cálculos en un caso se fija en la distancia, 
en el otro en cuanto tardas en recorrerla, y para eso usa los tipos de vía y 
límites de velocidad. Cuando no existen usa los que tiene puestos por defecto 
según el tipo de vía.

Un saludo.



De: yo paseopor mailto:yopaseo...@gmail.com>>
Enviado el: domingo, 28 de octubre de 2018 6:52
Para: Discusión en Español de OpenStreetMap 
mailto:talk-es@openstreetmap.org>>
Asunto: Re: [Talk-es] Necesidad de poner límites en ciudad.

El hecho de poner un límite a las calles es útil, pero en este caso tiene un 
problema. Si especificas el límite a 50 km/h y el límite real es a 30 o a 40 
estarás dando una información errónea. Si no especificas límite sabremos que 
esas calles las debemos de completar/revisar.

La normativa de tráfico es muy clara: 50 km/h en vías urbanas. No necesitas un 
GPS que te lo especifique. Por lo tanto, con o sin datos el máximo en vía 
urbana en España (no sólo Granada) será de 50 km/h. Por lo que no ganas nada 
poniendo límites a cascoporro (porque este límite se 

[Talk-at] OSM Flyer Bestellung

[scubbx]

Hallo, liebe Mitmapper und Mitmapperinnen!

Der OSM-AT Verein wird in Kürze wieder neue OSM - Flyer bestellen.
(https://github.com/scubbx/osm-at-flyer)
Falls jemand weiß, dass eine größere Menge benötigt werden wird, kann
dies jetzt kundgetan werden, dann werden wir diese Menge in der
Bestellung berücksichtigen.

Beste Grüße,
Markus (ScubbX)


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

[Talk-it-trentino] SFScon, the Free Software Conference on Friday, 16th of November, 2018 at NOI Techpark, BZ

[IDM Suedtirol]

[Deutsche Version folgt weiter unten]
[Segue Versione in Italiano]

Dear SFScon friends,

we are proud to invite you to the #SFScon18, an opportunity to discuss
together with international experts about how Free Software, Open
Standards and Open Data can contribute to find disruptive Business
Models in the Industry and to create innovative products using Open
Technologies.

The conference will take place on *Friday, November 16th at 8:30 AM
(check in) in the NOI Techpark* (A.-Volta-Str. 13A Bozen / via A. Volta
13A Bolzano).

We are pleased to welcome internationally recognized experts from around
the world, like Wolfgang Burtscher (European Commission), Josh Simmons
(Google), Martin Englund (Palo Alto Networks), Patrick Masson (OIN),
Matthias Kirschner (FSFE), Molly de Blanc (FSF), Chris Lamb (Debian
GNU/Linux), Flavia Marzano (Roma Capitale) and many more.

Schedule details and tickets can be found on the events website:

http://www.SFScon.it

The LUGBZ will award a person who has substantially contributed to the
adoption and distribution of Free Software in South Tyrol with the
"*SFSaward*". And like last year the conference will also host a
*hackathon*, which will start during the conference day and will last
for 24 hours!

The event will be held in English only.

Participation is free of charge thanks to the DAVINCI project funded by
the European Funds for Regional Development (ERDF) and our sponsors:
Made In Cima, R3GIS, Würth Phoenix as well as 1006.org, Brandnamic, CIB,
Davide Montesin, Peer, QBUS, Telmekom and Yanovis

We are looking forward to seeing you in South Tyrol!

Kind regards,
Patrick Ohnewein

[Italiano]

Cari amici della SFScon,

è con grande piacere che vi invitiamo alla conferenza #SFScon18.
Un'occasione per discutere insieme ad esperti internazionali come il
Free Software, gli Open Standard e gli Open Data contribuiscono a creare
nuovi Modelli di Business e prodotti innovativi basati su tecnologie aperte.

La conferenza si svolgerà *venerdì 16 novembre, dalle ore 8.30 (check
in), presso il NOI Techpark* (via A. Volta 13A Bolzano).

Abbiamo tra i nostri ospiti diversi esperti di fama internazionale, come
Wolfgang Burtscher (European Commission), Josh Simmons (Google), Martin
Englund (Palo Alto Networks), Patrick Masson (OIN), Matthias Kirschner
(FSFE), Molly de Blanc (FSF), Chris Lamb (Debian GNU/Linux), Flavia
Marzano (Roma Capitale) e molti altri!

Dettagli del programma e i ticket per la conferenza sono disponibili sul
sito dell'evento:

http://www.SFScon.it

L'associazione Linux User Group di Bolzano-Bozen-Bulsan assegnerà ad una
persona che si è particolarmente distinta per l’utilizzo e la diffusione
del Software Libero nella Provincia Autonoma di Bolzano il premio
"*SFSaward*". Inoltre anche quest'anno ci sarà come evento collaterale
un *hackathon* che inizierà durante la giornata di conferenza e durerà
24 ore!

L'evento si svolgerà in lingua inglese!

La partecipazione è gratuita grazie al sostegno dato dal progetto
DAVINCI, finanziato dal Fondo Europeo per lo Sviluppo Regionale (FESR) e
grazie agli sponsor: Made In Cima, R3GIS, Würth Phoenix, 1006.org,
Brandnamic, CIB, Davide Montesin, Peer, QBUS, Telmekom e Yanovis

Non vediamo l'ora di incontrarvi alla SFScon!

Cordiali saluti
Patrick Ohnewein


[Deutsch]

Liebe Freunde der SFScon,

es freut uns sehr, euch zur #SFScon18 einladen zu dürfen. Die Konferenz
ist eine Gelegenheit um mit Experten über Freie Software, Offene
Standards und Open Data zu sprechen. Welche neue Geschäftsmodelle und
welche innovative Produkte können mit offene Technologien erstellt werden?

Die Konferenz findet am *Freitag, den 16. November ab 8.30 Uhr (check
in) im **NOI Techpark* (A. Volta-Str. 13A Bozen) statt.

Auch heuer dürfen wir unter unseren Gästen weltweit bekannte Fachleute
auf diesem Gebiet begrüßen. Darunter Wolfgang Burtscher (European
Commission), Josh Simmons (Google), Martin Englund (Palo Alto Networks),
Patrick Masson (OIN), Matthias Kirschner (FSFE), Molly de Blanc (FSF),
Chris Lamb (Debian GNU/Linux), Flavia Marzano (Roma Capitale) und viele
mehr!

Das detaillierte Programm und Tickets sind auf der Webseite verfügbar:

http://www.SFScon.it

Im Rahmen der SFScon wird der *SFSaward* von der LUGBZ, die Linux User
Group Bozen-Bolzano-Bulsan, an eine Person verliehen, die sich in
besonderer Weise für die Anwendung und Verbreitung von Freier Software
in Südtirol eingesetzt hat. Außerdem wird am Konferenztag ein
*Hackathon* als spezieller Track beginnen und Talente können sich für 24
Stunden messen und Preise gewinnen!

Die Veranstaltung wird auf Englisch abgehalten.

Die Teilnahme ist kostenlos. Dies ist Dank der Unterstützung aus dem
DAVINCI Projekt, welches vom Europäischen Fonds für regionale
Entwicklung (EFRE) finanziert wird, und Dank unserer Sponsoren (Made In
Cima, R3GIS, Würth Phoenix, 1006.org, Brandnamic, CIB, Davide Montesin,
Peer, QBUS, Telmekom und Yanovis) möglich.

Wir freuen uns auf euer Kommen!

Mit freundlichen Grüßen

Re: [Talk-es] Necesidad de poner límites en ciudad.

[Alejandro Moreno]

«más vale poner el límite genérico de 50 a no poner ninguno en el caso de
las vías que se les ponga una categoría superior a “residencial” únicamente
y dentro de los municipios»

Es una mala decisión poner un límite que no está avalado por ninguna señal.
Si el límite de velocidad de una calle es el genérico debe ser el enrutador
el que gestione ese límite. Si no corres el riesgo de que el límite
genérico cambie y no sepamos que max-speed están puesto porque hay una
señal y cuales se pusieron para ayudar a los enrutadores.



El dom., 28 oct. 2018 a las 15:09, Fco. Javier González Jiménez (<
fjavier...@hotmail.com>) escribió:

> Hola,
>
>
>
> Gracias yopaseopor. Veo que estamos de acuerdo en que sirvan de
> referencia para editar y no que se trasladen de forma literal. En Granada
> es un verdadero desastre lo que se ha hecho con la clasificación de las
> calles, y podemos ver casi toda la ciudad como de tercera categoría,
> bastantes de segunda y primera, y no se corresponden a una distribución
> real, ni lógica, como ya le comenté al usuario que lo hizo y que se negó a
> corregir. Para él lo que importa es lo que diga el Ayuntamiento y no lo que
> tienes delante de los ojos ni el trabajo de los que te antecedieron
> editando, o la norma de OSM de crear redes de distribución que sea:
> primarias para unir distritos, secundarías para unir barrios, terciarias
> para las vías principales dentro del barrio. Ya me diréis de qué le sirve a
> un enrutador tener que elegir entre varias calles si todas tienen la misma
> categoría…
>
>
>
> Desde luego lo ideal sería establecer los límites reales y el resto de
> características de las vías como propones en el caso de la iluminación,
> pero también de carril bici o bus, número de carriles, etcétera.
>
>
>
> Creo que cuando usamos la categoría “residencial” los enrutadores toman
> una velocidad por defecto según se indica en la ley, pero cuando usamos una
> de categoría superior, que se supone que están para usar en exteriores de
> municipios, la velocidad por defecto de los  enrutadores va en consonancia
> a la categoría, por lo que si no se pone ninguna velocidad, los enrutadores
> pueden usar 80, 90 o 100 km en mitad de la ciudad, por eso propongo, que
> más vale poner el límite genérico de 50 a no poner ninguno  en el caso de
> las vías que se les ponga una categoría superior a “residencial” únicamente
> y dentro de los municipios. Aunque legalmente todo el mundo sabe la
> velocidad en ciudad, el enrutador te puede calcular la ruta por distancia
> (ruta más corta) o velocidad (ruta más rápida), para hacer los cálculos en
> un caso se fija en la distancia, en el otro en cuanto tardas en recorrerla,
> y para eso usa los tipos de vía y límites de velocidad. Cuando no existen
> usa los que tiene puestos por defecto según el tipo de vía.
>
>
>
> Un saludo.
>
>
>
>
>
>
>
> *De:* yo paseopor 
> *Enviado el:* domingo, 28 de octubre de 2018 6:52
> *Para:* Discusión en Español de OpenStreetMap 
> *Asunto:* Re: [Talk-es] Necesidad de poner límites en ciudad.
>
>
>
> El hecho de poner un límite a las calles es útil, pero en este caso tiene
> un problema. Si especificas el límite a 50 km/h y el límite real es a 30 o
> a 40 estarás dando una información errónea. Si no especificas límite
> sabremos que esas calles las debemos de completar/revisar.
>
>
>
> La normativa de tráfico es muy clara: 50 km/h en vías urbanas. No
> necesitas un GPS que te lo especifique. Por lo tanto, con o sin datos el
> máximo en vía urbana en España (no sólo Granada) será de 50 km/h. Por lo
> que no ganas nada poniendo límites a cascoporro (porque este límite se
> sobreentiende). El 50 ya lo tienes.
>
> Sería interesante revisar la velocidad de las calles de Granada, a fin de
> poner el límite real en las calles.Aprovechad para poner la iluminación
> también si esta existiera (lit=yes)
>
>
>
> Por lo que hace referencia a las categorías poner de entrada lo que diga
> un ayuntamiento o administración sobre una vía puede fallar más que una
> escopeta de feria. Ahora bien, tener en cuenta esos datos, aprender, ver
> hacia dónde hace ir los flujos de tráfico el ayuntamiento, etc. me parece
> correcto y una forma adecuada de proceder, puesto que esos datos nos darán
> también las pistas sobre futuras actuaciones en determinadas vías
> (pacificaciones, etc.)
>
>
>
> Espero que mi opinión te haya servido :)
>
> yopaseopor
>
>
> ___
> 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: [Talk-es] Calles residenciales en Madrid

[Alejandro Moreno]

Entiendo que lo más sencillo es hacer esta modificación en bloque usando
una consulta para obtener todos los highway=living_street de Madrid y
añadirles las 2 etiquetas para las bicicletas, ¿no?

El dom., 28 oct. 2018 a las 7:57, yo paseopor ()
escribió:

> Saludos
> Creo recordad que el mensaje de Ikanian viene dado por algunos mensajes
> que escribimos en Telegram sobre la nueva ordenanza de tráfico del
> Ayuntamiento de Madrid, en el que se permite circular a las bicicletas por
> las vías residenciales (señal S-28, plataforma única, etc.) en sentido
> contrario sin ninguna otra indicación. Tal y como lo empecé a leer en la
> wiki pensé que con la primera etiqueta sería suficiente. Pero si se sigue
> leyendo la wiki se especifica que hace falta reforzarlo con el
> cycleway=opposite
> " These roads should normally also be tagged with oneway
> =yes and also
> oneway:bicycle =no
> ."
> A raíz del mensaje de Daniel he mirado la otra definición y es cierto que
> desde oneway:bycicle no se especifica  necesidad de otro etiquetaje.
> Considero que estaría muy bien unificar situaciones desde las dos páginas
> de la wiki y evidentmente actualizar sus traducciones
>
> Salut i bicis en sentit contrari
> yopaseopor
>
>
> [1] https://wiki.openstreetmap.org/wiki/Key:cycleway
>
>
> On Sat, Oct 27, 2018 at 12:52 PM dcapillae  wrote:
>
>> Hola, Héctor.
>>
>> Ikanian ha preguntado cómo etiquetar calles residenciales de un solo
>> sentido
>> donde las bicis pueden circular en ambos sentidos. En ese caso, bastaría
>> con
>> añadir «oneway:bicycle=no» al etiquetado de la vía. No ha mencionado que
>> haya carriles bici ni ninguna otra característica en particular. En
>> general,
>> con «oneway:bicycle=no» es suficiente para indicar que las bicis pueden
>> circular a contramano por una vía de sentido único (oneway=yes), es decir,
>> que puede circular en el sentido propio de la vía y en sentido contrario.
>>
>> Para conocer el etiquetado de casos particulares, habría que conocer los
>> detalles para poder precisar.
>>
>>
>>
>> -
>> 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] Borne de puisage

[Nicolas Moyroud]

Merci Vincent (l'autre !) pour ces précisions.

Tu en as de ces TOCs toi ;) 

Oui tout plein, mais j'ai même pas envie de me faire soigner !
Certaines communes ne respectent pas ce code couleur. Je pense par 
exemple à Senlis (60) où une bonne proportion des "vrais" poteaux 
incendie sont du même vert que les bornes de puisage, juste pour une 
raison esthétique : 
MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le 
rendu ça ! D'après mon contact la réglementation devrait bientôt obliger 
à respecter les codes par catégories d'hydrant. A voir...
pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) 
) je suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.


Pour les jaunes pas forcément évident de connaître la pression si ce 
n'est pas indiqué dessus (mais peut-être que ça l'est 
systématiquement?). Y'a moyen d'indiquer "supérieur à" pour une valeur 
numérique ? J'ai jamais fait ça...


On dirait que Disneyland aime mettre la pression. :-P

Nicolas


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

Re: [Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo rozcestníky

[Tom Ka]

Ahoj, tak se zacinam pomalu vracet k nekterym restum ve Fody.

- barevne bych rad urdzel "chybne" rozcestniky vsechno v sede jako
doposud aby to rozumne kontrastovalo s ostatnima vrstvama (primarne
fotkama nafocenych)
- za mne bych tam dle aktualni situace cyklo i silnicni nechal, obecne
chceme aby to lidi fotili
- sum je podle mne u cyklo primarne kvuli foceni "znaceni", v tom se
snazim o edukaci aby se nefotilo cokoliv ale podobne jako u pesich jen
tam, kde ej to nejak dulezite k pochopeni, orientaci nebo jako dukaz,
ze tam rozcestnik zaneseny v OSM realne neni. S tim souvisi, ze by
takoveto tabulky znaceni nemely byt zadavany do OSM (muj nazor, ale
asi tady uz taky probehlo).

Ja (jak dovoli cas) zpracovavam vsechny fotky, primarne ty, ktere to
vyhodi jako problem, ale uz jsem rikal, ze cyklo ma u mne mensi
prioritu (ciste proto, ze nejsem s to stihat uplne vsechno, co bych
chtel).

Zaroven jsme se ted s Marianem bavili, z eby nebylo spatne mit pro
vrstvu nafocenych (ale tim padem mozna i nenafocenych) lepsi
'advanced' mod, kde by se dalo lepe filtrovat co chci a nechci
sobrazit. Tim by se mozna neco z tvych prani dalo resit.

Zkus tedy prosim jeste preformulovat, ceho by jsi chtela pro sebe
dosahnout (skryt XX ve vrstve YY protoze mne nezajimaji) a uvidime co
s tim dal.

Bye

čt 6. 9. 2018 v 13:20 odesílatel majka  napsal:
>
> Dávám k úvaze, zda na openstreetmap.cz ve vrstvě chybných rozcestníků také 
> zvolna nezačít rozlišovat od sebe turistické rozcestníky a cyklo rozcestníky 
> barvou, jako to děláme u rozcestníků vyfocených (příklad tady). Případně zda 
> by nebylo lepší je z chybných zcela vynechat (tedy jen rozcestníky s pouze 
> bicycle=yes, jako je ten chybějící na tom odkazu) a do mapy nezobrazovat jen 
> cyklo rozcestníky, které se spárují.
>
> Ve "vyfocených" územích nám ty cyklo rozcestníky v téhle vrstvě trochu 
> začínají přidávat šum, a taky nafukují velikost v těch souborech gpx, které 
> se vytvářejí.
>
> Netuším, jestli chceme uživatele vyzývat k focení stejně, jako u turistických 
> rozcestníků. Řekla bych, že se soustavným zpracováním těch fotek momentálně 
> nikdo z nás nezabývá, resp. maximálně si autor ty  svoje fotky vždy nějak 
> zpracuje sám. Neříkám nezadávat do OSM, nebo nefotit (a neukazovat v mapě), 
> ale možná nevykazovat momentálně jako stejnou chybu, jako u turistických 
> rozcestníků (tedy chybějící foto a/nebo ref).
>
> 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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Mateusz Konieczny]

29. Oct 2018 11:43 by davefoxfa...@btinternet.com 
:

>  It's the gate which is the restriction. The problem is the gate
> doesn't have any subtags to indicate access.
>




I am using access=*, vehicle=*, bicycle=*, foot=*, opening_hours=* 




At least for gates in my region it is sufficient.

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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Dave F]

Hi

I've had similar in my area, also by Amazon Logistics *, where they 
added a short section around a gate like one you've indicated with 
access=private. I removed it as you can drive right up to the gate. This 
is tagging incorrectly for the router.


 It's the gate which is the restriction. The problem is the gate 
doesn't have any subtags to indicate access. It could be permanently 
open or locked shut. It might have a latch operable by all or a keypad 
entry allowing entry to specific people. etc.



* Personally, I think causing more harm than benefit, but that's for 
another thread.


Cheers
DaveF

On 29/10/2018 03:08, Jem wrote:


Re: https://www.openstreetmap.org/way/634085262 and several more like 
it in the area.


It seems that new, short ways have been introduced to replicate the 
purpose of the existing barrier nodes. i.e. to prevent routing for 
vehicular traffic. I believe it is incorrect and just adds complexity.


I plan to contact the user to discuss, but want to make sure I'm 
right. Can any experienced members please advise?



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


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

Re: [OSM-talk-fr] Borne de puisage

[Vincent de Château-Thierry]

Bonjour,

> De: "Nicolas Moyroud" 
> 
> La borne incendie étant un de mes TOCs ;-) 

Tu en as de ces TOCs toi ;)

> Je trouve plutôt bien ta proposition de tagging
> Vincent.
> Je pense que je vais rechercher mes bornes avec overpass pour mettre
> les tags que tu as proposé. D'autres avis ?

Je suis du même avis, ça colle avec ce que je fais par ailleurs comme par 
exemple ici :
https://www.openstreetmap.org/node/3374361144/history
J'ajoute une note car certains prennent ce schema de tags comme une description 
erronée d'une vraie borne incendie.

> Petite précision il existe aussi des bornes jaunes et bleues (je suis
> tombé sur ma première bleue récemment, encore jamais sur une jaune).
> J'ai posé la question à un géomaticien d'une collectivité que je
> connais
> et voici sa réponse :
> 
> - Les bornes de couleur "verte" sont des bornes de puisage (ce ne
> sont pas des poteaux incendie) équipé le plus souvent d'un compteur et qui
> serve à remplir les cuves des camions de lavage de rue, des cuves de
> traitement, etc.

Certaines communes ne respectent pas ce code couleur. Je pense par exemple à 
Senlis (60) où une bonne proportion des "vrais" poteaux incendie sont du même 
vert que les bornes de puisage, juste pour une raison esthétique :
https://www.google.fr/maps/@49.2046978,2.5869506,3a,42.4y,100.99h,82.01t/data=!3m7!1e1!3m5!1s20eyz88Sb-xhYClMxxFHBA!2e0!5s20170901T00!7i13312!8i6656

> Du coup à part la couleur, comment tagguer la pression supérieure à 8
> bars pour les jaunes et le fait que la borne est une borne d'aspiration
> pour les bleues ?

Pour les bleues, tu rajoutes :
fire_hydrant:pressure=suction cf. 
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant#How_to_map et 
pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) ) je 
suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.

vincent

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Rispetto la tua posizione, ma... puoi spiegarne i motivi? Quali sono i rischi, 
secondo te?

Comunque, /n /è pari a 5.3 (/quindi siamo ampiamente nello stesso ordine di 
grandezza/) e inoltre penso che i criteri di scelta debbano essere più 
qualitativi che quantitativi.

Prova anche a fare un overpass-turbo per /taxon /(/puoi limitarti ai nodes/) su 
Vienna, Londra o Parigi e vedi cosa salta fuori.

Ciao,

Sergio

On 2018-10-29 00:51, Martin Koppenhoefer wrote
>> On 28. Oct 2018, at 13:25, Sergio Manzi  wrote:
>>
>> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del 
>> dataset mipaaf la chiave "taxon".
> per un import escluderei l’ipotesi di appoggiare un tag usato n volte di meno.


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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Jem]

Your assumptions are spot-on. Thanks for the advice.

On Mon, 29 Oct 2018 at 20:12, Mateusz Konieczny 
wrote:

> 29. Oct 2018 04:08 by jem.maw...@gmail.com:
>
>
> Re: https://www.openstreetmap.org/way/634085262 and several more like it
> in the area.
>
> It seems that new, short ways have been introduced to replicate the
> purpose of the existing barrier nodes. i.e. to prevent routing for
> vehicular traffic. I believe it is incorrect and just adds complexity.
>
> I plan to contact the user to discuss, but want to make sure I'm right.
> Can any experienced members please advise?
>
>
> I am assuming that there is a gate here and there is no short segment
> where
>
> motor vehicles are forbidden - though weirder thing happened and maybe
> there is a sign
>
> meters before gate from each side "motor vehicles forbidden".
>
>
> I would consider it as a tagging for renderer, and it would be preferable
> to avoid it (tagging
>
> access on gate should be sufficient). On the other hand it is one of the
> least harmful ones
>
> so I would it phrase it "it is not necessary to do that" rather "it is
> harmful, stop immediately,
>
> I reverted your edits".
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 08:23, cascafico  wrote:
> 
> Se tra le linee guida del mappatore c'è l'essere minimalisti con i tag,
> allora mettiamo solo species, poi uno va lìì e si fa le sue deduzioni. In
> fondo si potrebbe giocare sulla sorpresa ;-)


varianti di tag per varie lingue è solo sensato quando si aggiungono 
informazioni. Per nomi ha senso per esempio, ma taxon e species sono tags 
formali, il loro valore non è un campo libero ma va scelto da una lista 
predefinita (la classificazione scientifica). Dando la classe specifica 
(species oppure volendo variante di specie) si registra tutto il necessario, 
aggiungere in più un species:it sarebbe come aggiungere un amenity:it=scuola ad 
un amenity=school

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

Re: [OSM-talk] Fwd: Short ways added to substitute barriers

[Mateusz Konieczny]

29. Oct 2018 04:08 by jem.maw...@gmail.com :


>
> Re: > https://www.openstreetmap.org/way/634085262 
> >  and several more like it in 
> the area.
> It seems that new, short ways have been introduced to replicate the purpose 
> of the existing barrier nodes. i.e. to prevent routing for vehicular traffic. 
> I believe it is incorrect and just adds complexity.
> I plan to contact the user to discuss, but want to make sure I'm right. Can 
> any experienced members please advise?




I am assuming that there is a gate here and there is no short segment where 


motor vehicles are forbidden - though weirder thing happened and maybe there is 
a sign 


meters before gate from each side "motor vehicles forbidden".





I would consider it as a tagging for renderer, and it would be preferable to 
avoid it (tagging

access on gate should be sufficient). On the other hand it is one of the least 
harmful ones

so I would it phrase it "it is not necessary to do that" rather "it is harmful, 
stop immediately,

I reverted your edits".


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

Re: [Talk-it-lazio] Digest di Talk-it-lazio, Volume 72, Numero 1

[Ubaldo]

Mi dispiace ma sono fuori Roma e non posso esserci
Nel frattempo buon Halloween a tutti

Ubaldo 

Inviato da iPhone

> Il giorno 25 ott 2018, alle ore 14:00, 
> talk-it-lazio-requ...@openstreetmap.org ha scritto:
> 
> Invia le richieste di iscrizione alla lista Talk-it-lazio
> all'indirizzo
>talk-it-lazio@openstreetmap.org
> 
> Per iscriverti o cancellarti attraverso il web, visita
>https://lists.openstreetmap.org/listinfo/talk-it-lazio
> oppure, via email, manda un messaggio con oggetto `help' all'indirizzo
>talk-it-lazio-requ...@openstreetmap.org
> 
> Puoi contattare la persona che gestisce la lista all'indirizzo
>talk-it-lazio-ow...@openstreetmap.org
> 
> Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
> in modo che sia più utile di un semplice "Re: Contenuti del digest
> della lista Talk-it-lazio..."
> Argomenti del Giorno:
> 
>   1. Prossimo Mapping party il 29 ottobre? (Flaminia Tumino)
>   2. Re: Prossimo Mapping party il 29 ottobre? (Martin Koppenhoefer)
> 
> 
> ___
> Talk-it-lazio mailing list
> Talk-it-lazio@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-lazio


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

Re: [OSM-talk-fr] Borne de puisage

[Nicolas Moyroud]

Bonjour à tous,

La borne incendie étant un de mes TOCs ;-)  j'ai quelquefois ajouté dans 
OSM des bornes vertes. Mais jusqu'à récemment je ne savais pas de quoi 
il s'agissait donc je les avais toutes tagguées en 
emergency=fire_hydrant... mais j'ai toujours eu la bonne idée de mettre 
colour=green ! Je trouve plutôt bien ta proposition de tagging Vincent. 
Je pense que je vais rechercher mes bornes avec overpass pour mettre les 
tags que tu as proposé. D'autres avis ?


Petite précision il existe aussi des bornes jaunes et bleues (je suis 
tombé sur ma première bleue récemment, encore jamais sur une jaune). 
J'ai posé la question à un géomaticien d'une collectivité que je connais 
et voici sa réponse :


- Les bornes de couleur "verte" sont des bornes de puisage (ce ne sont 
pas des poteaux incendie) équipé le plus souvent d'un compteur et qui 
serve à remplir les cuves des camions de lavage de rue, des cuves de 
traitement, etc.
- Les bornes de couleur "rouge" sont des poteaux incendie raccordé à un 
réseau sous pression (eau potable ou eau brute);
- Les bornes de couleur "jaune" sont des poteaux incendie raccordé à un 
réseau sous pression dit "surpressé" (eau potable ou eau brute) avec une 
pression supérieure à 8 bars;
- Les bornes de couleur "bleue" sont des poteaux incendie d'aspiration 
(dans une cuve, dans une rivière, etc.)


Du coup à part la couleur, comment tagguer la pression supérieure à 8 
bars pour les jaunes et le fait que la borne est une borne d'aspiration 
pour les bleues ?


Nicolas


Le 24/10/2018 à 21:34, Vincent Bergeot a écrit :
on trouve quelques (37) amenity=hydrant 
https://taginfo.openstreetmap.org/tags/amenity=hydrant#overview


et dans ce cas on ajoute hydrant:type=pillar

fee=yes/no

color=green :)

ref=

Avis ?



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[cascafico]

dieterdreist wrote
>> Osm non è un catalogo per naturalisti, ne' un entry point di wikidata.
>> Non pensate che un paio di semplici tag possa aiutare meglio per esempio
>> un turista?
> 
> il turista potrebbe usare un’app che mette insieme osm con altri fonti.
> Utilità per turisti non è un criterio forte, altrimenti mapperemo anche le
> critiche sui ristoranti ;-)

Be' la recensione di un POI è  un dato a dir poco dinamico e sicuramente
soggettivo, mentre una quercia è sempre una quercia ...e per parecchi anni a
venire :-)

Se tra le linee guida del mappatore c'è l'essere minimalisti con i tag,
allora mettiamo solo species, poi uno va lìì e si fa le sue deduzioni. In
fondo si potrebbe giocare sulla sorpresa ;-)








-

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

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