Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

Prinzipiell +1, es ist aber auch eine Frage gegen (anhand) welche(r)
Auflösung gemappt wird.  Wenn Alleebäume, Graben und Bankette nicht
auf einem Luftbild zu erkennen sind und außerdem _keine_ Vorort-
Besichtigung stattfand, dann ist es _nach dieser Quellenlage_
nicht falsch, diese Objekte zu unterschlagen.

Eine ungenaue Ackergrenze ist in diesem Fall besser, als gar keine.
Sollen diese temporären bzw. groben Datenstände vermieden werden,
dann wäre eine Regel aufzustellen, nach der nur Daten in OSM einge-
tragen werden dürfen, die mit einem Fehler <= eps der Realität
entsprechen.  Solche eine Regel gibt es m.W. für/in OSM nicht.

Natürlich ließe sich mit ein paar Grund_annahmen_ über die Topologie
auch eine Ackergrenze _konstruieren_ die neben der Straße liegt, ob-
wohl kein genaues Luftbild zum Tracen vorliegt, aber das kann im
Zweifel die Realität genau so schlecht approximieren bzw. annähern,
wie das Verkleben, das in Gebieten mit schlechten oder gar keinen
Luftbildern nunmal einfach und bequem ist, selbst wenn ein Fehler
"eps" später bei geänderter Datenlage sichtbar wird.

Die Bewertung, ob etwas sachlich falsch ist, hängt also unmittel-
bar an der Verfügbarkeit entsprechender Information zum Abgleich.
Das ist der Wikipedia sehr ähnlich:  Oft als Tertiärquelle be-
nannt, kann die wiedergegebene Datenqualität nicht besser sein,
als das, was sekundärquellenhaft den Autoren (und auch den Ad-
mins ..) zur Verfügung stand.


In D ist das aufgrund sehr guter Auflösung der Orthofotos weniger
relevant, aber in anderen Gebieten sieht es eben anders aus. Selbst
wer einen Anschluss mit geringer Bandbreite hat, ist evtl. auch
hierzulande nicht bereit auf eine hochauflösende Orthofoto-Quelle
zurückzugreifen, obwohl sie zur Verfügung stünde.


Gruß


> On 21. Oct 2018, at 12:26, Florian Lohoff wrote:
>
> [..] Die mapper die dann kein "nichts" ertragen können ziehen dann das
> Farmland bis zur Straße und dann sind die Allebäume und der Graben und
> die Bankette teil des Ackers - und DAS ist sachlich falsch. [..]
> 
> 
> Flo

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

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

Not sure why I can't find it on the list archives but there was some
discussion about this below. In short, I'm in favour of not uploading
duplicate state borders and during or post-import we manually fix up
the relations to use the existing state boundaries.

On Thu, 18 Oct 2018 at 12:35, Andrew Davidson  wrote:
>
> On Wed, Oct 17, 2018 at 6:29 PM Andrew Harvey  
> wrote:
>>
>> I'm in favour of first manually removing the
>> state borders so we don't dump more nodes on top and then post-upload
>> we can just join the new relations to the existing state borders where
>> they meet.
>
>
> I can see your point about not wanting to upload ways and nodes that just 
> going to be deleted immediately after. However if we don't then it's going to 
> make my idea for QA harder. I'd assumed that we'd be uploading valid 
> multi-polygons which means that we could use Overpass and the JOSM validator 
> for QA. I guess we might be able to come up with another approach but I'm not 
> sure it's worth the effort just to avoid adding and removing a few tens of 
> thousands of nodes in comparison to the size of the import.
On Mon, 22 Oct 2018 at 15:04, Joel H.  wrote:
>
> One last note (and I don't know if this has been mentioned already).
>
> But it seems that the State boundary (at least on the QLD/NSW boarder)
> doesn't match up precisely with what we already have in OSM. Should we
> remove the outer edges of the PSMA data and then add existing state ways?
>
> On 22/10/18 1:40 pm, Andrew Harvey wrote:
> >> I don't know if this was introduced in the simplification or it was an
> > error with PSMA. But there is only 26 of these errors in QLD so I would
> > hardly call this an issue, you can easily fix these manually.
> >
> > I'm not sure either, so unless there's a better/automated way, let's
> > just address this manually either during the import or immediately
> > after.
> > On Sun, 21 Oct 2018 at 12:33, Joel H.  wrote:
> >> On 19/10/18 5:01 pm, Andrew Harvey wrote:
> >>
> >>> Is there a problem with crossing ways? Why do they need a shared node
> >>> when they are different admin levels?
> >>
> >> Yes jump to the position I told you and zoom right in to the
> >> intersection, there is a crossover between two level 10 admin areas.
> >>
> >> I don't know if this was introduced in the simplification or it was an
> >> error with PSMA. But there is only 26 of these errors in QLD so I would
> >> hardly call this an issue, you can easily fix these manually.
> >>
> >>
> >>
> >> ___
> >> Talk-au mailing list
> >> Talk-au@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-au
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] PSMA Administrative Boundaries

[Joel H.]

One last note (and I don't know if this has been mentioned already).

But it seems that the State boundary (at least on the QLD/NSW boarder)
doesn't match up precisely with what we already have in OSM. Should we
remove the outer edges of the PSMA data and then add existing state ways?

On 22/10/18 1:40 pm, Andrew Harvey wrote:
>> I don't know if this was introduced in the simplification or it was an
> error with PSMA. But there is only 26 of these errors in QLD so I would
> hardly call this an issue, you can easily fix these manually.
>
> I'm not sure either, so unless there's a better/automated way, let's
> just address this manually either during the import or immediately
> after.
> On Sun, 21 Oct 2018 at 12:33, Joel H.  wrote:
>> On 19/10/18 5:01 pm, Andrew Harvey wrote:
>>
>>> Is there a problem with crossing ways? Why do they need a shared node
>>> when they are different admin levels?
>>
>> Yes jump to the position I told you and zoom right in to the
>> intersection, there is a crossover between two level 10 admin areas.
>>
>> I don't know if this was introduced in the simplification or it was an
>> error with PSMA. But there is only 26 of these errors in QLD so I would
>> hardly call this an issue, you can easily fix these manually.
>>
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

Per the import guidelines
https://wiki.openstreetmap.org/wiki/Import/Guidelines I've requested a
review from the wider imports mailing list at
https://lists.openstreetmap.org/pipermail/imports/2018-October/005760.html
On Mon, 22 Oct 2018 at 14:40, Andrew Harvey  wrote:
>
> > I don't know if this was introduced in the simplification or it was an
> error with PSMA. But there is only 26 of these errors in QLD so I would
> hardly call this an issue, you can easily fix these manually.
>
> I'm not sure either, so unless there's a better/automated way, let's
> just address this manually either during the import or immediately
> after.
> On Sun, 21 Oct 2018 at 12:33, Joel H.  wrote:
> >
> > On 19/10/18 5:01 pm, Andrew Harvey wrote:
> >
> > > Is there a problem with crossing ways? Why do they need a shared node
> > > when they are different admin levels?
> >
> >
> > Yes jump to the position I told you and zoom right in to the
> > intersection, there is a crossover between two level 10 admin areas.
> >
> > I don't know if this was introduced in the simplification or it was an
> > error with PSMA. But there is only 26 of these errors in QLD so I would
> > hardly call this an issue, you can easily fix these manually.
> >
> >
> >
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

> I don't know if this was introduced in the simplification or it was an
error with PSMA. But there is only 26 of these errors in QLD so I would
hardly call this an issue, you can easily fix these manually.

I'm not sure either, so unless there's a better/automated way, let's
just address this manually either during the import or immediately
after.
On Sun, 21 Oct 2018 at 12:33, Joel H.  wrote:
>
> On 19/10/18 5:01 pm, Andrew Harvey wrote:
>
> > Is there a problem with crossing ways? Why do they need a shared node
> > when they are different admin levels?
>
>
> Yes jump to the position I told you and zoom right in to the
> intersection, there is a crossover between two level 10 admin areas.
>
> I don't know if this was introduced in the simplification or it was an
> error with PSMA. But there is only 26 of these errors in QLD so I would
> hardly call this an issue, you can easily fix these manually.
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

[Talk-us] Spartanburg County SC road centerlines import

[Mike N]

This is a proposed import of road centerlines for Spartanburg County SC, 
based on county GIS data.   This will include a systematic review of all 
roads in the county and qualify to remove tiger:reviewed tags.


https://wiki.openstreetmap.org/wiki/Spartanburg_county_road_center_line_import

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Oleksiy Muzalyev]

