Re: [talk-ph] A Call to Correct Narratives aboutGeospatial Work in the Philippines

[Erwin Olario]

Looks like the YouTube video has been pulled down. Thankfully, someone made
an archive of the video here:
https://catdrop.drycat.fr/r/BMnz2gzJ#2ZFAiINWEgHDU+ncv1ZHj78vQFB0/weneUJRC6L+XxQ=

- - - - - - - - - - - - - - - - - - -
» email: erwin@ *n**gnu**it**y**.xyz*
 | gov...@gmail.com
» mobile: https://t.me/GOwin
» OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B


On Fri, Sep 4, 2020 at 10:00 PM Eugene Alvin Villar 
wrote:

> Hello all,
>
> Last September 1, Amazon Web Services (AWS) released an episode of their
> documentary series *Now Go Build* which highlighted the work done by the
> Humanitarian OpenStreetMap Team in the Philippines, especially in mapping
> the town of Guagua, Pampanga.
>
> You can see AWS' video here: https://www.youtube.com/watch?v=hqQwEOaKRas
>
> Several members of the OSM-PH community however have observed that there
> are missing and problematic narratives in the video related to the story it
> tells of geospatial and humanitarian workers in the country.
>
> Therefore, some of us have prepared and release the following statement:
> https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf
>
> Regards,
> Eugene
>
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-au] Are Health Centres, hospitals

[Graeme Fitzpatrick]

On Fri, 4 Sep 2020 at 20:25, Ewen Hill  wrote:

> We also have the grey area of Bush Nursing Centres that are clearly not
> hospitals but are the best place to head to in an emergency and may be the
> difference when you are looking at two equal sized communities. The ten
> staff sounds arbitrary.
>
> Shouldn't the difference be based on the capability of the premises to
> resuscitate, handle compound fractures and prolong life until the patient
> can be moved to a more appropriate facility rather than a "must have ten
> medical staff"?
>

Good points, Ewen.

Thanks, everyone - you've convinced me that I was looking at it the wrong
way & that these type of facilities should stay as hospitals.

  Further more, should it be defined as "an official hospital or the first
> place of medical support in a rural setting"?
>

You're probably correct but I think we'd have issues changing the main
definition of hospital, as it wouldn't suit the Western European / US point
of view :-(

As Cleary mentioned earlier: "Perhaps the Australian Guidelines should
permit the "hospital" tag where that is consistent with usage of the term
by the local community, would be a lot easier to do, so I'll make that
amendment if there's no major objection?

Thanks

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

[talk-au] Fwd: Are Health Centres, hospitals

[Graeme Fitzpatrick]

Resend to list - darn "reply" only going to the sender, not the list! :-(

-- Forwarded message -
From: Graeme Fitzpatrick 
Date: Sat, 5 Sep 2020 at 08:25
Subject: Re: [talk-au] Are Health Centres, hospitals
To: Andrew Davidson 





On Fri, 4 Sep 2020 at 18:02, Andrew Davidson  wrote:

> On 4/9/20 3:55 pm, Graeme Fitzpatrick wrote:
> > So does that make 2255 / 222 / or a different tally?
>
> It's 222 but I'm not sure how you got that, I get 200.


Thanks for clarifying that - my bad!

Did you use "amenity=hospital in Queensland" in the wizard?
>

No, just amenity=hospital, then dragged the manual bbox to more-or-less the
Qld border, but that then included 2-3 in Milne Bay area of PNG, & also a
number in NE NSW, which would explain the discrepancy.

Thanks

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

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Frederik Ramm]

Thank you all for your comments.

I have now added access=no to the paths leading up to the site, and
changed the site from tourism=viewpoint to military=bunker with an
access=no added to the site for good measure. (Though historic=ruins
would probably be as appropriate.)

I have also changed the name from "Post-WWII observation point" to
"Devil's Slide Bunker" which seems to be the commonly used name (and
anyway the previous name was not a name but a description).

There's a catalogue of bunker types on the wiki page and if anyone is in
the mood, feel free to add the correct one.

I think that in this particular case, even if the object is de-facto a
tourist destination, tagging it as such invites too much
misunderstanding (at least at a time when OSM data consumers, including
our own OSM-Carto rendering, are generally not sophisticated enough to
suppress advertising a tourist=* object when paired with access=no).

The discussion has shown that some of you share this opinion and some
would prefer to call a tourist spot a tourist spot even if illegal. I
think that a nuanced approach is probably approriate; having the
occasional illegal viewpoint on the map is not a big issue but in this
particular case we have a fat sign directly at the site telling people
to stay away, plus the site isn't off the beaten track but in a
tourist-y area so a big tourist symbol on the map could tempt many to
stop and look.

I hope this is something people can live with. You're welcome to
continue this discussion and if the community should come to a general
agreement about how to tag tourist attractions with no access then I'm
happy to see this changed.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-us] Trouble with getting Superior National Forest

[Doug Hembry]

On Wed, Sep 2, 2020 at 7:34 PM brad  wrote:


I'm with Kevin, SteveA, etc,  here.   In the part of the world that I
live, a map without national forest & BLM boundaries is very incomplete.
A useful OSM needs this.   The useful boundary would be the actual
ownership boundary, not the outer potential ownership boundary.   Messy, I
know.


+1
In fact, true for all protected areas.

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

Re: [OSM-talk-fr] La gestion des poteaux

[Francois Gouget]

On Thu, 3 Sep 2020, Philippe Verdy wrote:
[...]
> > Le nombre de cables se voit sur les photos aériennes.
>
> Pas toujours il y a plein de petites lignes même si on est capable de le 
> dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même 
> s'il y en a plus d'un seul.

On parle bien du 20kV, pas du 400V en aval des transformateurs de 
distribution ? Les lignes 400V sont effectivement ingérables. Pareil pour 
les lignes téléphoniques.


> Ca dépend beaucoup du fond (y compris la saison),

Ils sont effectivement beaucoup plus visibles sur les fonds sombres que 
les fonds clairs. C'est pas très pratique dans les vignobles, plus simple 
là où il y a des prairies. Mais même si on ne voit pas le nombre de cables 
à un endroit donné, on peut souvent les compter dans un autre champ un peu 
plus loin.

> Et de toute façon pas moyen de deviner les tensions transportées et le 
> mode (nombre de phases ou continu à certains endroits)

Comme dit précédemment la tension se déduit des transformateurs qu'on 
trouve sur la ligne.


> Les transfos sont également pas faciles à voir (et pas toujours montés en
> haut des poteaux,

Les transformateurs au sol sont au sol sont généralement en bordure des 
villes. Pour eux il faut compté sur les photos de rue.

Mais en campagne c'est huit voir neuf transformateurs sur 10 qui se 
trouvent en haut du poteau. Ceux-là font une généralement une verrue bien 
repérable sur l'ombre du poteau.

https://www.openstreetmap.org/edit#map=21/45.77978/-0.09650

Du coup ça fait un bon faisceau d'indices : verrue sur l'ombre + ligne 3 
cables qui arrive + proche d'un transformateur manquant sur Osmose + à 
coté d'un hameau => il y a un transformateur.


> et ce transfo est souvent caché dans la végétation

D'accord avec toi mais en remplaçant 'souvent' par 'parfois'. La verrue 
est aussi parfois moins visible quand le poteau est dans l'axe du soleil.


> parfois enterré sous une trappe difficile à voir (ou dans une armoire
> difficile à distinguer d'une armoire télécoms;

Tout ça ne concerne que les villes. Et dans ce cas c'est clair qu'i faut 
des photos de rue.


> Pour le gaz c'est plus facile car le chemin est marqué par des gros points
> jaunes ou chapiteaux jaunes sur un poteau très visibles presque partout et
> presque toujours en bordure de chemin ou en limite de parcelle sur une aire
> dégagée.

Oui. Et il y a moins de marqueurs que de poteaux électriques. Mais les 
marqueurs faits pour être vus d'hélicoptère sont assez rares et quand on 
n'a qu'eux je ne suis pas sûr que le tracé du pipeline soit bien précis. 
Pour bien faire il faut aussi avoir les marqueurs triangulaires (pedestal) 
mais ils sont très durs à repérer 'en grous il faut identifier 4 pixels un 
peu clairs en losange de part et d'autre d'une route proche du tracé 
supposé du pipeline).


> Sinon si j'ai des doutes, tant pis je ne relie pas:

Oui. Pareil.


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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

[Philippe Verdy]

Note que le gros des tests et déploiement de SoH en ce moment dépend de
serveurs mis en place par CloudFlare.
Hors CloudFlare c'est jsutement une des grosses victimes de la méga-panne
de Level3 (au moins en Europe).

ce qui marche plutôt pour l'instant (mais pas encore massivement déployé)
c'est DoT (DNS over TLS, plutôt TLS 1.3), IPSEC.

Il manque encore des composants essentiels: SNI, et surtout le déploiement
d'IPv6 qui est encore largement insuffisant pour servir le monde (et
notamment les IoT qui se développent à grande vitesse dans l'anarchie la
plus complète et sans grand contrôle et même en dépit des règles légales
concernant leur sécurité, la confidentialité, l'absense totale de contrôle
par l'utilsiateur tant ils sont opaques, jamais maintenus, et pas
désactivables).

