Re: [talk-au] Mapping hook turns for bicycles

[Andrew Davidson]

On 25/10/20 12:21 pm, Philip Mallis wrote:


What would be the best way to map this in OSM?


Try the lanes extension tagging:

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

Assuming that it's mapped as two one-way ways and there are two through 
car lanes at the point where the hook turn is (can't tell from the photo 
if there is a turning lane for cars):


lanes=2<--- lanes only counts lanes wide enough for cars
turn:lanes=right|through|through|through
cycleway:lanes=lane|lane|none|none
access:lanes=no|no|| <--- over rides the default access with no for 
the two bicycle lanes

bicycle:lanes=designated|designated||  <--- set the access for bicycles




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

[talk-au] Mapping hook turns for bicycles

[Philip Mallis]

Hi all, An increasingly common feature at intersections in Melbourne is installing facilities specifically for people riding bikes to be able to do a hook turn (I.e. waiting to the left side of the road before waiting for a green signal on the perpendicular road). Here is an example: https://www.flickr.com/photos/philipmallis/50515824341/in/photostream/ What would be the best way to map this in OSM? Thanks, Philip

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

Re: [talk-au] Mapping "off track" hiking routes

[Phil Wyatt]

Hi Folks,

 

For the Australian Tagging Guidelines can I suggest the following text as point 
4 under bushwalking and Cycling Tracks Notes….

 

4. Caution should be exercised if considering mapping of ‘tracks, routes and 
pads’ in remote reserves, as they may well be covered by management plans, 
standards or regulations which seek to minimise publicity. Such regulations or 
standards (AS2156)  may request that the location of such ‘tracks’ are not 
publicised on maps. You should seek clarification from the managing authority 
prior to adding such tracks.

 

Cheers - Phil

 

From: Little Maps  
Sent: Friday, 23 October 2020 9:35 PM
To: OSM Aust Discussion List 
Subject: Re: [talk-au] Mapping "off track" hiking routes

 

Hi folks, thanks for a very interesting discussion. It was great to hear from 
people who don’t often pipe up on the forum. Whilst it started off informative 
and insightful, it didn’t take long to reach into rhetoric about Russia and 
guns/maps don’t kill people ... neither of which is particularly helpful.

 

The original issue is clearly very important, so can I ask a much more basic 
question what text should we add to the Australian Tagging Guidelines, 
which give no guidance on the matter? The proportion of mappers who read the 
guidelines may be small but must be much larger than those who read this 
listserve. If the outcome of this discussion isn’t consolidated I for one would 
see this a somewhat wasted opportunity.

 

Best wishes Ian

 





On 23 Oct 2020, at 9:12 pm, Mateusz Konieczny via Talk-au 
mailto:talk-au@openstreetmap.org> > wrote:

 

 

 

 

23 Oct 2020, 11:59 by fors...@ozonline.com.au  :

A licence condition for data users is that they have a public policy for the 
Don'tRender tag

'That is fortunately impossible' why is it impossible?

Technically it is possible but it would require license

change that would be problematic

both from legal viewpoint (making such rule effective

would be tricky at best)

and unlikely to be accepted by osm community.

 

It is not impossible as in "can be established

with math proof to be illogically and therefore impossible"

but impossible as in "I will stop conflict in

Middle East by posting on Twitter'.

 

'Note that deleting existing paths with "I do not want them rendered" is not an 
acceptable edit'

I don't think anybody suggested it was.

This "solution" regularly appears in such

topics about illegal or unwanted paths.

'Russia does not get to decide whatever their military bases can be mapped and 
rendered in OSM.'

Nobody said that Russia should should be able to

It was just proposed that owners or operator 

of an area would be able to suppress 

rendering of objects there.

 

Its a point for discussion. What do you think should happen?

Paths existing but illegal to use should

be marked and tagged with access tags.

 

Path destroyed should be deleted from OSM.

 

Paths but existing should not be mapped in OSM.

 

Why single out Russia?

AFAIK they have laws forbidding mapping

locations of military bases.

 

PS thanks Steve for your second email.

thanks Phil for your clarification on 'illegal'

 

Tony

 

 

 

Oct 23, 2020, 10:18 by fors...@ozonline.com.au  
:

I am not morally responsible if an ex partner kills a woman in a women's 
refuge, he is, but I won't knowingly contribute to the process. And it doesn't 
wash with me to say they should put a guard at the door because I have mapped a 
refuge.