Hi Martin,

Before continuing this discussion further, I would advise to read the 
amazing article "The demise of the nation state" by Rana Dasgupta 
available via this link: 
https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta


The issue of national state boundaries is more profound and ubiquitous 
than it may seem at first sight. This topic is controversial and 
complicated, and Rana Dasgupta's analyses provides some good 
starting-point insights.


Best regards,
Oleksiy

On 21.10.18 16:12, Martin Koppenhoefer wrote:

Dear all,

we all know how sensible the topic of disputed boundaries can be (they 
are not necessarily a big problem, many boundary disputes like between 
Italy and France about the summit of Mont Blanc / Monte Bianco, have 
little bearing on the actual life of people).


Therefore we can all be satisfied there is clear guidance from the 
board how to deal with this: the local situation determines how we 
map, and the OSMF is explicit here: “National borders are particularly 
sensitive. Currently, we record one set that, in OpenStreetMap 
contributor opinion, is most widely internationally recognised and 
best meets realities on the ground, generally meaning physical control.”


https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation. 
pdf 



When I recently looked at Crimea I noticed it is still part of the 
Ucraine in OSM: https://www.openstreetmap.org/relation/60199


As many might know, the current boundary situation for Crimea was 
frozen 4 years ago “for a short time” by the DWG and so I asked them 
about their current position 2 months ago, and after I got no reply, 
tried to remind them 5 weeks ago, but have not yet gotten any reply, 
so I am now opening this thread here.


IMHO, for consistency and credibility, we should either recognize that 
Russia is actually controlling Crimea, or we should update the 
disputed borders information. As I believe the general concept of 
ground truth for admin boundaries was a good idea, I would tend to the 
former.


I also believe the actual situation has already been ignored for too 
long. When the thing is still dynamic or/and we’re in the middle of a 
conflict it can be wise to step back and see for some time how things 
are evolving, but 4 years are a lot of time, something like one year 
would seem more reasonable.


What do you think?

Cheers, Martin

sent from a phone

Begin forwarded message:

*From:* Martin Koppenhoefer >

*Date:* 20. August 2018 at 10:42:33 CEST
*To:* d...@osmfoundation.org 
*Subject:* *DWG policy on Crimea*


Dear members of the DWG,

as of this question in the help forum:

https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea 



I kindly invite you to reconsider and eventually update your position 
on the situation in Crimea.


As you have stated in 2014, this should not be the long term way to 
deal with the situation, and short term is probably coming to an end. 
There is clear guidance by the OSMF board how to deal with disputed 
boundaries (as the situation seems to be more stable than some would 
have liked).


My motivation is not promoting the Russian point of view, but to act 
predictably and consistent wrt sensible topics.


Thank you,
cheers,
Martin



___
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] Bien qu'étant abonné, je ne reçois pas tous les mails

[Philippe Verdy]

J'ai noté aussi que les envois à la liste faits par les abonnés de
LaPoste.fr aboutissent aussi très souvent dans ma boite de courriels
indésirables car LaPoste identifie mal sur ses DNS l'authenticité de ses
serveurs SMTP (l'expéditeur ne peut pas être vérifié de façon certaine
comme étant bien un abonné de LaPoste, et les relais de messagerie SMTP de
LaPoste cassent également un certain nombre d'entêtes MIME qui permettrait
de pallier en permettant de certifier le routage effectif par un serveur
SMTP appartenant à LaPoste).

Du coup un gros volume de "spams" transitent par leurs serveurs en
utilisant des falsifications d'identité (détournées) de réels abonnés à la
Poste et ensuite s'ils sont relayés par la Poste vers d'autres serveurs,
des derniers vont en rejeter pas mal (ne pas accepter de les relayer plus
loin ou sinon les mettre dans la corbeille des indésirables si leur
destinataire final est une boite à lettres de ces derniers serveurs).

Du côté d'OSM on ne peut pas faire grand chose, la poste n'est pas à jour;
Orange non plus, qui ne parvient toujours pas à authentifier de façon
certaine tous ses propres serveurs SMTP. Ces deux services sont à la traîne
depuis longtemps (même pour leurs abonnés payants) et ne veulent toujours
rien corriger (ils prétendent à chaque fois que tout va bien et qu'il n'y a
aucune anomalie chez eux même si on leur démontre le contraire: dès qu'on
rentre dans des preuves techniques, cela sort de leur "périmètre" de
support officiel et ils insistent pour qu'on n'utilise alors PAS la
messagerie SMTP/POP3, ni même IMAP, mais uniquement leur "webmail"
propriétaire, enrichi en pubs et pas vraiment pratiques non plus à
utiliser...

Pour eux le SMTP/POP3 ce n'est pas du mail et pourtant c'est bien un
service mail supposé conforme aux normes existantes qu'ils ont vendus mais
détournés pour en faire un support publicitaire, souvent très intrusif
alors que la loi normalement leur impose de traiter la messagerie et tout
ce qui y est véhiculé comme un service postal les obligeant au secret des
communications personnelles, et aussi à prendre toutes les mesures de
sécurité dans l'état de l'art de ce qui est connu, mais avec une obligation
légale de moyens (ce dont ils se dégagent sans arrêt, comme si ce n'était
pas de leur responsabilité).

Ceci dit, "l'état de l'art" des normes connues pour la messagerie est en
perpétuel changement et il y a beaucoup d'extensions qui sont maintenant
demandées par certains services, certes décrites dans des RFC mais pas
approuvées comme partie de la norme obligatoire pour la conformité : nombre
des extensions sont expérimentales même si elles sont maintenant utilisées
par des gros fournisseurs, qui veulent les imposer de cette façon (non pas
avec des mesures transitoires destinées à palier des difficultés techniques
temporaires comme l'usage abusif qui compromettrait gravement les
performances des systèmes pour une grande partie de leurs utilisateurs,
mais par des mesures imposées de façon permanente à tous les autres...
avant qu'ils décident finalement d'en changer encore les spécifications de
façon incompatible avec les versions préliminaires non standardisées de
leurs protocoles expérimentaux).

Il y a un tel volume massif de spams dans la messagerie mondiale que
chacune finalement tente d'inventer ses solutions, mais il manque une
réelle concertation pour faire évoluer les normes existantes de façon
stable, avec des étapes correctement décrites permettant la migration en
douceur avant de renforcer progressivement les règles.

En fin de compte les fournisseurs de services ne réagissent qu'en fonction
de statistiques d'utilisation et d'impact commercial réel : si l'anomalie
ne touche que 1% des utilisateurs légitimes, ils s'en fichent et remettent
toujours tout à plus tard et ne veulent pas la prendre en compte dans leurs
supports techniques (ils préfèrent obliger les utilisateurs à adopter
d'autres solutions propriétaires et plus chères pour les facturer, ou les
obliger à accepter d'utiliser des systèmes intrusifs). Le mail standard est
le cadet de leur soucis, il n'est là que bon gré et mal gré pour eux juste
comme une nécessité qui doit juste fonctionner dans 80% des cas.






Le sam. 20 oct. 2018 à 17:26, Gwenaël Jouvin  a
écrit :

> Bonsoir,
>
> J’ai le même problème et je remarque que nous sommes tous deux chez la
> Poste.
>
> Je suppose que c’est dû à cet hébergeur. J’ai subi de gros problèmes de
> réception de messages sur cette boîte il y a quelques mois, des messages
> arrivaient 2, 3 jours après leur envoi…
> Les soucis se sont calmés mais reviennent çà et là.
> Faudrait vraiment que tout le monde envoie ses mails avec un timbre rouge
> :-)
>
> Ma parade : inscrit avec une autre adresse pour tout avoir ou consulter
> les archives.
>
> Gwenaël
>
>
> Le 20/10/2018 à 15:31, Paul Desgranges a écrit :
> > Bonjour
> >  Bien qu'étant abonné a talk-fr@openstreetmap.org, je ne reçois qu'un
> mail sur cinq à peu près, j'ai vérifié la gestion des 

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Yuri Astrakhan]