DoH pour moi n'a aucune chance de marcher sans IPv6 partout (Note:
Microsoft est en train de supprimer de Windows le support des tunnels IPv6
pour la transition: 6to4, Teredo, etc. sont officielement listés comme
n'étant plus maintenus, et les serveurs de Microsoft qui les
supporte encore sont en forte déduction de capacité). Microsoft semble
faire ça pour forcer les FAI a enfin mettre à jour leurs box ou les
remplacer (mais dans de nombreux pays, les box ne sont pas fournis ni gérés
par les FAI, ils sont achetés et ceux qui les vendent ne les
maintiennent pas non plus, il y a beaucoup de produits défectueux et non
conformes dans ce qu'on trouve en ligne dont nombre de vendeurs chinois, et
même chez de nombreux importateurs qui achète juste sur catalogue et
livrent tels quels)

De fait aussi, nombre de'utilisateurs désactivent le support d'IPv6 sur
leur matériel parce qu'ils jugent qu'ils n'en ont pas besoin, ou parce
qu'un vendeur de VPN leur a dit que c'était nécessaire et qu'ils
"s'occupaient de tout" à leur place. Les VPN sont une arnaque commerciale
presque partout, avec de fausses promesses de sécurité, de confidentialité
ou d'optimisation des performances.

Que dire encore des FAI et fournisseurs de services français qui tardent
encore à déployer IPv6 (à peine 35% d'entre eux ont une allocation et un
bloc routable, mais au final ils ne les utilisent même pas pour leurs
clients et préfèrent déployer IPv6 à travers de tunnels IPv4 propriétaires,
bien plus lent donc que l'IPv4 natif). Orange en particulier ne fait pas
grand chose. Pas plus SFR. Seul Free semble avoir une offre native
dual-stack par défaut pour tout le monde (libre ensuite à chacun de le
désactiver s'il le veut). Et rien du tout concernant l'Internet mobile.

En fait tout ce monde là préfère vendre ses services en fournissant un
service DNS dont ils contrôlent et filtrent le contenu, et ils en supprime
la sécurité (aucune authentification, ils en profitent pour détourner du
trafic: Orange et SFR notamment). Et que dire des offres des FAI français
qui imposent l'usage (location ou achat) de leur modèle de box supporté
uniquement chez eux et dont ils controlent totalement le firmware (même sur
les box achetées et non louées). L'internet transparent et égalitaire n'est
pas une réalité, il est même de plus menacé, filtré, comme autant de
réseaux propriétaires où on voit ce que le fournisseur veut bien laisser
passer.

Dans ces conditions, IPv6 ne décolle pas. Et tout le monde continue de
dépendre sur des services IPv4 dont on peine à les maintenir en vie et à
les sécuriser: Internet est de plus en plus grévé d'erreurs de securité et
de défauts de maintenance, mais tout le monde "tolère" ça car en plus ces
problèmes servent à booster des ventes d'autres produits dits "de
sécurisation" (les VPN sont la dernière invention inutile, alors qu'ils
n'étaient au départ qu'une solution transitoire d'interconnexion, pas
destinée à optimiser les performances ni réellement apporter une vraie
sécurité auditable).

Bref j'ai de gros doute sur le fait de déployer DoH pour l'instant.
L'Internet n'est pas prêt (en tout cas même pas en France, il l'est
juste dans certains petits pays comme le Luxembourg, mais ces même pays
dépendent très largement de contenus et services qui ne sont pas
accessibles en IPv6, même en vitesse lente pour seulement envisager d'y
héberger DNS sur HTTPS ou TLS: meêm sans TLS, le DNS non sécurisé sur TCP
est tout aussi lent et sous-dimensionné, il n'y a pas assez de serveurs,
même en IPv4, et encore moins en IPv6 où pourtant ce serait plus facile
avec plein de ports et des milliards d'IP uniques pour multiplier les ports
sans nécessiter d'installer une multitude d'interfaces réseau et leur
allouer de très couteuses IPv4).

Si je reviens aux VPN, ils sont presque tous conçus pourtant pour héberger
leur tunnel en IPv4 (il n'y a pas assez de serveurs de tunnels en IPv6).

Il y a bien une parade: faire du TLS avec une encapsulation de TCP sur UDP
(solution déjà utilisée pour le streaming sur certains services).

Mais les gros sites fournisseurs ou hébergeurs de vidéos eux préfèrent
encore l'HTTP(S) sur IPv4 via des serveurs miroirs négociés chez les
fournisseurs 

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Ca c'est jsute le point de vue théorique. Rien à voir avec le pragmatisme
qui consiste à s'adapter à ce qu'on peut et sait faire en attendant de
développer mieux.

Ton problème de comptage est un point de vue théorique uniquement qui
oublie de prendre en compte le fait que tu peux parfaitement (et
facilement en plus!) identifier les doublons. C'est une réponse de celui
qui a juste pas envie, pas le courage de le faire. Pourtant c'est facile à
documenter, et utile dans un *long* processus de transition où on n'aura
jamais tout en même temps et tout de suite: c'est illusoire de croire
qu'OSM sera complet, sinon c'est que le monde entier est mort (et n'a donc
plus besoin d'OSM et n'a plus non plus aucun contributeur)!

On en reparlera quand le monde ne sera plus peuplé que de robots et que
l'espèce humaine aura disparu. Personne ne le souhaite ici et en fait on ne
le verra jamais sur OSM, OSM sera mort bien avant ça.

Être pragmatique c'est juste savoir minimiser l'impact en terme de
conséquences, et ici les conséquences sont théoriques (pour un esprit trop
borné à ne pas vouloir voir le reste et qui voudrait se comporter comme un
robot). Mais un humain n'est pas induit en erreur, et on peut parfaitement
apprendre à un robot à se comporter correctement, il faut juste lui dire et
le faire travailler un peu plus, à peine plus en fait car c'est facile à
trouver dans la base).


Le ven. 4 sept. 2020 à 18:20, Vincent de Château-Thierry 
a écrit :

>
> > De: "Philippe Verdy" 
>
> > Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> > méthodes sont indiquées comme valides et approuvées. Certes il y a
> > des bogues dans le rendu puisque suivant les cas c'est l'une ou
> > l'autre méthode qui est visible; mais si on voit les deux c'est
> > moins grave que ne rien voir du tout.
>
> Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles
> sont mutuellement exclusives : si on en choisit une pour un objet du
> terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours
> le "one feature, one element".
>
> > Et même hors du rendu (par exemple pour les recherches) cela n'a pas
> > de conséquence: on trouve deux objets pratiquement au même endroit.
>
> Il y a au moins une conséquence : 2 objets pour la même réalité terrain,
> ça fausse les statistiques. Avec un polygone "parking" incluant un point
> "parking" la réponse à la simple question "combien y a t-il de parkings
> dans la commune ?" devient compliquée, alors qu'elle devrait être
> simplement la somme des noeuds "parking" et des polygones "parking" si on
> respecte le principe du "one feature, one element".
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

[Philippe Verdy]

A mon avis je ne pense pas qu'on ait besoin de l'avis international (peut
importe dans quelle langue) pour décrire ce qu'on a en France et nos
besoins (bien que la solution française est pratiquement similaire chez nos
voisins, européens, ou nos outremers qui sont assez isolés de leurs
voisins, sauf en Angleterre et même pas tout le Royaume-Uni).

On peut décider ici pour la France (et pour d'autres pays francophones qui
nous suivent, même si par exemple les belges devraient en discuter aussi
avec les néerlandophones, les suisses avec les germanophones).

Donc aucune opposition à fixer ça dans la page française (en laissant toute
fois la place à d'autres pays francophones, notamment le Canada, la
Belgique en marquant clairement ce qui s'applique en France dans sa
section, et permettant des sections spécifiques pour d'autres pays, avec
d'autres exigences locales).

OSM applique une politique de respect des conditions locales: partout en
géographie, il ne faut pas toujours généraliser ce qui ne doit pas l'être
et laisser la place à des extensions ou exceptions et essayer de borner ce
qui est applicable (et le minimum applicable c'est la juridiction
applicable, nationale ou d'état, même si dans l'UE beaucoup de principes
réglementaires sont basés sur des règles européennes qui s'imposent du fait
du marché unique et de très nombreuses normes obligatoires assorties de
sanctions si elles ne sont pas appliquées dans une juridiction donnée avant
un temps imparti, une fois les temps de négociation, amendements ou recours
passés et portés dans les instruments de ratification et acceptés par les
autres pays ou négociés par échange d'autres exceptions pour eux).
Cependant au final, même si l'UE a plein de directives, elles ne sont pas
immédiatement applicables et au final c'est toujours la juridiction locale
qui fait loi et règles les litiges (même s'il y a encore ensuite des
recours européens en dernier ressort, qui peuvent alors imposer des
changements réglementaires ou des sanctions à une juridiction locale qui
devra modifier ses instruments de ratification et en notifier l'UE; de même
la France, comme les autres pays de l'UE, est tenue de publier les
décisions faisant jurisprudence, afin que les autres pays aussi puisse les
connaitre et éventuellement commencer des recours contre leur application
trop stricte ou trop large; en pratique ce sont les grands groupes de
cabinets juridiques qui se chargent de faire le tri et ensuite presser l'UE
de modifier les directives pour obliger les gouvernements à renégocier
certains accords ou les faire réviser dans leurs parlements pour les lois
ou par de nouveaux arrêtés d'application).

Bref, on peut décider ici ce qui vaut pour la France, mais rien n'interdit
d'en aviser les autres listes (d'autant que tout le monde n'est pas non
plus francophone, même en France au sens légal, et nombreux sont ceux qui
se sentent plus à l'aise avec une autre langue de travail, ou simplement
ils préfèrent passer plus de temps à coopérer à l'international et ne pas
se disperser sur plein de listes). Donc leur faire savoir qu'une modif a eu
lieu dans la page de doc francophone du wiki suite à un échange ici (ou sur
la petite partie francophone du forum en ligne d'OSM si certains le
suivent).

Unetelle décision peut aussi se faire savoir par le bulletin d'actus OSM
(lui aussi à la base hébergé sur le wiki mais très résumé et qui au moins
aura une traduction dans plus de langues : à charge ensuite pour les autres
de nous lire ou se faire aider pour comprendre les traductions. De toute
façon sur notre wiki, on peut aussi créer une sous-page qui sera traduite
en français et anglais (néerlandais, allemand, italien, catalan ou espagnol
pour les motivés, et même portugais pour ce qui concerne la Guyane et nos
voisins brésiliens bien que la Guyane soit très pauvre en rond-points et
que la communication c'est d'abord par voie fluviale ou maritime) et
référencée depuis la page anglophone sans avoir besoin de trop la
restructurer: la doc du wiki est d'abord centrée sur des aspects génériques
(tous pays) mais a vocation à avoir des sous-pages appropriées s'il le fait
pour certains pays (indépendamment des langues utilisées pour l'original ou
ses traductions complètes ou partielles).





Le ven. 4 sept. 2020 à 19:01, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> C'est la question que je me pose aussi.
> On a les pages route=bus
>  et FR:Bus
> .
> Puis d'autres comme relation route
>  pour les  Itinéraires
> cyclables et randonnées
> ,
>
> Si notre souci est franco-français, et pas juste francophone, quelle est
> la bonne pratique ? Met-on un paragraphe "Rond point" dans ces pages en
> précisant "bonne pratique en France" ? Doit-on d'abord s'assurer 

Re: [OSM-talk-fr] Rond point et relations routes

[Georges Dutreix via Talk-fr]

C'est la question que je me pose aussi.
On a les pages route=bus 
 et FR:Bus 
.
Puis d'autres comme relation route 
 pour les 
Itinéraires cyclables et randonnées 
, 

Si notre souci est franco-français, et pas juste francophone, quelle est 
la bonne pratique ? Met-on un paragraphe "Rond point" dans ces pages en 
précisant "bonne pratique en France" ? Doit-on d'abord s'assurer de 
l'accord sur la page EN ?




Le 04/09/2020 à 05:52, Gad Jo a écrit :
Pour faire les modifications sur les pages EN faut il faire une 
demande de consensus via une page de discussions ? Quitte a passer sur 
l'hebdo osm pour stimuler les réponses

Il me faut juste quelques conseils et je me lance


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Vincent de Château-Thierry]

> De: "Philippe Verdy" 

> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a
> des bogues dans le rendu puisque suivant les cas c'est l'une ou
> l'autre méthode qui est visible; mais si on voit les deux c'est
> moins grave que ne rien voir du tout.
 
Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles sont 
mutuellement exclusives : si on en choisit une pour un objet du terrain, alors 
il ne faut pas utiliser l'autre pour le même objet. Toujours le "one feature, 
one element".
 
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas
> de conséquence: on trouve deux objets pratiquement au même endroit.

Il y a au moins une conséquence : 2 objets pour la même réalité terrain, ça 
fausse les statistiques. Avec un polygone "parking" incluant un point "parking" 
la réponse à la simple question "combien y a t-il de parkings dans la commune 
?" devient compliquée, alors qu'elle devrait être simplement la somme des 
noeuds "parking" et des polygones "parking" si on respecte le principe du "one 
feature, one element".

vincent

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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

[Denis Chenu via Talk-fr]

Je gère des serveurs dont des serveurs DNS,

Cependant : je ne me permettrais ni d'évaluer la qualité technique de DOH.
Je laisse cela à des personnes compétentes.

Denis
Le 04/09/2020 à 15:18, Philippe Verdy a écrit :
> Ce n'est toujours pas complètement réglé. Notamment des fournisseurs
> de DNS sécurisés (dont bon nombre de services DNS over HTTPS qui
> perdent leurs sessions et on beaucoup de mal à les reconencter) sont
> toujours impactés.
>
> Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou
> par Microsoft sous Windows 10, mais visiblement il n'a pas encore la
> capcité nécessaire de supporter le traffic nécessaire: les serveurs
> DOH "tombent" les uns après les autres par surcharge (plus assez de
> ports TCP). A mon avis le DOH est une mauvaise solution (à cause de
> l'utilisation de TCP) et le plus fiable reste encore le DNS sur UDP
> qu'on peut authentifier malgré tout avec les signatures numériques et
> les certificats PKI.
>
> J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez
> Cogent (et sur certaines passerelles de Cogent vers
> l'Afrique transitant par OpenTransit/Orange). Là encore il y a
> toujours un problème (et certains pays africains sont encore quasi
> coupés du monde (il y a aussi des problèmes ailleurs comme en Syrie ou
> Corée du Nord, mais là c'est beaucoup plus lié aux mesures politiques,
> ou des mesures d'urgence dans la cyberguerre qui se déroule en ce
> moment, que ce soit entre US et Chine, ou Chine et Taiwan, et en fait
> pas tellement pour ce qui concerne la situation politique locale,
> puisque même les groupes violents ou extrémistes ont besoin de ces
> réseaux et ne les sabottent pas, bien au contraire, même s'ils veulent
> en prendre le contrôle pour pouvoir les utiliser encore davantage: les
> mesures prises le sont par leurs voisins).
>
>
> Le ven. 4 sept. 2020 à 09:39, Christian Quest  > a écrit :
>
> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était
> extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink,
> un gros
> fournisseur de tuyaux.
>
> 
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> -- 
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Arnaud Champollion]

Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :
Si par contre tu parles d'objets de nature surfacique telles qu'un 
parking ou un jardin, on est d'accord.


Pour une école je ne sais : tu mets ça sur le landuse ?



Pour une école, je fais un polygone avec amenity=school sur l'emprise de 
l'établissement avec ses bâtiments et surfaces extérieures, par exemple 
https://www.openstreetmap.org/way/483979733







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

[OSM-talk-fr] Caméras - Contributions de Sous-surveillance.net

[Vucod via Talk-fr]

Bonjour,

Le site sous-surveillance.net a récemment accepté que les données que ces 
contributeurs ont récolté soient importées dans OpenStreetMap.
Il s'agit de 10 000 caméras et caméras ALPR localisés essentiellement en France 
et récoltés par des contributeurs locaux.
C'est-à-dire que les caméras ont été ajoutées manuellement par les 
contributeurs. Notez également, que les données récoltées correspondent déjà 
aux tags de OpenStreetMap.

Je souhaite donc importer ces données. Je l'ai déjà fait il y a quelques mois 
pour la ville de Bruxelles. 
La qualité des données a été vérifiée, les doublons ont été exclus et cet 
import-là n'a pas reçu de retour négatif après l'import.

Vous pouvez trouver plus d'information ici: 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/sous-surveillance.net et 
n'hésitez pas à commenter la page.

Vucod

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Et noter que le "POI" ne désignent pas la cartographie physique, ils sont
juste des points au centre d'une aire (de taille non spécifiée) qui n'est
pas délimitée nécessairement par un objet physique (un seul batiment,
plusieurs, des services annexes rattachés, y compris leurs boites aux
lettres qui peuvent être ailleurs, et qui ne couvrent pas non plus leur
aire d'influence ou de chalandise et ne dit souvent rien de leur importance
relative vis à vis de leur environnement économique ou social)

Hors on ne peut pas taguer comme un POI tous les objets physiques et les
découper ou regroupe ne fait souvent pas de sens non plus car on n'est pas
capable de faire une réelle délimitation: c'est pour ça qu'on les réduit à
un seule noeud assez souvent. Pourtant ils peuvent être bien plus grands et
avoir eux-même une structure interne plus fine (exemple: une école ou une
zone hospitalière avec divers services, et même pas mal de zones
commerciales: l'usage des lieux n'est pas forcément unique non plus et on
ne peut pas séparer géographiquement ces services qui pourtant y sont
situés et se recouvrent partiellement, que ce soit territorialement ou dans
le temps).

On ne peut donc pas déprécier une méthode plutôt qu'une autre.
Malheureusement, traiter les points et les polygones/surfaces, c'est très
différent dans les rendus. Et pour créer des filtres efficaces, ce n'est
pas facile car on ne les verra pas toujours simultanément dans toute
sélection d'objets depuis la base (au plan purement géométrique, les points
sont trop petits ils peuvent être oubliés, les surfaces sinon ne sont
qu'indicatives le plus souvent et parfois trop grande relativement à
l'importance d'autres objets voisins ou qui y sont inclus: on ne peut pas
figer ces règles de filtrage dans les rendus, donc autant permettre cette
flexibilité: c'est aux rendus qui voient les deux types d'objets de mieux
gérer les filtres au cas où il voient des doublons, et ils n'en voient pas
toujours puisqu'ils ne sélectionnent pas tous la même chose).

Enfin les POI tagués comme simple noeud n'ont toujours indication d'une
taille relative (au moins un rayon), et leur "importance" relative par
rapport au reste ne peut pas non plus être décrétée par le système de
tagging, sinon on aurait partout le même carte unique dans tous les rendus,
les mêmes filtres appliqués à tous les niveaux de zopom, et trop de détail
visibles pour tous les usages qui n'en ont pourtant pas besoin: ce qu'on
ferait serit de recréer une carte "à la Google" avec ses critères imposés
ou téléguidés par des choix externes (ou des politiques commerciales selon
les intérêts des autres et pas du visiteur réutilisateur; OSM serait
beauoup moins riche).

Le ven. 4 sept. 2020 à 17:25, Philippe Verdy  a écrit :

> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a des
> bogues dans le rendu puisque suivant les cas c'est l'une ou l'autre méthode
> qui est visible; mais si on voit les deux c'est moins grave que ne rien
> voir du tout.
>
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
> conséquence: on trouve deux objets pratiquement au même endroit.
>
> C'est similaire à d'autres objets où on tague les deux (y compris les
> "labels" qui ont été utilisés et sont encore approuvés dans les relations
> boundary même si on n'en a plus besoin pour les rendus les plus courants ni
> pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
> être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
> ils trouvent les deux objets (de type différents) au même endroit et la
> façon dont ils gèrent les priorités d'affichage (car de toute façon ils
> font toujours des choix, ils ont tous des filtres et ce sont ces filtres
> qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
> besoin puisqu'ils ne "voient" qu'une partie des objets).
>
> Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
> de **détourner** des tags prévus pour désigner tout autre chose a fin de
> forcer un affichage. Ce n'est pas du tout le cas ici: les deux
> méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
> pour l'autre.
>
>
> Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "Philippe Verdy" 
>>
>> > Ce rappel était inutile. Ce sont deux objets de nature différente
>> > même s'ils ont le même nom mais pas la même fonction. Et ce
>> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
>> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
>> > de volumétrie et il n'y a pas d'ambiguité réelle.
>>
>> Dans ton précédent mail tu dis : "un point parking trouvé dans une
>> surface parking" donc on parle bien de 2 objets décrivant la même réalité
>> sur le terrain. Leur nature géométrique est différente mais ce sont bien
>> des doublons sémantiques, chose qu'on cherche à 

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
méthodes sont indiquées comme valides et approuvées. Certes il y a des
bogues dans le rendu puisque suivant les cas c'est l'une ou l'autre méthode
qui est visible; mais si on voit les deux c'est moins grave que ne rien
voir du tout.

Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
conséquence: on trouve deux objets pratiquement au même endroit.

C'est similaire à d'autres objets où on tague les deux (y compris les
"labels" qui ont été utilisés et sont encore approuvés dans les relations
boundary même si on n'en a plus besoin pour les rendus les plus courants ni
pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
ils trouvent les deux objets (de type différents) au même endroit et la
façon dont ils gèrent les priorités d'affichage (car de toute façon ils
font toujours des choix, ils ont tous des filtres et ce sont ces filtres
qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
besoin puisqu'ils ne "voient" qu'une partie des objets).

Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
de **détourner** des tags prévus pour désigner tout autre chose a fin de
forcer un affichage. Ce n'est pas du tout le cas ici: les deux
méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
pour l'autre.


Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Philippe Verdy" 
>
> > Ce rappel était inutile. Ce sont deux objets de nature différente
> > même s'ils ont le même nom mais pas la même fonction. Et ce
> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
> > de volumétrie et il n'y a pas d'ambiguité réelle.
>
> Dans ton précédent mail tu dis : "un point parking trouvé dans une surface
> parking" donc on parle bien de 2 objets décrivant la même réalité sur le
> terrain. Leur nature géométrique est différente mais ce sont bien des
> doublons sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par
> Christian.
>
> > Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> > limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> > nettement avoir deux objets (de nature différents mais positionnés
> > presque au même endroit, cela n'induit personne en erreur) que de
> > n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> > cherche avec les outils qu'on a actuellement (en attendant qu'ils
> > soient corrigés).
>
> Le fait de "voir ou pas" les objets est de la responsabilité du logiciel
> qui les affiche, ça n'est pas au contenu lui-même de palier les limites des
> chartes graphiques. Sinon ça revient à tagguer pour le rendu.
>
> vincent
>
> ___
> 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] Affichage d'un name suivant le rendu

[Vincent de Château-Thierry]

Bonjour,

> De: "Philippe Verdy" 
 
> Ce rappel était inutile. Ce sont deux objets de nature différente
> même s'ils ont le même nom mais pas la même fonction. Et ce
> "doublon" n'est pas gênant: si on crée une surface délimitée par un
> polygone, ce n'est pas un noeud de plus qui change la donne en terme
> de volumétrie et il n'y a pas d'ambiguité réelle.

Dans ton précédent mail tu dis : "un point parking trouvé dans une surface 
parking" donc on parle bien de 2 objets décrivant la même réalité sur le 
terrain. Leur nature géométrique est différente mais ce sont bien des doublons 
sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par Christian.

> Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> nettement avoir deux objets (de nature différents mais positionnés
> presque au même endroit, cela n'induit personne en erreur) que de
> n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> cherche avec les outils qu'on a actuellement (en attendant qu'ils
> soient corrigés).

Le fait de "voir ou pas" les objets est de la responsabilité du logiciel qui 
les affiche, ça n'est pas au contenu lui-même de palier les limites des chartes 
graphiques. Sinon ça revient à tagguer pour le rendu.

vincent

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

Re: [OSM-talk] A Call to Correct Narratives about Geospatial Work in the Philippines

[john whelan]

I have noticed that HOT does tend to promote the idea that HOT mapping is
bringing maps to areas that haven't been mapped before.  The emphasis is on
enthusiasm and tapping into the mappers before they move on to something
else.  This approach does get a fair bit of mapping done and the quality
side is improving.

I suspect that mix that in with a journalistic approach that tends to be
cost driven and simplify and the result is what you see.

There are some more serious HOT mappers and as you note quite a few
contributions to OpenStreetMap come from trained professional mappers
working for governments.

I think all we can do is recognise there is a range of contributors to
OpenStreetMap but how you get this recognised I'm not sure.  Talk nicely to
the BBC perhaps and ask them nicely to create a program on the subject?

Create a video?  To get a professional looking video is more complex that
it might sound at first glance.

Cheerio John

On Fri, Sep 4, 2020, 10:08 Eugene Alvin Villar  wrote:

> Hello all,
>
> Last September 1, Amazon Web Services (AWS) released an episode of their
> documentary series Now Go Build which highlighted the work done by the
> Humanitarian OpenStreetMap Team in the Philippines, especially in mapping
> the town of Guagua, in the province of Pampanga.
>
> You can see AWS' video here: https://www.youtube.com/watch?v=hqQwEOaKRas
>
> Several members of the OSM-PH community however have observed that there
> are missing and problematic narratives in the video related to the story it
> tells of geospatial and humanitarian workers in the country.
>
> Therefore, some of us have prepared and released the following statement:
> https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf
>
> Regards,
> Eugene
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] A Call to Correct Narratives about Geospatial Work in the Philippines

[Eugene Alvin Villar]

Hello all,

Last September 1, Amazon Web Services (AWS) released an episode of their
documentary series Now Go Build which highlighted the work done by the
Humanitarian OpenStreetMap Team in the Philippines, especially in mapping
the town of Guagua, in the province of Pampanga.

You can see AWS' video here: https://www.youtube.com/watch?v=hqQwEOaKRas

Several members of the OSM-PH community however have observed that there
are missing and problematic narratives in the video related to the story it
tells of geospatial and humanitarian workers in the country.

Therefore, some of us have prepared and released the following statement:
https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf

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

[talk-ph] A Call to Correct Narratives aboutGeospatial Work in the Philippines

[Eugene Alvin Villar]

Hello all,

Last September 1, Amazon Web Services (AWS) released an episode of their
documentary series *Now Go Build* which highlighted the work done by the
Humanitarian OpenStreetMap Team in the Philippines, especially in mapping
the town of Guagua, Pampanga.

You can see AWS' video here: https://www.youtube.com/watch?v=hqQwEOaKRas

Several members of the OSM-PH community however have observed that there
are missing and problematic narratives in the video related to the story it
tells of geospatial and humanitarian workers in the country.

Therefore, some of us have prepared and release the following statement:
https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf

Regards,
Eugene
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

[Philippe Verdy]

Ce n'est toujours pas complètement réglé. Notamment des fournisseurs de DNS
sécurisés (dont bon nombre de services DNS over HTTPS qui perdent leurs
sessions et on beaucoup de mal à les reconencter) sont toujours impactés.

Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou par
Microsoft sous Windows 10, mais visiblement il n'a pas encore la
capcité nécessaire de supporter le traffic nécessaire: les serveurs DOH
"tombent" les uns après les autres par surcharge (plus assez de ports TCP).
A mon avis le DOH est une mauvaise solution (à cause de l'utilisation de
TCP) et le plus fiable reste encore le DNS sur UDP qu'on peut authentifier
malgré tout avec les signatures numériques et les certificats PKI.

J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez Cogent
(et sur certaines passerelles de Cogent vers l'Afrique transitant par
OpenTransit/Orange). Là encore il y a toujours un problème (et certains
pays africains sont encore quasi coupés du monde (il y a aussi des
problèmes ailleurs comme en Syrie ou Corée du Nord, mais là c'est beaucoup
plus lié aux mesures politiques, ou des mesures d'urgence dans la
cyberguerre qui se déroule en ce moment, que ce soit entre US et Chine, ou
Chine et Taiwan, et en fait pas tellement pour ce qui concerne la situation
politique locale, puisque même les groupes violents ou extrémistes ont
besoin de ces réseaux et ne les sabottent pas, bien au contraire, même
s'ils veulent en prendre le contrôle pour pouvoir les utiliser encore
davantage: les mesures prises le sont par leurs voisins).


Le ven. 4 sept. 2020 à 09:39, Christian Quest  a
écrit :

> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros
> fournisseur de tuyaux.
>
>
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Affichage d'un name suivant le rendu

[Philippe Verdy]

Le ven. 4 sept. 2020 à 09:38, Christian Quest  a
écrit :

> Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
> > De façon pragmatique on peut admettre d'avoir simplement les deux (un
> > noeud et une surface)
>
> C'est une très mauvaise pratique, car cela crée 2 objets dans la base
> pour un seul sur le terrain.
>
> Petit rappel :
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


Ce rappel était inutile. Ce sont deux objets de nature différente même
s'ils ont le même nom mais pas la même fonction. Et ce "doublon" n'est pas
gênant: si on crée une surface délimitée par un polygone, ce n'est pas un
noeud de plus qui change la donne en terme de volumétrie et il n'y a pas
d'ambiguité réelle.

Et j'avais indiqué "de façon pragmatique". On sait qu'on a des limites et
qu'elles ne vont pas se régler tout de suite. Je préfère nettement avoir
deux objets (de nature différents mais positionnés presque au même endroit,
cela n'induit personne en erreur) que de n'en voir aucun de façon aléatoire
ou ne pas le trouver si on cherche avec les outils qu'on a actuellement (en
attendant qu'ils soient corrigés).

Si la correction a lieu il sera toujours très facile plus tard de nettoyer
ces quelques "doublons", faciles à trouver en plus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

[Philippe Verdy]

Notez quand même que nos giratoires à cédez le passage pour l'entrée ne
sont pas la règle partout. Le premier pays à avoir introduit des
giratoires, le Royaume-Uni, a la plupart de ses ronds-points avec
cédez-le-passage en sortie (la priorité à gauche classique, puisqu'ils
roulent à gauche, s'applique) Et dans de nombreux pays les giratoires (ils
en ont moins) sont souvent plus grands qu'en France et comportent des feux
(une minorité en France sauf aménagément particuliers pour voies de bus
centrale, ou dans les très grands ronds-points comme L'Etoile à Paris, où
les giratoires sont très peu nombreux).

D'une façon générale malgré tout (en Europe du moins) les mêmes règles
qu'en France s'appliquent le plus souvent. Il reste quelques pays
anglophones (GB et US notamment) qui ont un système à part. Aux US les rues
sont démesuréement larges, multivoies même avec peu de circulation,
rectilignes, et ils aiment les feux (suspendus sur câbles). Ils ne sentent
pas le besoin de développer des giratoires (qui sont mal compris ou qui
souvent ont des dispositions encore plus spéciales (comme les
"Turbo-roundabount" qu'on trouve dans les interconnexions de voies
majeures, masi qui donnent une plus grande priorité à certains sens de
circulation et certaines voies d'entrée ou de sortie au détriment des
autres où la traversée est plus compliquée).

Nos giratoires à la française sont relatiment simples dans leurs règles et
ne diffèrent en fait que la présence ou l'absence d'ilots séparateurs entre
voies d'entrée et de sortie, et le cas des connexion unidirectionnelles,
mais la même règle de cédez-le-passage à l'entrée et priorité aux véhicules
sur l'anneau (qui devraient avoir un clignotant à gauche pour indiquer
qu'ils ne sortent pas, mais là c'est peu appliqué en France et jamais
sanctionné non plus, pas plus que ceux qui grillent la priorité et ne
cèdent pas le passage en forçant leur entrée et faisant mine de n'avoir
rien vu).


Le ven. 4 sept. 2020 à 05:52, Gad Jo  a écrit :

> Si vous voulez je peu m'en occuper à minima pour les bonnes pratique en
> France.
>
> Le cas des giratoires à ne pas découper on le comprend mieux chez nous, le
> pays des rond point... On en a un nombre très important sans commune mesure
> avec celui qui est en deuxième position (info entendu sur le journal TV).
> Il est probable que dans les autres pays que le cas se présente rarement
> et que personne ne s'y est intéressé.
>
> Pour faire les modifications sur les pages EN faut il faire une demande de
> consensus via une page de discussions ? Quitte a passer sur l'hebdo osm
> pour stimuler les réponses
> Il me faut juste quelques conseils et je me lance
>
> Le September 3, 2020 2:38:45 PM UTC, Rpnpif via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>>
>> Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
>>
>> Bonjour,
>>
>> J'ai souvent découpé des giratoires pour des lignes de bus : honte sur
>> moi !
>> Promis, je ne le ferai plus ;-)
>>
>> Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme
>> moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
>> ou
>> https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points
>> ?
>>
>> Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki
>> moi-même. Et il semblerait qu'il n'y ait pas consensus...
>> Peut-on écrire par ci par là que la bonne pratique en France est de, si
>> possible, ne pas casser les rond points en plusieurs segments ?
>>
>>
>> +1 ! Tout à fait d'accord.
>> --
>> Rpnpif
>>
>
> --
> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] OSM-Kachel-Server für graue Tiles in Europa?

[Martin Koppenhoefer]

Am Fr., 4. Sept. 2020 um 14:12 Uhr schrieb Frank Durstewitz <
frank.durstew...@online.de>:

> Kunden?
>
> Da empfehle ich ganz unironisch https://tiles.localhost




es gibt auch europäische Anbieter von tiles, s.
https://wiki.openstreetmap.org/wiki/List_of_OSM-based_services
je nach Umfang der benötigten tiles ist das evtl. ökonomischer.

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

Re: [Talk-de] OSM-Kachel-Server für graue Tiles in Europa?

[Frank Durstewitz]

Kunden?

Da empfehle ich ganz unironisch https://tiles.localhost

Am 04.09.20 um 13:41 schrieb Elstermann, Mike:

Hallo zusammen,

aus Gründen müssen wir für unsere Kunden prüfen, woher die OSM-Kacheln geladen 
werden. Nicht europäische Server sind da ungewollt (z. B. wg. der 
IP-Adressen-Übermittlung). Gibt es für die grauen Kacheln auch Server in 
Europa, so wie bei den farbigen Kacheln z. B. bei  
https://gauss.openstreetmap.de/? Wenn ja, bitte ich um den Link.

Danke & BG, mikeE.

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




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

[Talk-de] OSM-Kachel-Server für graue Tiles in Europa?

[Elstermann, Mike]

Hallo zusammen,

aus Gründen müssen wir für unsere Kunden prüfen, woher die OSM-Kacheln geladen 
werden. Nicht europäische Server sind da ungewollt (z. B. wg. der 
IP-Adressen-Übermittlung). Gibt es für die grauen Kacheln auch Server in 
Europa, so wie bei den farbigen Kacheln z. B. bei  
https://gauss.openstreetmap.de/? Wenn ja, bitte ich um den Link.

Danke & BG, mikeE.

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

Re: [talk-au] Are Health Centres, hospitals

[Ewen Hill]

We also have the grey area of Bush Nursing Centres that are clearly not
hospitals but are the best place to head to in an emergency and may be the
difference when you are looking at two equal sized communities. The ten
staff sounds arbitrary.

Shouldn't the difference be based on the capability of the premises to
resuscitate, handle compound fractures and prolong life until the patient
can be moved to a more appropriate facility rather than a "must have ten
medical staff"?  Further more, should it be defined as "an official
hospital or the first place of medical support in a rural setting"?

Ewen



On Fri, 4 Sep 2020 at 18:02, Andrew Davidson  wrote:

> On 4/9/20 3:55 pm, Graeme Fitzpatrick wrote:
> > So does that make 2255 / 222 / or a different tally?
>
> It's 222 but I'm not sure how you got that, I get 200. Did you use
> "amenity=hospital in Queensland" in the wizard?
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>


-- 
Warm Regards

Ewen Hill
Internet Development Australia
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] bâtiments composites / fusion de polygones ?

[draenog]

>> SC a des requêtes pourrissant pas mal la base comme demander plusieurs
>> adresses à un bâtiment.

Ok, c'est vrai que j'évite de donner plusieurs adresses pour un même 
lieu, d'où ma question initiale :)


>> Je ne dis pas que SC ne peut pas être utile mais qu'il est utilisé de
>> manière sous optimale. A cause des quêtes pas des utilisateurs^^.

Il est possible de réordonner les quêtes pour les prioriser, qu'est-ce 
qu'il serait le plus utile ?

https://wiki.openstreetmap.org/wiki/StreetComplete/Quests


Le 03/09/2020 à 14:20, osm.sanspourr...@spamgourmet.com a écrit :

Le 03/09/2020 à 13:56, draenog - drae...@harinezumi.fr a écrit :


Je contribue quasi exclusivement depuis mon téléphone, StreetComplete
/ Vespucci (un peu, je découvre), et cela me semblait curieux de
demander (StreetComplete) des numéros de rue plusieurs fois pour le
même lieu (mais est-ce gênant pour OSM ?)


SC a des requêtes pourrissant pas mal la base comme demander plusieurs
adresses à un bâtiment.

Au moins en France on veut ne voir qu'une adresse et plutôt au droit de
l'accès principal.

Et qu'elle soit dans une associatedStreet si c'est une adresse de rue.

Avec plusieurs adresses il y a du travail pour afficher une carte
propre. J'ai déjà vu des coins ou les adresses 12 pullulaient mais peu
d'autres d'adresses dans le coin.

Et tu imagines que si tu demandes d'aller au "13 rue de la Mairie" on
demande si tu veux aller :
- au toit "13 rue de la Mairie"
- au bâtiment de plain-pied "13 rue de la Mairie"
- au bâtiment de deux étages "13 rue de la Mairie"

etc...

De plus avec les possibilités d'intégrer les adresses depuis le
cadastre, il serait raisonnable de déactiver cette quête sur SC. Et
d'inciter à utiliser dev.cadastre.openstreetmap.fr à la place.

C'est un peu comme demander le revêtement de la route sur une
départementale en France : dans 99 % des cas c'est surface=asphalt. Je
pense qu'on a mieux à faire que demander le revêtement de la route.

Je ne dis pas que surface est sans intérêt mais seulement quand la
surface est étonnante ou que vu le type de voirie ça n'a rien d'évident.

 > Je contribue quasi exclusivement depuis mon téléphone,

C'est un peu le problème : en contribuant via SC tu n'a pas forcément
les bons outils.

Je ne dis pas que SC ne peut pas être utile mais qu'il est utilisé de
manière sous optimale. A cause des quêtes pas des utilisateurs^^.


Le bon type pour l'exemple au-dessus serait "toit" ?


oui (roof=no en termes d'attributs).

Jean-Yvon




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


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

Re: [Talk-it] Alberi monumentali d’Italia

[Martin Koppenhoefer]

sent from a phone

> On 4. Sep 2020, at 11:32, Cascafico Giovanni  wrote:
> 
> ho scoperto che alla wiki mancano i seguenti genus


inutile documentare tutti i genus, puoi tranquillamente usare qualsiasi genus 
che esiste nel mondo dei biologi...

Ciao Martin 


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

Re: [Talk-it] Alberi monumentali d’Italia

[Cascafico Giovanni]

Ho valorizzato i tag leaf_type e leaf_cycle grazie alla tabella wiki
[1] ed ho scoperto che alla wiki mancano i seguenti genus:

Ceratonia 19
Wisteria 8
Hedera 7
Vitis 7
Dracaena 5
Nolina 5
Ceiba 3
Gleditzia 3
Laurus 3
Phytolacca 3
Yucca 3
Dracena 2
Myrtus 2
Tipuana 2
Brachychiton 1
Casuarina 1
Clematis 1
Colletia 1
Diospyros virginiana 1
Genista 1
Jacaranda 1
Melaleuca 1
Mirtus 1
Osmanthus 1
Prosopis 1
Rhamnus 1
Sciadopitys 1
Strelitzia 1

Che fare?

[1] 
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree/List_of_Genus,_Leaf_cycle,_Leaf_type

Il 04/09/20, Martin Koppenhoefer ha scritto:
> Am Fr., 4. Sept. 2020 um 10:59 Uhr schrieb Alessandro Sarretta <
> alessandro.sarre...@gmail.com>:
>
>> On 04/09/20 10:45, Martin Koppenhoefer wrote:
>>
>>
>>
>> Am Fr., 4. Sept. 2020 um 10:40 Uhr schrieb Alessandro Sarretta <
>> alessandro.sarre...@gmail.com>:
>>
>>> secondo me non vale la pena di usare tag multipli. O si inseriscono come
>>> suggerisci tu in description:it oppure si potrebbero concatenare in un
>>> campo specifico tipo
>>>
>>> denotation:criteria=age;height; ...
>>>
>>
>> +1
>> o forse monumental:criteria
>>
>> Non so... monumental non è documentato né usato, mi pare.
>>
>> Forse, se usiamo sempre il tag denotation:natural_monument per questi
>> alberi monumentali, potrebbe essere più coerente ed esplicito
>>
>> natural_monument:criteria=age;height; ...
>>
>
>
> sì, potrebbe essere più esplicito.
> Non mi piace in generale la chiave "denotation" perché non mi sembra abbia
> senso semanticamente. Il metodo migliore per capirne il senso pare sia di
> inserirla in un dizionario tedesco-inglese, e risulta una parola ambigua
> (Bedeutung) che può essere tradotta anche come "importanza", tra tutti i
> significati: https://dict.leo.org/italienisch-deutsch/Bedeutung
> Intendo dire: probabilmente l'utente che ha unilateralmente creato questo
> tag tanti anni fa, probabilmente ha semplicemente cercato la traduzione
> inglese di "Bedeutung" e poi scelto la variante sbagliata ;-)
>
> Ciao
> Martin
>

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

Re: [Talk-it] Alberi monumentali d’Italia

[Martin Koppenhoefer]

Am Fr., 4. Sept. 2020 um 10:59 Uhr schrieb Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

> On 04/09/20 10:45, Martin Koppenhoefer wrote:
>
>
>
> Am Fr., 4. Sept. 2020 um 10:40 Uhr schrieb Alessandro Sarretta <
> alessandro.sarre...@gmail.com>:
>
>> secondo me non vale la pena di usare tag multipli. O si inseriscono come
>> suggerisci tu in description:it oppure si potrebbero concatenare in un
>> campo specifico tipo
>>
>> denotation:criteria=age;height; ...
>>
>
> +1
> o forse monumental:criteria
>
> Non so... monumental non è documentato né usato, mi pare.
>
> Forse, se usiamo sempre il tag denotation:natural_monument per questi
> alberi monumentali, potrebbe essere più coerente ed esplicito
>
> natural_monument:criteria=age;height; ...
>


sì, potrebbe essere più esplicito.
Non mi piace in generale la chiave "denotation" perché non mi sembra abbia
senso semanticamente. Il metodo migliore per capirne il senso pare sia di
inserirla in un dizionario tedesco-inglese, e risulta una parola ambigua
(Bedeutung) che può essere tradotta anche come "importanza", tra tutti i
significati: https://dict.leo.org/italienisch-deutsch/Bedeutung
Intendo dire: probabilmente l'utente che ha unilateralmente creato questo
tag tanti anni fa, probabilmente ha semplicemente cercato la traduzione
inglese di "Bedeutung" e poi scelto la variante sbagliata ;-)

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