Not mapping ones that are private and not signed falls under not mapping 
private info.

 

See 
https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information

for an attempt to gather consensus opinion.

Re access=no, if I recollect correctly they still display in OSM, only slightly 
more red.

This changed, now they display greish (less prominent)

 

You probably wouldn't notice. I haven't checked data users such as Osmand and 
Strava.

Any decent router will not route over them.

Graeme

Thanks for your thoughts on 'how to'. I have given it some thought and don't 
have any really good answers. Please think of a better scheme.

 

I mentioned a Don'tRender=yes tag but worry it may be too complicated for the 
benefit that results but here goes:

 

a land owner or manager can add a Don'tRender=yes tag

OSM.org map would honour the tag in map mode

This is a bad idea.

A licence condition for data users is that they have a public policy for the 
Don'tRender tag

That is fortunately impossible.

 

By having the item visible at edit time it eliminates the cycle of addition and 
deletion and edit wars.

You can do that by mapping line and tagging it with note.

 

Note that deleting existing paths with "I do not want them rendered" is not an 
acceptable edit.

Let the mapping community decide whether the claim to be a land owner or 
manager is credible, if two organisations have credible claim to that then 

Re: [OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

[Philippe Verdy]

Sauf que NSI spécialise ses conseils par pays (le code pays est bien
visible dans ses filtres)
Donc le bogue est plutôt dans Osmose (pas dans NSI), qui oublie de chercher
avec le filtre pays approprié au lieu, **avant** d'aller faire un repli
vers les attributs internationaux.

De toute façon les tags wikipedia sont dépréciés et inutiles si on a un tag
wikidata (où on trouvera les liens des diverses éditions de wikipedia,
sahcnat aussi que les codes "langue" de wikipedia ne sont pas vraiment des
codes langue (au sens de BCP47) mais des alias locaux propre au système de
codes interwiki.

Wikimedia peut avoir des codes différents, non standards, persistant
uniquement parce que ce sont des labels de noms de sous-domaines ou des
codes internes de noms de base de données dont tout le monde se fout, ou
fusionnés là où BCP47 est bien plus strict et plus précis sur les règles de
repli et les codes valides: mais c'est très long (ça fait des années que ça
dure comme des bogues signalés mais dont la correction est sans cesse
repoussée) pour qui Wikimedia fasse les correction nécessaires (à la limite
le plus facile a juste été de créer des "alias" sur les noms de domaines
(CNAME ou redirections) en deux temps (d'abord du code standard vers
l'ancien code, puis dans le sens inverse), ensuite il faut des années pour
mettre à jour les nombreux modèles ou modules, réviser des données
d'internationalisation au sein même de Mediawiki ou de son installation
locale, informer les communautés, tester, tester encore, vérifier que le
renommage peut aussi être fait dans translatewiki.net, que les outils
d'export/import de TWN vers MediaWiki puis de déploiement dans Wikipedia ou
les autres projets fonctionnent avec les nouveaux codes, puis prévoir la
transition des noms de domaine canoniques, vérifier que les redirections
fonctionnent, puis enfin la mettre en oeuvre, patienter des mois pour que
les sites web externes (notamment les moteurs de recherche) se mettent à
jour, puis commencer à prévoir le démantèlement du support par redirection
de l'ancien code (s'il est en conflit avec un autre usage nécessaire),
nettoyer Wikidata... La dernière phase (qui nécessite un arrêt du wiki) est
le renommage de la base de données, qui elle aussi se fait en plusieurs
étapes.
Renommer un wiki de Wikimedia n'est pas simple du tout (même pour les
petits wikis) !

Du côté d'OSM c'est plus simple: éviter de référencer wikipedia et mettre
wikidata à la place et laisser Wikidata gérer ces liens sur sa base.

Donc pour les "brands" cela n'a plus d'importance et on élimine des tas de
redondances pas utiles dans OSM qui nécessitent des constantes corrections
(surtout en plus que Wikipedia n'est pas forcément précis: chaque édition
peut décider ou non de fusionner plusieurs sujets dans un même article,
avec plusieurs sections, et Wikidata ne sait pas encore gérer correctement
les liens vers les sections d'article pour la désambiguisation et les
fusions ou scissions faites dans une édition linguistique de Wikipédia ne
sont pas pertinentes pour les autres, ni non plus pour d'autres projets
liés comme Commons ou Wikivoyage.

Si vous avez des problèmes avec des liens Wikipédia (comme ceux qui
persistent à changer l'édition linguistique "pertinente" sans tenir compte
de la langue locale appropriée, qui est aussi en elle-même un sujet de
conflit dans les régions multilingues comme la Catalogne ou le Pays basque
en Espagne, ou encore la Corse, ou les langues co-officielles en Belgique,
en Suisse ou au Canada) et ne trouvez pas d'élément Wikidata associé à un
article pertinent, le lieux est de créer cet élément Wikidata manquant, le
lier correctement à l'article Wikipédia le plus approprié et éventuellement
chercher dans d'autres éditions ou d'autre projets comme Commons,
Wikivoyage, Wikinews (voire le Wiktionnaire pour certains toponymes
connus). Et ensuite éliminer tous les tags wikipedia et les remplacer par
un tag wikidata unique vers l'élément Wikidata que vous avez créé.



Le sam. 24 oct. 2020 à 22:17,  a écrit :

> Bonjour, les suggestions d'Osmose sont des suggestions.
>
> Ici le suggestion-index est une belle c... : wikidata est neutre.
>
> Le "bon" article Wikipédia est usuellement celui du pays où est la filiale.
>
> Je remets régulièrement des fr:Système U alors que iD suggère de
> modifier en en:Système U.
>
> C'est crétin : c'est une entreprise française exerçant en France.
> L'article en anglais est évidemment plus pauvre.
>
> Donc la bonne page c'est par défaut la page dans la langue par défaut du
> pays.
>
> Jean-Yvon
>
> Le 24/10/2020 à 21:55, Romain MEHUT - romain.me...@mailo.com a écrit :
> > Bonsoir,
> >
> > Dans ce changeset https://www.openstreetmap.org/changeset/92924630
> > j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la
> > déclinaison française. La réponse est que c'est une suggestion d'Osmose.
> >
> > Ne priorise-t-on pas la valeur fr (s'agissant du territoire français
> > bien sûr) ?
> >
> > Merci pour vos 

Re: [talk-au] Mapping "off track" hiking routes

[Graeme Fitzpatrick]

On Sat, 24 Oct 2020 at 11:17, Greg Lauer  wrote:

>
> The real world example for me is riding in the local forest in SE QLD and
> seeing other riders blindly following MapsMe on tracks that are closed (and
> tagged as such but not visible on the map).
>
> I am not suggesting a 'tagging to render' regime but just tagging a trail
> as closed is not having the effect we think it does. Short of adding an
> attribution to the trail name I am not sure how we resolve? Example xyz
> trail [Closed]
>

Just thinking about this.

One problem there, could be that people's mapping app's aren't up to date?

eg I use OSMand, which only updates ~monthly, & I may then only download a
new copy of the updated map 2 - 3 times a year, so those, now closed,
tracks could well still be shown as open & valid. Mind you, having said
that, they are then probably riding around a sign saying Track Closed, &
there's not much we can do about that!

Maybe they need more "Ignore Your GPS" signs! :-)
https://www.google.com.au/maps/@-27.9748643,153.164579,3a,15y,328.13h,87.25t/data=!3m6!1e1!3m4!1sjUXRGta4I6LJZu9rtBDXvQ!2e0!7i13312!8i6656?hl=en

Thanks

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

Re: [OSM-talk] User deleting many roads in Brazil

[Simon Poole]

You need to take this up with the DWG (d...@osmfoundation.org) once 
direct contact with the mapper in question has failed. Posting to this 
and the tagging list is not going to achieve anything except that you 
will receive pointers to the DWG.


Simon

Am 24.10.2020 um 17:54 schrieb Erick de Oliveira Leal:
Good morning, a user in Brasil is deleting many roads, I think all of 
its changeset need to be reverted.

Examples of bad changesets:
https://www.openstreetmap.org/changeset/92345676 

https://www.openstreetmap.org/changeset/ 
92703956 

https://www.openstreetmap.org/changeset/ 
92610958 



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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

[osm . sanspourriel]

Bonjour, les suggestions d'Osmose sont des suggestions.

Ici le suggestion-index est une belle c... : wikidata est neutre.

Le "bon" article Wikipédia est usuellement celui du pays où est la filiale.

Je remets régulièrement des fr:Système U alors que iD suggère de
modifier en en:Système U.

C'est crétin : c'est une entreprise française exerçant en France.
L'article en anglais est évidemment plus pauvre.

Donc la bonne page c'est par défaut la page dans la langue par défaut du
pays.

Jean-Yvon

Le 24/10/2020 à 21:55, Romain MEHUT - romain.me...@mailo.com a écrit :

Bonsoir,

Dans ce changeset https://www.openstreetmap.org/changeset/92924630
j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la
déclinaison française. La réponse est que c'est une suggestion d'Osmose.

Ne priorise-t-on pas la valeur fr (s'agissant du territoire français
bien sûr) ?

Merci pour vos éclairages.

Romain




___
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] Règle Osmose pour tag brand:wikipedia