I think a country relation should describe how the specific country think
of its borders. So if two countries claim the same territory, those two
relations will overlap.

While not ideal, this is preferable for many data consumers - when
generating a map, one always has to consider whom it is being generated
for.  E.g. it would be illegal in some countries to generate political map
not according to that country's government.  So when I generate a map for
Russia, I have to show Crimea as part of Russia.  For Ukraine - as part of
Ukraine.  Same for China and India and ...

On Sun, Oct 21, 2018 at 5:11 PM Mateusz Konieczny 
wrote:

>
>
>
> 21. Oct 2018 15:12 by dieterdre...@gmail.com:
>
> Therefore we can all be satisfied there is clear guidance from the board
> how to deal with this: the local situation determines how we map, and the
> OSMF is explicit here: “National borders are particularly sensitive.
> Currently, we record one set that, in OpenStreetMap contributor opinion, is
> most widely internationally recognised and best meets realities on the
> ground, generally meaning physical control.”
>
>
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.
> 
> pdf
>
> When I recently looked at Crimea I noticed it is still part of the Ucraine
> in OSM: https://www.openstreetmap.org/relation/60199
>
>
> Yes, situation on the ground is quite clear here.
>
>
> No matter whatever we like it or not, Crimea is no longer controlled by
> Ukraine and situation
>
> here is quite clear, unlike other affected regions.
>
> We should apply here "Note that OSM follows On the Ground Rule
> .
> Boundaries recorded in
> OpenStreetMap are ones that are the most widely internationally recognised
> and best meets realities
> on the ground, generally meaning physical control."
> ___
> 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] Fwd: DWG policy on Crimea

[Mateusz Konieczny]

21. Oct 2018 15:12 by dieterdre...@gmail.com :


> Therefore we can all be satisfied there is clear guidance from the board how 
> to deal with this: the local situation determines how we map, and the OSMF is 
> explicit here: “National borders are particularly sensitive. Currently, we 
> record one set that, in OpenStreetMap contributor opinion, is most widely 
> internationally recognised and best meets realities on the ground, generally 
> meaning physical control.”
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation. 
> >
>  pdf 
> When I recently looked at Crimea I noticed it is still part of the Ucraine in 
> OSM: > https://www.openstreetmap.org/relation/60199 
> 




Yes, situation on the ground is quite clear here.




No matter whatever we like it or not, Crimea is no longer controlled by Ukraine 
and situation

here is quite clear, unlike other affected regions.

We should apply here "Note that OSM follows On the Ground Rule 
. Boundaries 
recorded inOpenStreetMap are ones that are the most widely internationally 
recognised and best meets realitieson the ground, generally meaning physical 
control."
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] migrer les amenity=swimming_pool (déprécié)

[marc marc]

J'ai changé le titre pour bien montrer que je me focalisait
sur qu'un des points du problème plus général signalé par Noémie :
changer le tag déprécié amenity=swimming_pool car c'est
le problème le + gros en taille qu'elle a identifié.

je laisse l'autre sujet pour le reste pour éviter la noyade :)

Le 20. 10. 18 à 15:24, Paul Desgranges a écrit :

> ça devient un peu compliqué de discuter du reste

Je pense que cette phrase résume aussi bien ma pensée.
Faire des étapes pour parfois 3 cas, c'est se compliquer la vie !
Je les ai corrigé, c'est plus rapide et simple.
Surtout qu'ils étaient déjà exclu du périmètre
de l'opération de masse.

> comment avais-tu compté ?

avec overpass mais de manière cumulative (tag déprécié -A -B)
c'est pour cela que le détail intermédiaire n'est pas comparable.

>  ne répondre qu'à une petite partie.

je pensais n'avoir rien d’intéressant à dire sur le reste :)
Mais si tu insistes pour avoir mon avis, l'expérience a encore
montré récemment avec maxspeed:type qu'une édition de masse
qui se disperse reste à l'état de discussion sans aboutir.
Voilà pourquoi je suis partisan d'étapes indépendantes et
ciblées plutôt qu'une méga-opération ultra imbriquée.

Mais tu es totalement libre d'être plus optimiste que moi et
de mettre en place un tel plan, obtenir l'accord unanime que
nécessite une opération de masse, le documenter et l'effectuer.

> traiter tous ces cas spéciaux
> Pas forcément à la main
> Si tu es d'accord avec ça

non, je ne suis ni candidat ni d'accord pour faire des éditions
de masses avec les 244 cas restant basée sur des suppositions
(taux d'erreur trop élevé <> temps raisonnable pour regarder
cela individuellement).
J'en ai traité quelques centaines, dans les différentes catégories,
il n'y avait jamais une conclusion binaire à en tirer.

> avant de toucher aux 7000 qui restent, il faudra aviser à nouveau

ok, j'attends que tu ai avisé :-)

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

[Talk-es] semanarioOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

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

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

¡Disfruta!

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

[Talk-ca] hebdoOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

[Talk-cu] semanarioOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

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

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

¡Disfruta!

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

[talk-latam] semanarioOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

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

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

¡Disfruta!

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

[OSM-co] semanarioOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

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

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

¡Disfruta!

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

[OSM-talk-fr] hebdoOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

[Talk-ht] hebdoOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

[Talk-africa] hebdoOSM Nº 430 2018-10-06-2018-10-15

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

Re: [OSM-talk-fr] repère géodésique détruit

[marc marc]

Le 21. 10. 18 à 21:49, Alain VASSAULT a écrit :
> tu as la ref du point geodesique ou ces coordonnées?

il y les a 2, sur les 2 objets
https://www.openstreetmap.org/node/67945
https://www.openstreetmap.org/node/67946

> jai l'appli "beta" librement dispo sur le google store  
> pour consulter et report sur les fiches geodesique.

Je suis curieux de voir ce que cela va donner, merci.

> Le 21 octobre 2018 21:45:43 GMT+02:00, David Crochet 
> a écrit :
> 
> J'ai envoyé un message à l'adresse ad'hoc pour signaler la disparition
> de la croix, avec photo d'un média audiovisuel  à l'appui :

Merci, voyons voir leur réaction. au moins "osm" aura transmis :)

 Message transféré 
Sujet : repère géodésique détruit
Date : Sun, 21 Oct 2018 20:29:10 +0200
De : Marc M. 
Pour : talk-fr 