Re: [OSM-talk-fr] maxspeed par défaut

[osm . sanspourriel]

Le 03/09/2020 à 16:05, Percherie OnDaNet - perche...@toutenkamion.net a
écrit


Attention pour le nombre de voies. C'est le nombre de voies par sens
de circulation. Je m'en suis rendu compte quand mes applications de
routage m'indiquez 4 voies (2 + 2 par sens) sur une route de
campagne. C'était une découverte sur un cas pratique.


Non, c'est bien le nombre *total* de voies :

FR:Key:lanes /
/

/La clé //lanes=*//doit être utilisée pour indiquer le nombre total
marquées de voies. /


Vérifié et confirmé.

Jean-Yvon

P. S.  : FR:Key:lanes#Présupposés

indique bien quand on peut se contenter du nombre de voies par défaut.

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

Re: [talk-cz] OSM: Zrušené polní cesty s nepravděpodobným obnovením

[majkaz]

Pokud po cestě není ani stopy, a vím, že je to delší stav, taky bez rozpaků 
mažu. Pokud je tam zábrana, zmapovat tu.
 
Majka
 
__

Od: "<0174" 
Komu: "OpenStreetMap Czech Republic" 
Datum: 04.09.2020 10:57
Předmět: Re: [talk-cz] OSM: Zrušené polní cesty s nepravděpodobným obnovením