[Frédéric Rodrigo]

Bonsoir,

Ça utilise les données de NSI.
Après ça n'a pas d'importance codé données, par définition les pages 
Wikipédia sont sont équivalente.
Mais je suis d'accord avoir le lien vers la page française facilité les 
choses coté réutilisation, mais ce n'est pas dans NSI.


https://nsi.guide/

Frédéric.


Le 24/10/2020 à 21:55, Romain MEHUT a écrit :

Bonsoir,

Dans ce changeset https://www.openstreetmap.org/changeset/92924630 
j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la 
déclinaison française. La réponse est que c'est une suggestion d'Osmose.


Ne priorise-t-on pas la valeur fr (s'agissant du territoire français 
bien sûr) ?


Merci pour vos éclairages.

Romain




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




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

[OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

[Romain MEHUT]

Bonsoir,

Dans ce changeset https://www.openstreetmap.org/changeset/92924630 j'ai 
demandé pourquoi la valeur au tag brand:wikipedia n'était pas la 
déclinaison française. La réponse est que c'est une suggestion d'Osmose.


Ne priorise-t-on pas la valeur fr (s'agissant du territoire français 
bien sûr) ?


Merci pour vos éclairages.

Romain




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

Re: [Talk-it] Incontro in Jitsi sabato 31/10 : UN Mappers, import dati e Josm avanzato

[Alessandro Sarretta]

Grazie Marco per la comunicazione e ad Andrea e tutto il gruppo 
piemontese per l'organizzazione!


Cercherò di esserci,

Ale

On 24/10/20 20:02, mbranco2 wrote:

Buonasera Lista,
sperando che stiate tutti bene, volevo segnalarvi che sabato 31 
ottobre, pomeriggio, faremo un incontro da remoto per parlare di UN 
Mappers, di import di dati in OSM, e di uso avanzato di Josm.
L'evento è nell'ambito degli incontri mensili OSM che da due anni 
facciamo regolarmente in Piemonte, ma vista la necessità di farli ora 
virtualmente, ci sembra giusto pubblicizzare la cosa anche sulla 
mailing list nazionale (della serie: cerchiamo di cogliere i risvolti 
positivi della situazione...)


I dettagli dell'incontro li trovate qui:
https://lists.openstreetmap.org/pipermail/talk-it-piemonte/2020-October/001077.html

Se quindi può interessarvi conoscere gli UN Mappers ed approfondire la 
conoscenza di Josm, ci sentiamo sabato prossimo su jitsi.


Un saluto!
Marco

___
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: [talk-au] Mapping "off track" hiking routes

[Andy Townsend]

On 24/10/2020 04:49, Brendan Barnes wrote:


Back to my original post which I was seeking advice on, I was 
requesting clarity of mapping an official hiking route, which a small 
section of it happens to not follow a defined track/path and a compass 
bearing is required. The hiking route is _official_: it has NSW NPWS 
signage which I have personally surveyed at the start of the segment 
denoting the "off track" route, the Australian Alps National Parks 
Cooperative Management Program publishes a map also detailing it, and 
all popular hiking guides have it listed, too. This small off track 
section forms part of the official route.


I've taken Andrew's advice and added fuzzy=500 to the way.



Thanks - there's nore usage of that than I was expecting (see 
https://taginfo.openstreetmap.org/keys/fuzzy ), although only 14 of 
those are lines rather than polygons.


On the other side of the world I've tended to use trail_visibility tags 
(which I think were mentioned earlier) to achieve the same thing; see 
e.g. https://www.openstreetmap.org/way/430909045 .  Something that 
renders the route but not the local path will show that as 
https://map.atownsend.org.uk/maps/map/map.html#zoom=16=54.40165=-0.93245 
.


Best Regards,

Andy


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

[Talk-it] Incontro in Jitsi sabato 31/10 : UN Mappers, import dati e Josm avanzato

[mbranco2]

Buonasera Lista,
sperando che stiate tutti bene, volevo segnalarvi che sabato 31 ottobre,
pomeriggio, faremo un incontro da remoto per parlare di UN Mappers, di
import di dati in OSM, e di uso avanzato di Josm.
L'evento è nell'ambito degli incontri mensili OSM che da due anni facciamo
regolarmente in Piemonte, ma vista la necessità di farli ora virtualmente,
ci sembra giusto pubblicizzare la cosa anche sulla mailing list nazionale
(della serie: cerchiamo di cogliere i risvolti positivi della situazione...)

I dettagli dell'incontro li trovate qui:
https://lists.openstreetmap.org/pipermail/talk-it-piemonte/2020-October/001077.html

Se quindi può interessarvi conoscere gli UN Mappers ed approfondire la
conoscenza di Josm, ci sentiamo sabato prossimo su jitsi.

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

Re: [OSM-talk-fr] Nouveau rendu osm.fr

[Philippe Verdy]

Personnellement je suis plus en faveur du rendu bitmap des surfaces
colorées de fond (avec un dégradé progressivement plus pâle pour les
faibles niveaux de zoom afin de masquer un peu mieux les détails locaux):
une seul rendu pour tout le fond en fait, sans aucun palissement, le
palissement est fait par un "alpha blending selon le niveau de zoom, du
coup une seule couche bitmap à calculer pour tout et la possibilité alors
de recalculer dynamiquement et facilement les niveaux de zoom plus faible.
C'est bien plus efficace et bien plus joli visuellement et plus rapide pour
tout le monde, le remplissage de polygones complexes est une opération très
couteuse en CPU qui marchera assez mal pour les mobiles si on veut
préserver leur autonomie).