Bonjour,

Un constructeur signale le démontage d'un clocher d'église qui 
hébergeait 2 repères géodésiques.
https://www.openstreetmap.org/note/1563371
https://www.openstreetmap.org/node/67945
https://www.openstreetmap.org/node/67946
au niveau osm, c'est facile
was: devant le man_made=survey_point
un end_date
une maj de la description

mais je demandais :
- il y a a-t-il un outil QA qui va crier pour sa disparition ?
Si oui quel schéma supporte-t-il ?
- quelqu'un est en contact avec l'ign pour leur remonter l'info
s'ils ne l'ont pas ?

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

Re: [OSM-talk-fr] repère géodésique détruit

[Alain VASSAULT]

hello,
tu as la ref du point geodesique ou ces coordonnées?
jai l'appli "beta" librement dispo sur le google store pour consulter et report 
sur les fiches geodesique.



Le 21 octobre 2018 21:45:43 GMT+02:00, David Crochet  a 
écrit :
>Bonjour
>
>
>Le 21/10/2018 à 20:29, marc marc a écrit :
>> - quelqu'un est en contact avec l'ign pour leur remonter l'info
>> s'ils ne l'ont pas ?
>
>J'ai envoyé un message à l'adresse ad'hoc pour signaler la disparition 
>de la croix, avec photo d'un média audiovisuel  à l'appui :
>==
>
>To: s...@ign.fr
>From: David Crochet 
>Subject: No du Site 1432701
>Date: Wed, 17 Oct 2018 13:15:59 +0200
>
>
>Bonjour
>
>A priori la croix n'existe plus (comme le montre la photo) :
>
>https://france3-regions.francetvinfo.fr/normandie/sites/regions_france3/files/styles/top_big/public/assets/images/2017/05/25/petit_lourdes-3075653.jpg?itok=NxUQHd0c
>
>
>
>Cordialement
>
>-- 
>David Crochet
>
>==
>
>Cordialement
>
>-- 
>David Crochet
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] repère géodésique détruit

[David Crochet]

Bonjour


Le 21/10/2018 à 20:29, marc marc a écrit :

- quelqu'un est en contact avec l'ign pour leur remonter l'info
s'ils ne l'ont pas ?


J'ai envoyé un message à l'adresse ad'hoc pour signaler la disparition 
de la croix, avec photo d'un média audiovisuel  à l'appui :

==

To: s...@ign.fr
From: David Crochet 
Subject: No du Site 1432701
Date: Wed, 17 Oct 2018 13:15:59 +0200


Bonjour

A priori la croix n'existe plus (comme le montre la photo) :

https://france3-regions.francetvinfo.fr/normandie/sites/regions_france3/files/styles/top_big/public/assets/images/2017/05/25/petit_lourdes-3075653.jpg?itok=NxUQHd0c 



Cordialement

--
David Crochet

==

Cordialement

--
David Crochet


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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Imre Samu]

> When I recently looked at Crimea I noticed it is still part of the
Ucraine in OSM: https://www.openstreetmap.org/relation/60199

And part of Russia:
https://www.openstreetmap.org/relation/60189#map=6/45.014/33.873=C

Imre

Martin Koppenhoefer  ezt írta (időpont: 2018. okt.
21., V, 15:15):

> Dear all,
>
> we all know how sensible the topic of disputed boundaries can be (they are
> not necessarily a big problem, many boundary disputes like between Italy
> and France about the summit of Mont Blanc / Monte Bianco, have little
> bearing on the actual life of people).
>
> Therefore we can all be satisfied there is clear guidance from the board
> how to deal with this: the local situation determines how we map, and the
> OSMF is explicit here: “National borders are particularly sensitive.
> Currently, we record one set that, in OpenStreetMap contributor opinion, is
> most widely internationally recognised and best meets realities on the
> ground, generally meaning physical control.”
>
>
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.
> 
> pdf
>
> When I recently looked at Crimea I noticed it is still part of the Ucraine
> in OSM: https://www.openstreetmap.org/relation/60199
>
> As many might know, the current boundary situation for Crimea was frozen 4
> years ago “for a short time” by the DWG and so I asked them about their
> current position 2 months ago, and after I got no reply, tried to remind
> them 5 weeks ago, but have not yet gotten any reply, so I am now opening
> this thread here.
>
> IMHO, for consistency and credibility, we should either recognize that
> Russia is actually controlling Crimea, or we should update the disputed
> borders information. As I believe the general concept of ground truth for
> admin boundaries was a good idea, I would tend to the former.
>
> I also believe the actual situation has already been ignored for too long.
> When the thing is still dynamic or/and we’re in the middle of a conflict it
> can be wise to step back and see for some time how things are evolving, but
> 4 years are a lot of time, something like one year would seem more
> reasonable.
>
> What do you think?
>
> Cheers, Martin
>
> sent from a phone
>
> Begin forwarded message:
>
> *From:* Martin Koppenhoefer 
> *Date:* 20. August 2018 at 10:42:33 CEST
> *To:* d...@osmfoundation.org
> *Subject:* *DWG policy on Crimea*
>
>
> Dear members of the DWG,
>
> as of this question in the help forum:
>
>
> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>
>
> I kindly invite you to reconsider and eventually update your position on
> the situation in Crimea.
>
> As you have stated in 2014, this should not be the long term way to deal
> with the situation, and short term is probably coming to an end. There is
> clear guidance by the OSMF board how to deal with disputed boundaries (as
> the situation seems to be more stable than some would have liked).
>
> My motivation is not promoting the Russian point of view, but to act
> predictably and consistent wrt sensible topics.
>
> Thank you,
> cheers,
> Martin
>
> ___
> 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-fr] repère géodésique détruit

[marc marc]

Bonjour,

Un constructeur signale le démontage d'un clocher d'église qui 
hébergeait 2 repères géodésiques.
https://www.openstreetmap.org/note/1563371
https://www.openstreetmap.org/node/67945
https://www.openstreetmap.org/node/67946
au niveau osm, c'est facile
was: devant le man_made=survey_point
un end_date
une maj de la description

mais je demandais :
- il y a a-t-il un outil QA qui va crier pour sa disparition ?
Si oui quel schéma supporte-t-il ?
- quelqu'un est en contact avec l'ign pour leur remonter l'info
s'ils ne l'ont pas ?

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Frederik Ramm]

Hi,

On 10/21/18 16:44, Martin Koppenhoefer wrote:
> Aus meiner Erfahrung sehen das die meisten so, aber vermutlich mit dem 
> Hintergedanken des Minderheitenschutzes, kann man sich z.B. in Deutschland 
> bisher nicht auf ein Schema einigen und bevorzugt, beide Varianten zu 
> empfehlen.

Ich hab mal ins Blaue geschossen mit einem Entwurf:

https://wiki.openstreetmap.org/wiki/User:Frederik_Ramm/Fl%C3%A4chenverklebung

sowas in der Art könnte man ja mal fertigschreiben und dann abstimmen
und dann hat die leidige Diskussion vielleicht ein Ende...

Bye
Frederik

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

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

Re: [Talk-ca] Nova Scotia imports, and boundary=land_area

[Andrew Lester]

Hi Frederik, 