Ahoj,pokud se tam fakt už nechodí/nejezdí/v terénu nic není ani měsíc po rozorání, 
tak bych ji smazal (jen v tom úseku, kde je zrušená).<0174
pá 4. 9. 2020 v 9:27 odesílatel Laďa Kašpárek > 
napsal:Ahoj, jak se přistupuje k mapované polní cestě, která byla rozorána a patrně nebude 
obnovena (uživatel pole umístil je okraj pole zábranu, aby se v dané trase nejezdilo)? Smazat 
nebo nějakým způsobam označit? Narazil jsem toto u 
https://www.openstreetmap.org/way/531467149#map=17/49.20177/18.04462 
Dík Laďa K.

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

Re: [Talk-it] Alberi monumentali d’Italia

[Alessandro Sarretta]

On 04/09/20 10:45, Martin Koppenhoefer wrote:



Am Fr., 4. Sept. 2020 um 10:40 Uhr schrieb Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>>:


secondo me non vale la pena di usare tag multipli. O si
inseriscono come suggerisci tu in description:it oppure si
potrebbero concatenare in un campo specifico tipo

denotation:criteria=age;height; ...


+1
o forse monumental:criteria


Non so... monumental non è documentato né usato, mi pare.

Forse, se usiamo sempre il tag denotation:natural_monument per questi 
alberi monumentali, potrebbe essere più coerente ed esplicito