On peut aussi faire une composition alpha-blending pour le rendu en
l'ombrage de la topographie d'altitude (mais pas pour les lignes d'iso)

En revanche ça ne marche mal pour les éléments linéaires (l'épaisseur des
traits doit changer, et on doit masquer plus de choses en dézoomant sinon
on superpose trop de choses), et pas du tout pour les éléments icônes et
textes posées encore par dessus : ces deux parties sont destinés à un rendu
vectoriel, y compris les lignes d'iso de topographie d'altitude).

Et pour les textes, bien séparer les textes localisables afin d'avoir une
sélection possible de la langue et un basculement facile: ce sera la couche
supérieure au dessus de la couche vectorielle des traits et des icônes (les
icônes sont aussi en format vectoriel afin de pouvoir tenir compte de la
résolution réelle pour les écrans HiDPI, mais elles ne posent pas de
problème car leur rendu bitmap pour la composition est facilement mise en
cache local pour économiser de la ressource locale de rendu, de la même
façon que se fait *déjà* le rendu bitmap des polices de textes dans tous
les moteurs de rendu de texte, ce ne sera donc pas répétitif et coûteux en
batterie.

La composition (blending) des couches est une opération de base de toutes
les cartes graphiques modernes (y compris tous les appareils mobiles) et
sinon c'est très optimisé au niveau de l'OS ou du navigateur pour un rendu
CPU (pour bureaux ou serveurs qui de toute façon sont aujourd'hui bien plus
rapides et pas trop limités en capacité de batterie), mais elle demande un
peu plus de mémoire: ce n'est aujourd'hui un problème que pour les
appareils mobiles très bon marchés ou anciens avec un vieil OS, ou un
affichage assez basique (mais ils sont aussi des tailles d'écran et
résolutions plus limitées, avec aussi une moins grande profondeur binaire
des couches colorimétriques, et c'est ce qui limite en pratique la mémoire
nécessaire).






Le sam. 24 oct. 2020 à 19:21, Yves P.  a écrit :

> Concernant les rendus spécialisés, François avait démarré une version
> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
> cf. https://2metz.fr/blog/cyclosm-vector-tiles/.
>
>
>
> Pourrait-on capitaliser dessus ?
>
>
> Je viens de voir un rendu vélo Polonais
>  (bitmap).
>
> En modifiant seulement le style, il doit être possible de réutiliser les
> tuiles CyclOSM vectorielles.
>
> __
> Yves
> ___
> 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] Fwd: Re: User deleting many roads in Brazil