What this mapper is doing is not usual or desired. As you've seen by the 
changeset discussions and edit wars, the general OSM community does not agree 
with the way they're doing things. I sent them a message a few days ago 
pointing out a number of the issues you listed and suggesting that they take a 
break from adding new data to go back and fix these issues, but I see that 
they've continued to import with the same issues, and they haven't replied to 
my message. Based on what I've seen and read, I suspect: 
1. They only have a basic understanding of OSM, and certainly not enough 
knowledge or experience to be making the type of mass-edits they are. 
2. They may be mapping for the specific purpose of Garmin GPS map use, and as a 
result are misusing tags to fit that usage rather than changing their Garmin 
map generation process. 
3. They may not even be living in Nova Scotia (some of what I've read implies 
that they're mapping remotely and English may not be their primary language). 

At this point, I think it might be a good idea to have the DWG step in. Clearly 
this mapper isn't going to stop what they're doing based solely on 
communication from other mappers. It's already going to take a while to clean 
up the mess they've made, so we need to stop the creation of even more mess. 

Andrew Lester 
Victoria, BC, Canada 


From: "Frederik Ramm"  
To: "talk-ca"  
Sent: Sunday, October 21, 2018 6:18:24 AM 
Subject: [Talk-ca] Nova Scotia imports, and boundary=land_area 

Hi, 

there's a mapper in Canada - Darthmouthmapper - who seems to: 

1. import data from a source he calls "Nova Scotia Open Data" - I am not 
aware of any imports discussion, and the source specification is not 
precise enough to determine the legal status of that. Judging from past 
changeset comments, whatever imports procedure is used must have a 
number of flaws. 

2. import administrative boundaries 

2a. as a mesh of closed ways (where most people would prefer relations), 

2b. with, among other things, the tags "_Shape_Area_=yes", 
"addrcountry=Canada" (no colon!), "addr:postcode" (which is not 
generally used for objects that do not represent an address), and 
"type=land_area" (which is not generally used on closed ways). 

2c. The combination of a level-8 admin boundary and place=village is 
also unusual (eg https://www.openstreetmap.org/way/616463020) but I 
cannot judge if this is normal in Canada. This is also used in 
residential areas https://www.openstreetmap.org/way/636390857 - is this 
area really a "village"? 

3. use a ton of is_in tags which are highly unusual nowadays 

4. occasionally change existing relations (not ways) from type=boundary 
to type=land_area (https://www.openstreetmap.org/relation/8417484/history) 

5. add addr:postcode and addr:province to place=village nodes 

6. revert corrections applied to this by other users, claiming that "The 
video and instructions state these can be part of the ways" 

A number of people have complained in the past 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=698649 
but many of the issues seem to be present still. 

Before I ask him to fix this -- are any of the behaviours / mapping 
techniques outlined above somehow usual in Canada? 

Bye 
Frederik 

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

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

[Talk-ca] Microsoft Soundscape / WeeklyOSM 430

[John Whelan]

  It's under HOT "The English city St Albans" and its to do with 
navigation for the blind using OpenStreetMap.


I know Ottawa is fairly well mapped but what does the map need to make 
it more useful?  Anyone know?


Thanks John

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

Re: [Talk-ca] Nova Scotia imports, and boundary=land_area

[John Whelan]

Looks like the wiki needs amending to only list open data with the 
correct license either separately or a note added to each entry.  I have 
noticed before there is no authority listed on the wiki.


Cheerio John

Дмитрий Киселев wrote on 2018-10-21 10:28 AM:

About source, I suppose it's

https://wiki.openstreetmap.org/wiki/WikiProject_Canada#Open_Data [12]

вс, 21 окт. 2018 г. в 10:20, Frederik Ramm >:


Hi,

there's a mapper in Canada - Darthmouthmapper - who seems to:

1. import data from a source he calls "Nova Scotia Open Data" - I
am not
aware of any imports discussion, and the source specification is not
precise enough to determine the legal status of that. Judging from
past
changeset comments, whatever imports procedure is used must have a
number of flaws.

2. import administrative boundaries

2a. as a mesh of closed ways (where most people would prefer
relations),

2b. with, among other things, the tags "_Shape_Area_=yes",
"addrcountry=Canada" (no colon!), "addr:postcode" (which is not
generally used for objects that do not represent an address), and
"type=land_area" (which is not generally used on closed ways).

2c. The combination of a level-8 admin boundary and place=village is
also unusual (eg https://www.openstreetmap.org/way/616463020) but I
cannot judge if this is normal in Canada. This is also used in
residential areas https://www.openstreetmap.org/way/636390857 - is
this
area really a "village"?

3. use a ton of is_in tags which are highly unusual nowadays

4. occasionally change existing relations (not ways) from
type=boundary
to type=land_area
(https://www.openstreetmap.org/relation/8417484/history)

5. add addr:postcode and addr:province to place=village nodes

6. revert corrections applied to this by other users, claiming
that "The
video and instructions state these can be part of the ways"

A number of people have complained in the past
http://resultmaps.neis-one.org/osm-discussion-comments?uid=698649
but many of the issues seem to be present still.

Before I ask him to fix this -- are any of the behaviours / mapping
techniques outlined above somehow usual in Canada?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org

  ## N49°00'09" E008°23'33"

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



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


--
Sent from Postbox 

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Martin Koppenhoefer]

sent from a phone

> On 21. Oct 2018, at 12:36, Florian Lohoff  wrote:
> 
> Es ist halt auch ohne Straße als Fläche falsch. Der Graben neben der
> Straße, die Bankette, die Aleebäume gehören nicht zum Acker oder
> Wiese.


Aus meiner Erfahrung sehen das die meisten so, aber vermutlich mit dem 
Hintergedanken des Minderheitenschutzes, kann man sich z.B. in Deutschland 
bisher nicht auf ein Schema einigen und bevorzugt, beide Varianten zu empfehlen.


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

Re: [OSM-talk] Fwd: DWG policy on Crimea

[_ dikkeknodel]

Hi all,

I fully support the position summarized by statement “As you have stated in 
2014, this should not be the long term way to deal with the situation, and 
short term is probably coming to an end.” If the DWG does not share this 
position, they should provide an argument for it.

Cheers,
dikkeknodel


Van: Martin Koppenhoefer 
Verzonden: Sunday, October 21, 2018 3:12:03 PM
Aan: talk@openstreetmap.org
Onderwerp: [OSM-talk] Fwd: DWG policy on Crimea

Dear all,

we all know how sensible the topic of disputed boundaries can be (they are not 
necessarily a big problem, many boundary disputes like between Italy and France 
about the summit of Mont Blanc / Monte Bianco, have little bearing on the 
actual life of people).

Therefore we can all be satisfied there is clear guidance from the board how to 
deal with this: the local situation determines how we map, and the OSMF is 
explicit here: “National borders are particularly sensitive. Currently, we 
record one set that, in OpenStreetMap contributor opinion, is most widely 
internationally recognised and best meets realities on the ground, generally 
meaning physical control.”

https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf

When I recently looked at Crimea I noticed it is still part of the Ucraine in 
OSM: https://www.openstreetmap.org/relation/60199

As many might know, the current boundary situation for Crimea was frozen 4 
years ago “for a short time” by the DWG and so I asked them about their current 
position 2 months ago, and after I got no reply, tried to remind them 5 weeks 
ago, but have not yet gotten any reply, so I am now opening this thread here.

IMHO, for consistency and credibility, we should either recognize that Russia 
is actually controlling Crimea, or we should update the disputed borders 
information. As I believe the general concept of ground truth for admin 
boundaries was a good idea, I would tend to the former.

I also believe the actual situation has already been ignored for too long. When 
the thing is still dynamic or/and we’re in the middle of a conflict it can be 
wise to step back and see for some time how things are evolving, but 4 years 
are a lot of time, something like one year would seem more reasonable.

What do you think?

Cheers, Martin

sent from a phone

Begin forwarded message:

From: Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>>
Date: 20. August 2018 at 10:42:33 CEST
To: d...@osmfoundation.org
Subject: DWG policy on Crimea


Dear members of the DWG,

as of this question in the help forum:

https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea

I kindly invite you to reconsider and eventually update your position on the 
situation in Crimea.

As you have stated in 2014, this should not be the long term way to deal with 
the situation, and short term is probably coming to an end. There is clear 
guidance by the OSMF board how to deal with disputed boundaries (as the 
situation seems to be more stable than some would have liked).

My motivation is not promoting the Russian point of view, but to act 
predictably and consistent wrt sensible topics.

Thank you,
cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] Nova Scotia imports, and boundary=land_area

[Дмитрий Киселев]

About source, I suppose it's

https://wiki.openstreetmap.org/wiki/WikiProject_Canada#Open_Data [12]

вс, 21 окт. 2018 г. в 10:20, Frederik Ramm :

> Hi,
>
> there's a mapper in Canada - Darthmouthmapper - who seems to:
>
> 1. import data from a source he calls "Nova Scotia Open Data" - I am not
> aware of any imports discussion, and the source specification is not
> precise enough to determine the legal status of that. Judging from past
> changeset comments, whatever imports procedure is used must have a
> number of flaws.
>
> 2. import administrative boundaries
>
> 2a. as a mesh of closed ways (where most people would prefer relations),
>
> 2b. with, among other things, the tags "_Shape_Area_=yes",
> "addrcountry=Canada" (no colon!), "addr:postcode" (which is not
> generally used for objects that do not represent an address), and
> "type=land_area" (which is not generally used on closed ways).
>
> 2c. The combination of a level-8 admin boundary and place=village is
> also unusual (eg https://www.openstreetmap.org/way/616463020) but I
> cannot judge if this is normal in Canada. This is also used in
> residential areas https://www.openstreetmap.org/way/636390857 - is this
> area really a "village"?
>
> 3. use a ton of is_in tags which are highly unusual nowadays
>
> 4. occasionally change existing relations (not ways) from type=boundary
> to type=land_area (https://www.openstreetmap.org/relation/8417484/history)
>
> 5. add addr:postcode and addr:province to place=village nodes
>
> 6. revert corrections applied to this by other users, claiming that "The
> video and instructions state these can be part of the ways"
>
> A number of people have complained in the past
> http://resultmaps.neis-one.org/osm-discussion-comments?uid=698649
> but many of the issues seem to be present still.
>
> Before I ask him to fix this -- are any of the behaviours / mapping
> techniques outlined above somehow usual in Canada?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


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

Re: [OSM-ja] JOSMプリセットファイル(XMLファイル)の共有

[tomoya muramoto]

hayashi様

ありがとうございます。
あまり使い方を理解できていないかもしれませんが、とりあえず作ってみました。

編集用リンク：
https://github.com/tankaru/JOSM_Presets/blob/master/EasyPresetsTunnel.xml

ダウンロード用リンク：
https://github.com/tankaru/JOSM_Presets/raw/master/EasyPresetsTunnel.xml

("Restrict editing to collaborators only"のチェックを外したので、誰でも編集できるはず…？)

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

[OSM-ja] 日本の「Acces / 交通手段による制限 - 陸上交通 車両種別アクセス」について

[yuu hayashi]

hayashiです

５月に行われた「[OSM-ja] 高速道路の定義について」の中で承認された「 提案2 accessタグの車両種別について日本での定義を取り決める
」作業ですが、
やっと、なんとかまとめることができました。

Acces / 交通手段による制限 - 陸上交通 車両種別アクセス
日本の「車両別アクセスタグ」の提案

OSM_Wiki「JA talk:Key:access 議論のページ」
https://wiki.openstreetmap.org/wiki/JA_talk:Key:access#.E3.80.8C.E8.87.AA.E5.8B.95.E8.BB.8A.E5.B0.82.E7.94.A8.E3.80.8D.E6.A8.99.E8.AD.98.E3.81.AE.E4.BE.8B

に記載しています。

皆様にお願いです。
１） 誤字脱字など見つけたら直してください。
２） 他のWikiページへのリンクがあればLINKしてください。
３） 改善点やもっといい方法があれば 書き加えてください。
４） こんな場合はどうするの？という疑問点があれば 書き加えるか Talk-jaに質問してください。
４） 「ここは、なぜこうしたの？」でも構いません
５） 難しそうな交通標識を見つけたら写真に撮って 
に送ってください（Wikiにアップするので権利関係がきれいなものに限る）

特に（５）の「写真」を待っています。
11月末まで WikiPegeの変更を受け付けようと思います。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-ca] Nova Scotia imports, and boundary=land_area

[Frederik Ramm]

Hi,

there's a mapper in Canada - Darthmouthmapper - who seems to:

1. import data from a source he calls "Nova Scotia Open Data" - I am not
aware of any imports discussion, and the source specification is not
precise enough to determine the legal status of that. Judging from past
changeset comments, whatever imports procedure is used must have a
number of flaws.

2. import administrative boundaries

2a. as a mesh of closed ways (where most people would prefer relations),

2b. with, among other things, the tags "_Shape_Area_=yes",
"addrcountry=Canada" (no colon!), "addr:postcode" (which is not
generally used for objects that do not represent an address), and
"type=land_area" (which is not generally used on closed ways).

2c. The combination of a level-8 admin boundary and place=village is
also unusual (eg https://www.openstreetmap.org/way/616463020) but I
cannot judge if this is normal in Canada. This is also used in
residential areas https://www.openstreetmap.org/way/636390857 - is this
area really a "village"?

3. use a ton of is_in tags which are highly unusual nowadays

4. occasionally change existing relations (not ways) from type=boundary
to type=land_area (https://www.openstreetmap.org/relation/8417484/history)

5. add addr:postcode and addr:province to place=village nodes

6. revert corrections applied to this by other users, claiming that "The
video and instructions state these can be part of the ways"

A number of people have complained in the past
http://resultmaps.neis-one.org/osm-discussion-comments?uid=698649
but many of the issues seem to be present still.

Before I ask him to fix this -- are any of the behaviours / mapping
techniques outlined above somehow usual in Canada?

Bye
Frederik

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

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

[OSM-talk] Fwd: DWG policy on Crimea

[Martin Koppenhoefer]

Dear all,

we all know how sensible the topic of disputed boundaries can be (they are not 
necessarily a big problem, many boundary disputes like between Italy and France 
about the summit of Mont Blanc / Monte Bianco, have little bearing on the 
actual life of people).

Therefore we can all be satisfied there is clear guidance from the board how to 
deal with this: the local situation determines how we map, and the OSMF is 
explicit here: “National borders are particularly sensitive. Currently, we 
record one set that, in OpenStreetMap contributor opinion, is most widely 
internationally recognised and best meets realities on the ground, generally 
meaning physical control.”

https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf 

When I recently looked at Crimea I noticed it is still part of the Ucraine in 
OSM: https://www.openstreetmap.org/relation/60199

As many might know, the current boundary situation for Crimea was frozen 4 
years ago “for a short time” by the DWG and so I asked them about their current 
position 2 months ago, and after I got no reply, tried to remind them 5 weeks 
ago, but have not yet gotten any reply, so I am now opening this thread here.

IMHO, for consistency and credibility, we should either recognize that Russia 
is actually controlling Crimea, or we should update the disputed borders 
information. As I believe the general concept of ground truth for admin 
boundaries was a good idea, I would tend to the former.

I also believe the actual situation has already been ignored for too long. When 
the thing is still dynamic or/and we’re in the middle of a conflict it can be 
wise to step back and see for some time how things are evolving, but 4 years 
are a lot of time, something like one year would seem more reasonable.

What do you think?

Cheers, Martin 

sent from a phone

Begin forwarded message:

> From: Martin Koppenhoefer 
> Date: 20. August 2018 at 10:42:33 CEST
> To: d...@osmfoundation.org
> Subject: DWG policy on Crimea
> 
> 
> Dear members of the DWG,
> 
> as of this question in the help forum:
> 
> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>  
> 
> I kindly invite you to reconsider and eventually update your position on the 
> situation in Crimea.
> 
> As you have stated in 2014, this should not be the long term way to deal with 
> the situation, and short term is probably coming to an end. There is clear 
> guidance by the OSMF board how to deal with disputed boundaries (as the 
> situation seems to be more stable than some would have liked).
> 
> My motivation is not promoting the Russian point of view, but to act 
> predictably and consistent wrt sensible topics.
> 
> Thank you,
> cheers,
> Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-ja] JOSMプリセットファイル(XMLファイル)の共有

[yuu hayashi]

hayashiです

Q. JOSMプリセットファイル(XMLファイル)の公開・共有に適したサービスはございませんでしょうか。
A. GitHub（https://github.com/）がよいと思います。

(0)まずはXMLファイルが共有できる。 ← 問題ない
(1)osm wikiのように、だれでも編集できるようにしたい。 ← OSM Wikiのレベルで誰でもできる＋Pull Request
という仕掛けも用意されてる
(2)編集履歴が残ると嬉しい。編集者もわかると助かる。 ← 問題なし
(3)オンラインで編集できると楽。 ← 問題なし
(4)ダウンロード用リンクと編集用リンクを別々に生成できると便利かも。 ← 問題なし（GitHub pages）
(5)できたら個人のアカウントに依存したくない。 ←
完全にパブリックドメインにするのは無理だけど、作成者本人が死亡したとしてもcloneが生き続けるので実質問題なし

手前味噌ですが GitHubの利用例も載せときます
https://github.com/yuuhayashi/coverageWeb/blob/master/README.md
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-ja] JOSMプリセットファイル(XMLファイル)の共有

[tomoya muramoto]

みなさま

トンネルの銘板マッピング向けにJOSMプリセットを作成したので共有しました。
https://1drv.ms/u/s!AvZ5JdN9PK_-j0-tsVo-BuIQdTsJ
(プリセットの作成にはEasyPresetsを使用させていただきました。作成者のMaripo GODA様、ありがとうございます。)

質問なのですが、
JOSMプリセットファイル(XMLファイル)の公開・共有に適したサービスはございませんでしょうか。

個人的には、以下のようなことができるサービスが良いのかなぁと考えています。(なんとなくの優先度順)
(0)まずはXMLファイルが共有できる。
(1)osm wikiのように、だれでも編集できるようにしたい。
(2)編集履歴が残ると嬉しい。編集者もわかると助かる。
(3)オンラインで編集できると楽。
(4)ダウンロード用リンクと編集用リンクを別々に生成できると便利かも。
(5)できたら個人のアカウントに依存したくない。

・OneDriveはそこそこよさそうなのでトンネル銘板プリセットにはこれを使いましたが、(2)(4)(5)あたりがダメそう。
・Dropboxは、(2)(4)(5)に加えて、(3)もダメだった(はず)。
・OSM wikiはそもそも(0)がダメ(XMLファイルのアップロードができなかった)

他によさそうなサービスをご存知でしたら教えていただけると助かります。

よろしくお願いします。

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

Re: [OSM-ja] トンネルの銘板

[tomoya muramoto]

JOSM用プリセットをOneDriveに上げました。よろしければお使いください。誰でも編集可能にしてあります。
https://1drv.ms/u/s!AvZ5JdN9PK_-j0-tsVo-BuIQdTsJ
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-ie] OpenStreetMap Ireland CLG launch yesterday

[Ciarán Staunton]

Greetings All
On behalf of the board I want to thank you for attending the launch and the
open mic event yesterday.

For the benefit of those that missed it we saw a fantastic look back at the
history of the community from mackerski. dónál went through the legalities
of the company set up, how we got to where we are now and that we will be
formally applying for chapter status with osmf. I myself (debigc) let
everyone know what to expect in term of activity for the next year, as we
bring the participation, connection, visibility and exchange to the next
level.

The open mics were all really interesting too, to summarise them we would
have to point to the diversity of platforms, motivations, focus, interest
that is out there in the broader community. The wealth of the asset that is
openstreetmap is the wealth of the knowledge you are all putting into it.
As all the speakers at the start said in one way or another pulling
together and being more coherent as a community is where we are navigating
to right now.

Keep up the great work everyone!
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[OSM-talk-ie] Collinstown Townland has been re mapped as Dublin Airport!

[Brian Hollinshead]

While adding the Malahide Union of parishes to the map which uses a
combination of the old civil parish boundaries I find that Collinstown
townland (relation/5436241) has been seriously redrawn if compared to the
GSGS 3906 map and maps.openstreetmap.ie. Rorys townlands.ie shows the post
changes state.
It looks as thought someone thought Collinstown Airport was the new
townland.

The border between townland of Forrest Little(relation 5440762) and
Clonshaugh, Corballis and Huntstown has been quite altered between
53.435847/-6.236136 and 53.4316541/-6.2644.

I believe this also alters some Barony and Superintendent Registrars
District boundaries so feel it is highly preferable that these changes be
reversed intact.

I regret this is way above my capability so I ask for someone reading this
to please address this issue.

Thank you for your kindness.

By the way, Many thanks to those organised such an enthusiastic meeting in
Maynooth yesterday, the future looks good.
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Florian Lohoff]

On Sat, Oct 20, 2018 at 10:43:08PM +0200, sepp1...@posteo.de wrote:
> ...Straßen sind da nur ein Beispiel ;-)
> 
> Darum gehts doch offenbar nicht. Woruauf soll ich mich denn als Mapper
> beziehen? Auf ein stellenweise wenig bis gar nicht aussagekräftiges Wiki,
> auf Meinung A, B oder C aus einem Forum, möglichst noch auf stellenweise
> uralte Forenbeiträge von 18-Hundertfrühling oder kann ich's selbst
> entscheiden, nachdem ich zumindest die Möglichkeit hatte, mir Vor- und
> Nachteile der jeweiligen Variante mal zu Gemüte zu führen um es auch zu
> verstehen, warum, weshalb, wieso?

Im Wiki darf jeder schreiben und ändern. Das als Konsens dartzstellen
ist halt eher nicht richtig. Gerade die Deutschen Wiki Artikel
weichen Teilweise Willkürlich von den Englishen ab und es ist nicht
ersichtlich wer oder warum oder welcher konsens dazu geführt haben
soll. Dann Fehlen Begriffserklärungen - Mein Lieblingsthema ist
da "Wasserwirtschaft" was gerne mit "Bundeswasserstraßen" gleichgesetzt
wird und schon ist alles nur noch ein Wirtschaftsweg und damit ein
Track. Und dann weiss man auch nicht mehr wo man anfangen soll. Ohne
konsens Wiki artikel geändert und mit begriffen angereichert die
Missverständlich sind und schon passieren die wunderlichsten dinge
in der Karte.

Im Falle von verkleben von Flächen sehe ich da ein eindeutige Meinung
im Wiki und verstehe auch nicht woher diese Verkleberei ausser
als "Unfall" kommt:

https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes

Areas and Ways Sharing Nodes

There is not clear consensus yet on how to draw areas adjacent to ways.
They may be drawn either by leaving a small gap between the area and the
way or by connecting them so that the area shares nodes with the way.
That being said, when the way is a highway, it usually is most accurate
to include a gap, so that the area ends by the side of the road and does
not share nodes with the road's way. This is because highway ways
usually are traced along the centerline of the road, and it is unlikely
that the area being tagged actually extends to the center of the road. 

Das steht da ziemlich unverändert seit ewigen Zeiten. Die Essenz dessen
ist ziemlich eindeutig:

"That being said, when the way is a highway, it usually is most accurate
to include a gap, so that the area ends by the side of the road and does
not share nodes with the road's way."

So - Und da wir an einer Geodatensammlung arbeiten deren Ziel
Genauigkeit und Vollständigkeit ist ist es völlig klar das nach dem
Tenor dieses Absatzes ein Entkleben die Qualität steigert und eben "most
accurate" ist.

Ja - Es gibt das verkleben von Flächen und Wegen - und technisch mag das
auch funktionieren, leider ist es eben ungenau und vor allem nach meiner
Erfahrung sehr Fehlerträchtig. Es ist eben irgendwann nicht mehr
ersichtlich welche und wieviele Wege da übereinander liegen und welche 
miteinander verbunden ist. Nicht jeder node muss ja mit allen
übereinander liegenden Wegen verbunden sein - er kann auch nur mit einem
subset verbunden sein. Und das sind spannende Routingfehler zum Suchen.

> Ohne jetzt hier ne Diskussion anzufachen - es geht doch schlussendlich
> darum, die Realität abzubilden und in dieser gibt es KEINE leeren Flächen
> und daraus ergibt sich zwangsläufig das Verkleben dieser jenigen welchen. Ob
> es nun Sinn macht, Straßenbelag als Fläche zu mappen, sei mal dahin
> gestellt. Der Kompromiss könnte bspw. in einer einvernehmlichen Festlegung
> oder besser Empfehlung bestehen, angrenzende Flächen nicht zu verkleben,
> solange Straßenbelagfläche nicht gemappt wurde, usw. usf. <= nur muss sowas
> irgendwo nachlesbar sein und zwar nicht in einem Forenbeitrag von 2009 auf
> Seite 24, vorletzter Seiteneintrag nach Bemühen einer Suchfunktion. Es
> scheitert doch beim Neuuser schon meist an der richtigen Begrifflichkeit, um
> eine Suche auch effektiv auszuführen. Mal ganz abgesehen davon, mappt der
> Neuuser wahrscheinlich erstmal direkt im Browser, klickt auf's Wiki und
> erfährt u.U. nicht viel bis gar nix. Der sucht nicht nach irgendeinem Forum
> und dort auch noch nach einem bestimmten Thema oder fragt in einer
> Telegrammgruppe oder wartet, bis der nächste stammtisch in seiner Stadt
> stattfindet.

Es ist halt auch ohne Straße als Fläche falsch. Der Graben neben der
Straße, die Bankette, die Aleebäume gehören nicht zum Acker oder
Wiese.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Florian Lohoff]