natural_monument:criteria=age;height; ...

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] OSM: Zrušené polní cesty s nepravděpodobným obnovením

[<0174]

Ahoj,
pokud se tam fakt už nechodí/nejezdí/v terénu nic není ani měsíc po
rozorání, tak bych ji smazal (jen v tom úseku, kde je zrušená).

<0174

pá 4. 9. 2020 v 9:27 odesílatel Laďa Kašpárek  napsal:

> Ahoj, jak se přistupuje k mapované polní cestě, která byla rozorána a
> patrně nebude obnovena (uživatel pole umístil je okraj pole zábranu, aby se
> v dané trase nejezdilo)? Smazat nebo nějakým způsobam označit? Narazil jsem
> toto u
> https://www.openstreetmap.org/way/531467149#map=17/49.20177/18.04462
> Dík Laďa K.
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Rond point et relations routes

[Christian Quest]

Le 01/09/2020 à 13:34, osm.sanspourr...@spamgourmet.com a écrit :

Tu veux parler de giratoires ? ;-)

Je crois que le problème est plus général avec les routes : on n'arrête
pas de les couper pour des limites de vitesse, stationnement, files...



Oui, le problème est plus général que l'effet des relation route=*

Cela pose problème côté rendu... car à force ces petits segments 
deviennent trop petits pour y placer les noms.