[80hnhtv4agou--- via talk]

I tried but many conflicts appeared in JOSM I'm not experienced to do it. 
Please if someone can do it. It's not only this 3 changeset but most of that 
user.  
>>Saturday, October 24, 2020 10:57 AM -05:00 from Erick de Oliveira Leal < 
>>erickdeoliveiral...@gmail.com >:
>> 
>>Good morning, a user in Brasil is deleting many roads, I think all of its 
>>changeset need to be reverted.
>>Examples of bad changesets: 
>>https://www.openstreetmap.org/changeset/92345676  
>>https://www.openstreetmap.org/changeset/ 92703956
>>https://www.openstreetmap.org/changeset/ 92610958
>>___
>>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] Nouveau rendu osm.fr

[Yves P.]

> Concernant les rendus spécialisés, François avait démarré une version
> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
> cf. https://2metz.fr/blog/cyclosm-vector-tiles/ 
> .


> Pourrait-on capitaliser dessus ?

Je viens de voir un rendu vélo Polonais 
 (bitmap).

En modifiant seulement le style, il doit être possible de réutiliser les tuiles 
CyclOSM vectorielles.

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

Re: [OSM-talk-fr] Nouveau rendu osm.fr

[Yves P.]

> Non, mon idée est de gardée une base commune à périmètre identique de ce que 
> ça fait déjà, pour garder ça léger et réutilisable.
+1