Hola,

On Sat, Oct 20, 2018 at 07:11:39PM +0200, Martin Koppenhoefer wrote:
> sent from a phone
> 
> > On 20. Oct 2018, at 18:23, sepp1...@posteo.de wrote:
> > In der Realität gibt es nunmal keine "leeren Flächen",
> 
> in OSM gibt es aber leere Flächen: wo bisher noch nicht gemappt wurde.
> Wenn in Deutschland leere Flächen neben der Straße stören dann liegt
> es vermutlich daran, dass die Straße noch nicht als Fläche gemappt ist

Das ist in der tat ein riesen Problem das es mapper gibt die "leere"
Flächen nicht ertragen und da wird jeder Quadratcentimenter in ein
landuse gepfriemelt und das alles an die Straßen geklebt weil ja
ansonsten da ein "nichts" entsteht z.B. durch die mangelnde
Breitenrendering Geschichte der Straßen im Mapnik.

Da wird ein 50cm Streifen Bankette zwischen Radweg und Straße in ein
landuse=grass gebaut und der dann auf Straße und Radweg gezogen.
Oder der Ackerrand wird zu einem natural=scrub auch wenn das
nur die breite ist der man eben mit dem Pflug nicht an den Graben
kann weil das sonst abrutscht.

Ich weiss dann nie wo ich anfangen soll wenn da was falsch ist.
Am Ende will man nichts entfernen oder löschen aber ohne da mal
eloquent auf den DEL key zu drücken ist das oft nicht mehr
aufzulösen. 