J'ai dû les recoller ensemble quand ils ont le même name=* / highway=* 
pour avoir plus de chance de placer le nom.


Il est probable de devoir un de ces jours avoir des relations pour 
conserver un objet logique composé de multiples éléments de plus en plus 
petits à mesure qu'on rentre dans les détails.


C'est un comble, car historiquement il n'y avait pas de "way" dans OSM, 
mais des segments qui ne reliaient que deux nœuds, et à force de 
découper, on retombe presque par endroits dans cette segmentation.





C'est qu'il manque un niveau d'information : la rue, le giratoire, à
distinguer du segment de route.

Pour la rue on a associatedStreet. Mais pour le rendu on utilise le nom
de chaque segment avec n fois Rue Tartempion sur la carte.



Les associatedStreet servent à lier les adresses à la voirie, pas à lier 
la voirie elle même.




Et le découpage des giratoires est fait en fonction des trajets de bus,
pas des segments (si deux routes se croise et que le bus route, on va
avoir un segment d'un côté et trois de l'autre).

On pourrait ici avoir 4 segments dans une relation round-about.

Ce serait propre et utilisable si les outils le supportaient.

Je crains qu'il vaille mieux s'en tenir à l'existant.

Usuellement je ne découpe que si le reste du trajet de bus les
giratoires sont découpés.