Exemple d'affichage sur 2 sites web différents :

++--++
| Couche ferroviaire | Couche Cyclo | Couche point d'eau |
++--++
|   Couche "fond de plan" (OpenMapTiles) |
++

 ++
 | Couche point d'eau |
+++
| Couche ferroviaire |Couche Cyclo|
+++
|  Couche "fond de plan" (OpenMapTiles)   |
+-+


> Mais d'avoir des layers de données que l'on peut rajouter et combiner. J'en 
> ai fait deux en ce sens, les arbres (1 layer) et l'infra vélo (2 layers).

ça pourrait donner ça :
+-+
|   Couche Arbres |
+-+
|   Couche  Cyclo |
+-+
|  Couche "fond de plan" (OpenMapTiles)   |
+-+

> 
> 
>> Concernant les rendus spécialisés, François avait démarré une version
>> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
>> cf. https://2metz.fr/blog/cyclosm-vector-tiles/. Pourrait-on capitaliser
>> dessus ?
> 
> J'ai javais vu ça et le tien, le mien étant plutôt une expérience, mais je 
> trouve le résultat plutôt pas trop mal et je m'en sert moi même.

Plutôt que de faire une couche de tuiles par "POI", on pourrait avec les points 
d'eau inclus dans la couche cyclo.

Les points d'eau sont déjà dans la couche OpenMapTile 

Je viens de voir ça avec CyclOSM vector : cliquer sur l'icône carte en haut à 
droite. Tous les objets sont afficher et une bulle affiche les attributs

https://cyclosm.2metz.fr/static/index.html#19.11/48.8548288/2.3455783
https://projetdumois.fr/projects/2020-09_aed/map#map=19.11/48.8548288/2.3455783
https://www.openstreetmap.org/node/494251394


La couche OpenMapTile indique son nom, son type drinking_water, il manque 
essentiellement l'id OSM… et les autres tags (photos)

Il existe aussi un (plusieurs ?) serveurs de tuiles qui combine plusieurs 
couches à la volée.

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

[OSM-talk] User deleting many roads in Brazil

[Erick de Oliveira Leal]

Good morning, a user in Brasil is deleting many roads, I think all of its
changeset need to be reverted.
Examples of bad changesets:
https://www.openstreetmap.org/changeset/92345676
https://www.openstreetmap.org/changeset/
92703956

https://www.openstreetmap.org/changeset/
92610958

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

Re: [Talk-it] Blocchi stradali temporanei

[Cascafico Giovanni]

Purtroppo "Da lunedì la Slovenia chiude i confini con l’Italia  //
@ultimora - @covid19"