Und wenn wir über Straßen als Flächen reden dann sind wir auch
bei Bankette, Straßengegleitender Graben (Der ja zur Straße gehört),
Aleebäume. Die mapper die dann kein "nichts" ertragen können ziehen dann das
Farmland bis zur Straße und dann sind die Allebäume und der Graben und
die Bankette teil des Ackers - und DAS ist sachlich falsch.

Vielleicht bin ich da auch nur so verbissen weil ich erahne wieviel
Mannmonate ich damit verbracht haben so einen Kram aufzuräumen
und Fehler in den Daten zu finden. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

[Talk-ca] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

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

[Talk-us] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

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

[OSM-talk] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-ie] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

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

[Talk-GB] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[talk-ph] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-in] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

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

[Talk-africa] weeklyOSM #430 2018-10-06-2018-10-15

[weeklyteam]

The weekly round-up of OSM news, issue # 430,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10822/

Enjoy!

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

Re: [OSM-talk] OpenStreetMap Carto release v4.16.0

[Daniel Koć]

W dniu 20.10.2018 o 11:03, Stephan Knauss pisze:
> Bitmap based pre-rendered maps are always a trade-off.
>
> If you are looking for a more "google-like" dynamic map, then check
> out the vector tiles based maps which support search for amenities and
> can dynamically display features.