Je ne découpe pas pour les route=*


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-it] Alberi monumentali d’Italia

[Martin Koppenhoefer]

Am Fr., 4. Sept. 2020 um 10:40 Uhr schrieb Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

> secondo me non vale la pena di usare tag multipli. O si inseriscono come
> suggerisci tu in description:it oppure si potrebbero concatenare in un
> campo specifico tipo
>
> denotation:criteria=age;height; ...
>
>
+1
o forse monumental:criteria

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

Re: [Talk-hr] Fwd: Import zgrada u Zagrebu

[Janko Mihelić]

Novi .osm sa novim tagovima:
https://www.dropbox.com/s/n05f0ikjxz8i9en/buildings-ot5-vjerski_objekti.osm?dl=0

A ovdje je mali .osm za isprobavanje OSM conflatora. Ima 4 poligona, dva
odvojena, dva spojena. Promijenjeno je nekoliko točaka između dva spojena
poligona.
Nepromijenjena datoteka:
https://www.dropbox.com/s/ff87kwi9pe1szqw/8912_5840.osm?dl=0
Promjenjena:
https://www.dropbox.com/s/17lqg3azxqr3fji/8912_5840_2.osm?dl=0

Janko

čet, 3. ruj 2020. u 17:29 Janko Mihelić  napisao je:

> čet, 3. ruj 2020. u 16:47 Matija Nalis <
> mnalis-openstreetmapl...@voyager.hr> napisao je:
>
>> hm, ne vidim taj source:geometry:dataset bas po taginfu? mozda spojiti u
>> jedan:
>>
>> source:geometry=ZIPP Aerofotogrametrijsko i LiDAR snimanje
>> source:geometry:ref=234235 (ovo umjesto zzip_import_id)
>> source:geometry:date=2012-03-26
>>
>> A da se opet zna *cije* je to Aerofotogrametrijsko i LiDAR snimanje...
>>
>
> Ja sam za. Imaš pravo, dvostruki datum nije potreban. Budem napravio nove
> religijske .osm datoteke sa tagovima. Find Replace.
>
>
>> S tim da mi ovaj drugi svasta nesto radi, ali javlja gresku
>> "confict in 'visible' attribute for object of type node with id 199"
>>
>
> Možda ipak treba prvo ovaj drugi link, a onda prvi. U drugom kaže
> "new_layer=false" a u prvom "true" pa valjda to radi problem kad proba
> spojiti podatke.
>
>
>> i da li bi trebalo biti u tom drugom URL-u "changeset_source=Bing" ?
>> mozda "changeset_source=geoportal.zagreb.hr" ?
>>
>
> To stvara Tasking Manager, ima dio gdje se može podesiti imagery, ja nisam
> stavio ništa pa je stavio defaultni source=Bing. Ali mi je glupo da u
> imagery stavim geoportal.zagreb.hr, pa da se otvori prazno. Možda da
> stavimo Zagreb 2018 imagery, ionako ćemo još malo podešavati po njemu.
> A mogu staviti i geoportal.zagreb.hr, nije neki problem svaki put
> otvoriti imagery..
>
>
>> Ja sam gledao ovaj:
>> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation
>> taj isto koristi utilsplugin2 ali je navodno bolji za conflation zbog
>> neceg :)
>>
>
> Budem probao, sa onim drugim nije baš bilo bezbolno, bilo je dosta ručnog
> rada sa spajanjem točaka.
>
>
>
>> Ja bih dakle da probamo:
>> a) napraviti rucno malo modificiranu fake verziju ovog originalnog ZIPPv1
>> dataseta i spremiti kao ZIPPv2.osm
>> b) probati sa utilsplugin2 (ili JOSM conflate) pluginom u JOSMu rucno
>> conflateati par zgrada po ZIPPv1 (da dobiju import tagove i geometriju)
>> c) sa https://wiki.openstreetmap.org/wiki/OSM_Conflator probati
>> poluautomatski upgrade sa ZIPPv1 na ZIPPv2 geometrije da vidi da li ce ih
>> pokupiti ispravno
>>(Samo za te zgrade koje smo rucno conflateali u koraku b) naravno!)
>>
>> pa tek kada znamo da ce nam to raditi OK, onda da objavimo Task manager...
>>
>
> Ok, budem napravio mini .osm fajlu sa nekoliko crkvica pa se možemo igrati.
>
> Za ljude je vjerojatno dovoljno dobro nesto tipa "source:geometry=RUCNO
>> radjeno prema a,b,c.  Ne dirati osim ako nova geometrija sigurno nije bolja
>> od toga"
>> Pa onda ce razmisliti (nadajmo se) prije nego krenes mijenjati geometriju
>> toga.
>>
>
> Onda je upitno ono što Hrvoje kaže da ionako trebamo namještati po Zagreb
> DOF-u 2018. Jer će onda svi biti bar malo drugačiji. Trebalo bi malo
> proanalizirati koji postotak bi se namještao:
> https://tms.osm-hr.org/
>
> Janko
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

Re: [Talk-it] Alberi monumentali d’Italia

[Alessandro Sarretta]

Ciao,

On 04/09/20 10:14, Cascafico Giovanni wrote:

Mi son fatto spedire dal MIPAAF il file xls nazionale, che sembra più
flessibile per correzioni ed aggiustamenti di campi.

Rispetto agli xls regionali, ciascun criterio è definito in un campo specifico:
CR ETA' Booleano CRITERIO ETA'
CR CIRCONF Booleano CRITERIO CIRCONFERENZA
CR ALTEZZA Booleano CRITERIO ALTEZZA
CR AMPIEZZ Booleano CRITERIO AMPIEZZA CHIOMA
CR FM O PO Booleano CRITERIO FORMA O PORTAMENTO
CR VALORE Booleano CRITERIO VALORE ECOLOGICO
CR RARITA'  Booleano CRITERIO RARITA' BOTANICA
CR ARCHIT Booleano CRITERIO ARCHITETTURA VEGETALE
CR PAESAG Booleano CRITERIO VALORE PAESAGGISTICO
CR STORICO Booleano CRITERIO VALORE STORICO

Come mappare i campi?
denotation:age=yes
denotation:circumference=yes eccetera,

oppure si concatena in description:it, come per esempio:
description:it=età e/o dimensioni, forma e portamento, valore ecologico


secondo me non vale la pena di usare tag multipli. O si inseriscono come 
suggerisci tu in description:it oppure si potrebbero concatenare in un 
campo specifico tipo


denotation:criteria=age;height; ...

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-it] Alberi monumentali d’Italia

[Cascafico Giovanni]

Mi son fatto spedire dal MIPAAF il file xls nazionale, che sembra più
flessibile per correzioni ed aggiustamenti di campi.

Rispetto agli xls regionali, ciascun criterio è definito in un campo specifico:
CR ETA' Booleano CRITERIO ETA'
CR CIRCONF Booleano CRITERIO CIRCONFERENZA
CR ALTEZZA Booleano CRITERIO ALTEZZA
CR AMPIEZZ Booleano CRITERIO AMPIEZZA CHIOMA
CR FM O PO Booleano CRITERIO FORMA O PORTAMENTO
CR VALORE Booleano CRITERIO VALORE ECOLOGICO
CR RARITA'  Booleano CRITERIO RARITA' BOTANICA
CR ARCHIT Booleano CRITERIO ARCHITETTURA VEGETALE
CR PAESAG Booleano CRITERIO VALORE PAESAGGISTICO
CR STORICO Booleano CRITERIO VALORE STORICO

Come mappare i campi?
denotation:age=yes
denotation:circumference=yes eccetera,

oppure si concatena in description:it, come per esempio:
description:it=età e/o dimensioni, forma e portamento, valore ecologico

@Martin
il campo STATO non indica la condizione di new entry e nel documento,
mentre la perdita di status monumentale (9 alberi in Friuli) è
descritta nel decreto [1] definito nel campo "DECR MODIF":
"[...] a causa dell'elevato deperimento strutturale e fisiologico di
esemplari iscritti nell'Elenco nazionale"



[1] 
https://www.pim.mi.it/normativa/Decreto_9022657_del_24_luglio_2020_GU_195_05-08-2020.pdf

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

Re: [talk-au] Are Health Centres, hospitals

[Andrew Davidson]

On 4/9/20 3:55 pm, Graeme Fitzpatrick wrote:

So does that make 2255 / 222 / or a different tally?


It's 222 but I'm not sure how you got that, I get 200. Did you use 
"amenity=hospital in Queensland" in the wizard?


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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

[Christian Quest]

Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
oui ça remarche ce midi, hier soir l'internet était un enfer à 
naviguer. (sauf les sites Google, et le reste était extrèmmeent lent, 
surtout le DNS et presque tout ce qui transitait par les gros 
datacenters d'Amsterdam)



Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros 
fournisseur de tuyaux.


https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet


La concentration d'internet dans toute sa splendeur :(

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Christian Quest]

Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
De façon pragmatique on peut admettre d'avoir simplement les deux (un 
noeud et une surface)


C'est une très mauvaise pratique, car cela crée 2 objets dans la base 
pour un seul sur le terrain.


Petit rappel : 
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element



En revanche il peut être utile de conserver certains tags spécifiques 
(pas tous) comme la délimitation des places réservées aux handicapés, 
ou les parkings 2 roues sans avoir besoin d'afficher leur nom en 
doublon visible.


amenity=parking_space pour indiquer les places (en ponctuel ou 
surfacique), à ne pas confondre avec amenity=parking qui décrit 
l'ensemble du parking.



--
Christian Quest - OpenStreetMap France


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

[talk-cz] OSM: Zrušené polní cesty s nepravděpodobným obnovením

[Laďa Kašpárek]

Ahoj, jak se přistupuje k mapované polní cestě, která byla rozorána a patrně
nebude obnovena (uživatel pole umístil je okraj pole zábranu, aby se v dané
trase nejezdilo)? Smazat nebo nějakým způsobam označit? Narazil jsem toto u
https://www.openstreetmap.org/way/531467149#map=17/49.20177/18.04462

Dík Laďa K.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-au] Are Health Centres, hospitals

[Mateusz Konieczny via Talk-au]

Sep 4, 2020, 07:09 by o...@97k.com:

>
> some would not satisfy the definition of "clinic" depending on whether the 10 
> staff (as specified in the OSM wiki)
>
This sounds like wikifiddling to me. I reduced its weight in
https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dclinic=2029091=1996391

>  I reckon the locals would regard the Burketown facility as their hospital 
> even if it is not so named and even if it does not satisfy OSM criteria.
>
Note that OSM maps reality and official government/local referring to something 
under an unusual
 term is not changing type of feature. Prisons should be tagged as prisons, 
even if government
calls them "vocation centers".

If something is clearly not a hospital it should not be tagged as one even if 
official
or local name includes "hospital". Even if locals are referring to them as 
"hospital".
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au