Il mar 16 giu 2020, 11:19 Cascafico Giovanni  ha
scritto:

> Tra Italia e Slovenia per il covid-19 sono stati mappati diversi
> blocchi stradali (reti e/o blocchi di cemento) in genere taggati così:
>
> access=no
> barrier=fence
> foot=yes
> note=COVID-19
>
> In questi giorni sembra siano stati rimossi; se li modifico solo
> aggiungendo
> disused:barrier=*  il routing rimane bloccato?
>
> Vorrei mantenere i tag per l'eventuale riuso, nella malaugurata
> ipotesi ritornassero i blocchi reali.
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] OSMF 2020 entre inquiétude et déception

[Philippe Verdy]

Le risque me semble bien plus élevé pour la Fondation OSM que pour la
Fondation Mozilla, qui n'a pas à supporter les mêmes frais
d'infrastructure, et a un nombre de soutiens bien plus élevés, aussi bien
au plan financier mondialement, que par le fait que les suites Firefox sont
souvent les seules aussi installées sur les serveurs et stations de travail
Linux, notamment les environnement de bureau virtualisés hébergés dans les
clouds des entreprises, qui donc acceptent aussi de maintenir une
contribution leur apportant aussi un support direct ou via un prestataire.
La Fondation OSM en revanche non seulement a des frais d'infra importants,
mais aussi se met à dépenser sans compter, en croyant que le tapis sur
lequel elle est encore confortablement installé pourra se reconstituer
aussi vite qu'il est dépensé. Il a fallu moins d'un an pour anéantir les
efforts des 10 ans.
Et pourtant la Fondation OSM ne finance pas un projet important pour elle:
la consolidation de son infrastructure pour bâtir un vrai CDN, et sinon
consolider la base de données. Elle en fait trop sur les éditeurs, et tente
maintenant d'opacifier ses prises de décisions et même ses justifications.
elle renforce le rôle dominant ed certains personnes dont la neutralité est
de moins en moins évidente.


Le sam. 24 oct. 2020 à 10:37, Jean-Marc Liotier  a écrit :

> Le "Is responsible for allocating $$ to diverse worthwhile software
> projects with grants and microgrants" de
> https://wiki.osmfoundation.org/wiki/Mission_Statement me gène également
> beaucoup. Je vois la Fondation comme arbitre de conflits et garant
> ultime de la license - or on sent le glissement vers ce qui pourrait
> finir par ressembler à la Mozilla Foundation - une course en avant dans
> toutes les directions en même temps plutôt que la dalle stable sur
> laquelle repose tout le reste.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-tr] Ortahisar

[ismail gürbüz]

İnsanlar memleketim olan nevşehirde Ortahisar ilçesinde bir fotoğraf
çekiliyor ancak instagramda konum etiketleyecekleri zaman Trabzon'daki
Ortahisar ilçesi etiketleniyor. Düzeltmeleri yapılması umuduyla.
___
Talk-tr mailing list
Talk-tr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tr

Re: [OSM-legal-talk] OdbL: Section 4.6, Does data/methods have to be released on public Produced Work?

[Tom Hummel via legal-talk]

Hi Lars-Daniel, Kathleen,

> The process doesn't seem to be trivial, since the edges of many polygons go 
> across areas, where no OSM elements could have been used as a reference. So 
> OSM dataset has either been changed or augmented using 3rd party reference 
> (knowledge, imagery, data etc.) to create the product. Those changes are 
> share-alike by ODbL.

The Trivial-Transf.-Guideline asks a trivial transformation to be
judged from a non-technical point of view. The quality of the
transformation itself should be non-trivial.

You explained, how the edges of some polygons go along edges that may
be very difficult to obtain, as they can’t be found within OSM. While
Kathleen seems to assume that they are directly and easily derived from
OSM data. Is that right?

OTOH that doesn’t seem important under the TTG. The TTG asks us to
estimate the modification or addition itself. You seem to be certain,
the modifications are only possible by combination of 3rd party data
and OSM data. From that perspective, they don’t seem very trivial to me.
Kathleen?

Thanks

Tom

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

Re: [talk-au] Mapping "off track" hiking routes

[Andrew Harvey]

On Sat, 24 Oct 2020 at 18:54, stevea  wrote:

> The real world example for me is riding in the local forest in SE QLD and
> seeing other riders blindly following MapsMe on tracks that are closed
> (and tagged as such but not visible on the map).
>
> They are not blind if they are riding.  They are not blind, but let’s
> agree foolish if they are riding on closed trails which are signed as
> closed trails (so signed on the ground), regardless of what MapsMe says,
> because MapsMe doesn’t make people ride on closed trails, people foolishly
> choosing to ignore signs that say “Closed Trail” are what make people ride
> on closed trails.  Their choice, not MapsMe “making them.”  Let’s remember
> that OSM is a data project, not one to curate a specific renderer to
> display with specific semiotics:  getting data correct is paramount.
>

We shouldn't degrade the quality of the OSM just because a downstream app
chooses not to show the access tag we've added, all we can do is keep
adding these kinds of tags and do things to improve the whole tagging
ecosystem to make it easier for data consumers to understand what the tags
mean and how to interpret them.

I am not suggesting a 'tagging to render' regime but just tagging a trail
> as closed is not having the effect we think it does. Short of adding an
> attribution to the trail name I am not sure how we resolve? Example xyz
> trail [Closed]
>
>
Send feedback to the app, post feedback, promote alternative maps and apps
that do respect the way things are tagged and which display this
information to users appropriately.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] OSMF 2020 entre inquiétude et déception

[Jean-Marc Liotier]

Le "Is responsible for allocating $$ to diverse worthwhile software 
projects with grants and microgrants" de 
https://wiki.osmfoundation.org/wiki/Mission_Statement me gène également 
beaucoup. Je vois la Fondation comme arbitre de conflits et garant 
ultime de la license - or on sent le glissement vers ce qui pourrait 
finir par ressembler à la Mozilla Foundation - une course en avant dans 
toutes les directions en même temps plutôt que la dalle stable sur 
laquelle repose tout le reste.




On 10/22/20 10:03 PM, severin.menard via Talk-fr wrote:

Bonjour,

Pour info, pour celles et ceux qui ne seraient pas membres de l'OSMF, 
j'ai publié cet article sur sa liste de discussion : 
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-October/007294.html
et également sur mon journal OSM : 
https://www.openstreetmap.org/user/SeverinGeo/diary


Les retours (positifs ou négatifs) sont toujours bienvenus.



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

Re: [talk-au] Mapping "off track" hiking routes

[stevea]

On Oct 23, 2020, at 6:14 PM, Greg Lauer  wrote:
> I have not seen any apps that, for example, display any attribute (or 
> graphic) to show a track is closed.

Try Carto (Standard) on a web page, how most users see OSM’s data as a map.  
When tagged access=no, for example, a highway=path does not show as red dots, 
but rather as faint grey dots.

> So the tagging of trails is not visible to most users, and we have the issue 
> of maintaining the tags as they are usually fluid (open, closed etc),

Mmmm, “false” (see above) and “usually false” (as closed trails usually stay 
closed trails, rather than be “fluid").  OSM maps “what is,” not “what we wish 
the world to be."

> The real world example for me is riding in the local forest in SE QLD and 
> seeing other riders blindly following MapsMe on tracks that are closed (and 
> tagged as such but not visible on the map).

They are not blind if they are riding.  They are not blind, but let’s agree 
foolish if they are riding on closed trails which are signed as closed trails 
(so signed on the ground), regardless of what MapsMe says, because MapsMe 
doesn’t make people ride on closed trails, people foolishly choosing to ignore 
signs that say “Closed Trail” are what make people ride on closed trails.  
Their choice, not MapsMe “making them.”  Let’s remember that OSM is a data 
project, not one to curate a specific renderer to display with specific 
semiotics:  getting data correct is paramount.

> I am not suggesting a 'tagging to render' regime but just tagging a trail as 
> closed is not having the effect we think it does. Short of adding an 
> attribution to the trail name I am not sure how we resolve? Example xyz trail 
> [Closed]

It sounds like you are suggesting ’tagging to render’ when you suggest 
something contrary to our wiki, which admonishes us to put into the name key 
“the name only.”  I ask “what effect DO you hope to have by tagging a trail as 
closed?”  If it is to “cause” potential users of a trail not to, I’d say you 
need to lower your expectations, as that is not what OSM either does or is 
designed to do.  When in the real world, pay attention to its signs.  Maps 
strive to be a good representation of the real world, but please do not confuse 
the map for the territory.

SteveA___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au