It doesn't have to be proper vector map. Dynamic overlay works against
simple bitmap background (including OSM Carto by default):

http://openpoimap.org

-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

+1

Gruß

> On 20. Oct 2018, at 22:43, sepp1...@posteo.de wrote:
> 
> [..] Ob es nun Sinn macht, Straßenbelag als Fläche zu mappen, sei 
> mal dahin gestellt. Der Kompromiss könnte bspw. in einer 
> einvernehmlichen Festlegung oder besser Empfehlung bestehen, angrenzende 
> Flächen nicht zu verkleben, solange Straßenbelagfläche nicht gemappt 
> wurde, usw. usf. <= nur muss sowas irgendwo nachlesbar sein und zwar 
> nicht in einem Forenbeitrag von 2009 auf Seite 24, vorletzter 
> Seiteneintrag nach Bemühen einer Suchfunktion. [..]
> 
> Grüße
> Sepp

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Markus]

Liebe Mit-OSMer,

Am 20.10.2018 um 22:43 schrieb sepp1...@posteo.de:
> Woruauf soll ich mich denn als Mapper beziehen?

Diese wesentliche Frage ist bei OSM "seit Jahrzehnten" nicht zielführend
beantwortet. Dabei verstecken wir uns hinter "Mapping-Freiheit" - in
Wirklichkeit vermute ich aber, dass wir immer noch nicht den Mut haben,
sowas wie "Best Practice" festzuhalten und zu teilen.

*Jeder Mapper hat immer gute Absichten*

Deshalb sucht er nach Information, um seine Arbeit *gut* zu machen.
Diese muss ihm schnell, simpel und verständlich zugänglich sein :-)

Leider entwickelt sich die Welt gerade in eine grauslige Moral.
Incl. verrohender Umgangsformen.

Ich würde mir sehr wünschen, wenn wir hier eine bessere Welt gestalten.
Freundliche, wertschätzende und partnerschaftliche Umgangsformen sind
für mich selbstverständliche Voraussetzung.

Mit herzlichem Gruss,
Markus

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