Re: [OSM-talk] Duplicate ways in multipolygon relations

[Warin]

More Problems

1) Source

 .. the source tags can be in the relation and not the way ...
Change the way to the new source and yet the other relations all say it is some 
other source.

My conclusion is that the source should be on the way.

2)

Are the other relations, that refer to this way, that are being changed by the 
new source ok with this change?

3)

You are going to have to compare each new outline with the old outlines ..
Where they are the same (or within, say, 3 metres) then leave the old way there 
and mark it checked=new source + date

(the 3 metres comes from the JOSM simplify way set to a default of 3 metres, 
I'd use the same level of accuracy here)

4)
Where the boundary lies along a waterway for some distance .. I would tend not 
to join them.
The water course can change over time, the boundary is usually set not to 
follow changes in the water course.



On 19-Feb-17 03:52 PM, nwastra wrote:

…..Actually, all the overlapping ways in the current shapefile are where 
adjacent relations meet.


On 19 Feb 2017, at 2:04 PM, nwastra  wrote:

Hi
is there a JOSM plugin to assist with duplicate ways?

We have been given explicit permission to use a good data set of shapefiles 
that define boundaries for the OSM.

Using JOSM, my method is to select the shapefile relation for a particular 
National Park for instance then merge the selection into the OSM Data Layer. 
Often a replace geometry is needed on many polygons to help preserve the 
history. Add all the tags to the relation.

Then the hard part….
You have to cut up and conflate the new boundaries with the existing data.
All the duplicate overlying ways need to be selected, nodes entered, nodes 
merged and joined at the end, boundary and nodes selected where split is 
performed, remove extra over lapping ways to generally leave one, add that one 
left to this or another relation. Add more tags as needed.
Then selection each relation that was affected and view the result to see if it 
is complete.

In some areas there are likely to be National Parks and other protected areas, 
forestry areas, etc all adjacent to each other with boundaries that meet.

Another method I use is to split up the relation before merging piece by piece 
but is just as complex.

Another method is to leave the overlapping ways for someone else to sort out.

In some relations there may be 30 or so adjacent polygons with ways partially 
overlapping so is a lot of work that I think would be ideal for plugin 
assistance and efficiency.
It seems to me that if one relation is selected at a time, it should be a task 
able to be mostly automated by programming. Then it would be up to the mapper 
to verify and quality control the result.

I am a new user to QGis and wonder if the splitting and conflating of the 
shapefile to be merged can be done in QGis prior to introduction to JOSM and 
then would only need to sort out areas between adjacent relations.

Is it best not to bother doing this anyway or even preferable to leave all the 
polygons as individual entities with overlapping ways?

Finally, I should add that I do try to add small discreet areas and relations 
one at a time that are manageable before proceeding.

Nev



___
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] Duplicate ways in multipolygon relations

[nwastra]

…..Actually, all the overlapping ways in the current shapefile are where 
adjacent relations meet.

> On 19 Feb 2017, at 2:04 PM, nwastra  wrote:
> 
> Hi
> is there a JOSM plugin to assist with duplicate ways?
> 
> We have been given explicit permission to use a good data set of shapefiles 
> that define boundaries for the OSM.
> 
> Using JOSM, my method is to select the shapefile relation for a particular 
> National Park for instance then merge the selection into the OSM Data Layer. 
> Often a replace geometry is needed on many polygons to help preserve the 
> history. Add all the tags to the relation. 
> 
> Then the hard part….
> You have to cut up and conflate the new boundaries with the existing data. 
> All the duplicate overlying ways need to be selected, nodes entered, nodes 
> merged and joined at the end, boundary and nodes selected where split is 
> performed, remove extra over lapping ways to generally leave one, add that 
> one left to this or another relation. Add more tags as needed.
> Then selection each relation that was affected and view the result to see if 
> it is complete.
> 
> In some areas there are likely to be National Parks and other protected 
> areas, forestry areas, etc all adjacent to each other with boundaries that 
> meet.
> 
> Another method I use is to split up the relation before merging piece by 
> piece but is just as complex.
> 
> Another method is to leave the overlapping ways for someone else to sort out.
> 
> In some relations there may be 30 or so adjacent polygons with ways partially 
> overlapping so is a lot of work that I think would be ideal for plugin 
> assistance and efficiency. 
> It seems to me that if one relation is selected at a time, it should be a 
> task able to be mostly automated by programming. Then it would be up to the 
> mapper to verify and quality control the result.
> 
> I am a new user to QGis and wonder if the splitting and conflating of the 
> shapefile to be merged can be done in QGis prior to introduction to JOSM and 
> then would only need to sort out areas between adjacent relations. 
> 
> Is it best not to bother doing this anyway or even preferable to leave all 
> the polygons as individual entities with overlapping ways?
> 
> Finally, I should add that I do try to add small discreet areas and relations 
> one at a time that are manageable before proceeding. 
> 
> Nev 
> 


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

[OSM-talk] Duplicate ways in multipolygon relations

[nwastra]

Hi
is there a JOSM plugin to assist with duplicate ways?

We have been given explicit permission to use a good data set of shapefiles 
that define boundaries for the OSM.

Using JOSM, my method is to select the shapefile relation for a particular 
National Park for instance then merge the selection into the OSM Data Layer. 
Often a replace geometry is needed on many polygons to help preserve the 
history. Add all the tags to the relation. 

Then the hard part….
You have to cut up and conflate the new boundaries with the existing data. 
All the duplicate overlying ways need to be selected, nodes entered, nodes 
merged and joined at the end, boundary and nodes selected where split is 
performed, remove extra over lapping ways to generally leave one, add that one 
left to this or another relation. Add more tags as needed.
Then selection each relation that was affected and view the result to see if it 
is complete.

In some areas there are likely to be National Parks and other protected areas, 
forestry areas, etc all adjacent to each other with boundaries that meet.

Another method I use is to split up the relation before merging piece by piece 
but is just as complex.

Another method is to leave the overlapping ways for someone else to sort out.

In some relations there may be 30 or so adjacent polygons with ways partially 
overlapping so is a lot of work that I think would be ideal for plugin 
assistance and efficiency. 
It seems to me that if one relation is selected at a time, it should be a task 
able to be mostly automated by programming. Then it would be up to the mapper 
to verify and quality control the result.

I am a new user to QGis and wonder if the splitting and conflating of the 
shapefile to be merged can be done in QGis prior to introduction to JOSM and 
then would only need to sort out areas between adjacent relations. 

Is it best not to bother doing this anyway or even preferable to leave all the 
polygons as individual entities with overlapping ways?

Finally, I should add that I do try to add small discreet areas and relations 
one at a time that are manageable before proceeding. 

Nev 


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

Re: [Talk-it] mappatura armadi telefonici

[Martin Koppenhoefer]

sent from a phone

> On 18 Feb 2017, at 19:04, Andrea Solari  wrote:
> 
> Ciao
> qualcuno ha iniziato a mappare gli armadi telefonici Tim/Telecom per la
> fibra ottica?


si:
http://www.openstreetmap.org/node/457644


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

Re: [OSM-talk-fr] HebdoOSM

[Philippe Verdy]

I'm not speaking about how German or Spanish version are produced or even
if there are reviewers on the English version. For now there's a clear lack
of actual translators for French and all this is google-like translated
with too much non-sense.

Also I spoke about the selection of topics when it is clear that many of
them are of German origin (and links to articles are not translated at all
for most of them), and interesting about German projects and point of
views. There's a clear lack of audting elsewhere.

You're describing the ideal of how this should work, but now what can be
perceived from now. And the main reason is probably because the project
lacks communacitions and requires too mcuh technical background. What I
proposed was to produce independant RSS-like feeds from several regions
(with a minimu mset of translation to English) to help feed these news. But
French topics are mostly covered on this French mailing list (never
referenced anywhere in WeeklyOSM) or on the French OSM site. Even topics
transalted in English on the .org wiki are in fact not read (as well as
their talk pages with a very low activity because of this).

But anyway participating to the wiki is much simpler than to your project
which uses specific tools: this means there are less reviewers and all
tasks are done only by a few persons (possibly working outside the actual
collaborative work for their OSM oragnization in their area). The barriers
are visible, and this also limits your audience, and even the interest to
translate these news as is due to the limited view and personal preferences
only for some topics.

I do not mean that the result needs to be perfect English, but a minimum
understanding is still required, both from producers (selectors of topics)
and translators. The frequency of WeeklyOSM also does not help doing this
correctly in a timely manner: transaltions are posted too soon, or
selections are inserted possibly too soon, when each topic could be worked
on individually (instead of weekly issue by issue): if something is not
clear, it can be delayed in all languages and we don't need to publish
non-sense or things that are not understandable. You don't need to produce
a constant weekly "volume" of news.

One way of doing this would be to integrate a contact email or forum to
signal some topics that can be discussed and explained correctly, or
allowing independant groups to produce their own feeds, that you'll
agregate. Those feeds could be anywhere (including on Twitter or Facebook
pages: people have their prefered methods and channels for communicating).
Each channel can have a few persons performing a selection and posting some
summaries of what happened in a known feed. My opinion if WeeklyOSM should
then become more an aggregator. As more people will be involved they will
be more likely to translate correctly the few sentences needed, and links
will point to the relevant groups/projects where these originate and are
discussed or developed.

But finally there should be a way to generate separate newsfeeds and
integrate other items than those selected initilly introduced on the
English feed (which does not need to be the first one available. Making the
feeds more granular (topic by topic) and ordered individually (per language
as they are really ready) will improve the quality of what is published for
everyone.

Still I maintain that someone using bots to translate automatically things
without understanding them is a bad practice: it is not followed everywhere
else: you need to educate your contributors. Some tools can facilitate, but
compare to jobs made by bots and at the existing policy in OSM for Bots
imports : we require integration, not blind massive imports (and this
necessarily involved collaboration with others instead of working alone to
take the leadership).


2017-02-18 22:21 GMT+01:00 Manfred A. Reiter :

> 2017-02-18 21:10 GMT+01:00 Philippe Verdy :
>
> Et c'est encore plus vrai pour WeeklyOSM quand la source originale n'est
>> en fait même pas l'anglais (souvent l'allemand, l'espagnol ou le russe), et
>> où la version anglais proposée comme source est en fait une traduction
>> approchante qui peut déjà contenir des tas de fautes de sens ou de
>> grammaire non corrigées (surtout celles venant en fait du russe et de
>> l'espagnol dont les locuteurs maîtrisent souvent plus mal l'anglais que les
>> germanophones...) ce qui "perd" encore plus les traducteurs automatiques
>> partant de cette traduction anglaise approximative.
>>
>
> @all pardonnez moi, que je dise ici quelque chose en anglais. Je promesse,
> que je termine - pour ma part - cette discussion.
> Sorry, I admire your language, but I must correct some things, which are
> really not as correct as they could be.
>
> Let me tell it once again and very clear: You are talking about a process,
> that you don't know - not at all.
>
> I repeat here in short words again:
>
> 1. each language is produced 

Re: [OSM-talk-fr] HebdoOSM

[Manfred A. Reiter]

2017-02-18 21:10 GMT+01:00 Philippe Verdy :

Et c'est encore plus vrai pour WeeklyOSM quand la source originale n'est en
> fait même pas l'anglais (souvent l'allemand, l'espagnol ou le russe), et où
> la version anglais proposée comme source est en fait une traduction
> approchante qui peut déjà contenir des tas de fautes de sens ou de
> grammaire non corrigées (surtout celles venant en fait du russe et de
> l'espagnol dont les locuteurs maîtrisent souvent plus mal l'anglais que les
> germanophones...) ce qui "perd" encore plus les traducteurs automatiques
> partant de cette traduction anglaise approximative.
>

@all pardonnez moi, que je dise ici quelque chose en anglais. Je promesse,
que je termine - pour ma part - cette discussion.
Sorry, I admire your language, but I must correct some things, which are
really not as correct as they could be.

Let me tell it once again and very clear: You are talking about a process,
that you don't know - not at all.

I repeat here in short words again:

1. each language is produced by native speakers.
2. if an article is in ES, the ES deliver an EN as well.  (Yes, in a not
perfect EN)
3. The EN is checked by at least two native speakers - or as in this example
 4 (in words four) experienced mappers
4. Where do you see a problem, when an article is written in Spanish and
English by a mapper from Bolivia, the English corrected by a mapper in
Australia, Canda, India and London? The result should be a nearly perfect
English. Do you agree?
4.1. Don't forget that the Spanish version is corrected by native speakers
as well. a least two, in this example four people as well
.
5. Wehre is now the problem, if I translate it into German? And be aware
the German version is proofread be at least two German native speaker. -
What is your quality issue?

May be you have better porcesses to deliver a better summary what happens
in the OSM ecosystem each week. We don't have.

Finally, let me admit that I personally see a real problem - we do not
report adequately about what is happening in the French community. French
community means not only France, but also francophone Africa and
francophone Canada.

Producing 52 versions per year is perhaps a bit more difficult and needs
more dedication than keeping a inflammatory speech

.

Anyway - I hope we see us in Avignon ;-)

-- 
## Manfred Reiter - -
## N49° 25' 11.028" E6° 50' 47.328"
## www.weeklyOSM.eu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] HebdoOSM

[JB]

Bon ben comme ça, on a un non-lecteur non-traducteur qui n'est pas 
d'accord avec les autres. Il serait non-au-courant, ça arrangerait juste 
tout le monde.

C'était mon mauvais esprit du soir, bon week-end,
JB.

Le 18/02/2017 à 21:10, Philippe Verdy a écrit :



Le 18 février 2017 à 15:47, Julien Coupey > a écrit :


Comme ça a été dit, il vaut mieux une version française limitée
que pas de version du tout.


Pas d'accord quand ça consiste juste à copier-coller directement le 
contenu d'une traduction automatique SANS la relire et la comprendre. 
N'improte qui fait ça directement avec son navigateur web et les 
outils divers (avec en plus la possibilité de choisir le robot 
traducteur, ce qu'on perd totalement ici).


Bref que ceux qui veulent traduire le fassent, mais il faut au minimum 
comprendre ce qu'on lit dans la langue source (l'anglais au minimum, 
parfois comparer à la cible des liens qui ne sont pas toujours en 
anglais et pour lesquels il n'y a pas toujours de traduction anglaise 
disponible non plus) ET comprendre ce qui est écrit en français (pour 
corriger les contre-sens complets).


C'est la même chose sur la traduction de tous les wikis (OSM ou 
Wikimedia) ou sur tous les projets de traduction (même s'ils incluent 
une mémoire de traduction et eux aussi proposent des robots 
traducteurs): l'utilisation automatique de robots (Google translate) 
pour insérer ces traductions automatique sans les relire est bannie. 
La relecture intelligente est une étape indispensable. Je ne vois pas 
pourquoi ce ne serait pas non plus le cas pour WeeklyOSM, que ces 
fausses traductions déservent plus le projet qu'elles ne le servent : 
quand un lecteur utilise *lui-même* un robot dans son navigateur il 
sait à quoi s'attendre et sait que la traduction automatique peut être 
erronée et à ne pas prendre au pied de la lettre.


Et c'est encore plus vrai pour WeeklyOSM quand la source originale 
n'est en fait même pas l'anglais (souvent l'allemand, l'espagnol ou le 
russe), et où la version anglais proposée comme source est en fait une 
traduction approchante qui peut déjà contenir des tas de fautes de 
sens ou de grammaire non corrigées (surtout celles venant en fait du 
russe et de l'espagnol dont les locuteurs maîtrisent souvent plus mal 
l'anglais que les germanophones...) ce qui "perd" encore plus les 
traducteurs automatiques partant de cette traduction anglaise 
approximative.


D'ailleur WeeklyOSM se base encore en proposant toujours l'anglais 
comme source, sans nécessairement montrer les autres langues 
originales (qui peuvent pourtant servir à lever des ambiguités, utiles 
quand un détecte des non-sens pour savoir ce quu voulait être 
rélelement dit et que les robots parviennent encore moins à "comprendre")


Un bon outil de traductions doit permettre de voir les autres langues 
et pas seulement la source proposée par défaut, et contenir un espace 
de discussion/questions pour interroger les auteurs sur les ambiguités 
ou difficultés de traduction ou compréhension de leur texte. On a ça 
dans le moteur de traduction de MediaWiki, mais rarement dans plein 
d'autres outils qu'on trouve sur le web, qui en plus ne disposent pas 
non plus de mémoire de traduction (qui aide à maintenir un lexique 
homogène, mais qui n'est pas infaillible non plus surtout s'il ne 
propose qu'une seule version et pas d'autres adaptées aux autres 
usages réels).


Les moteurs de traduction (pour produire et publier ces traductions, 
ou en ligne intégrés dans le navigateur du client) proposent divers 
outils, c'est dommage d'en priver les lecteurs en ne leur offrant plus 
qu'une version pseudo-traduite automatiquement et non relue, juste 
parce que quelqu'un a fait quelques clics rapides dans le moteur pour 
faire croire qu'il a produit très vite 100% d'une traduction. Quand on 
ne comprend pas ce qu'on lit, on ne traduit pas à la place des autres.



___
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] HebdoOSM

[osm . sanspourriel]

Bonjour,

Je croyais que Philippe répondait à mon message et j'étais choqué car il 
reprenait une partie en sortant du contexte. En fait non, je n'avais pas 
expédié mon message et on est presque d'accord, du moins sur la conclusion..


oui c'est imparfait mais ce n'est pas parce que c'est imparfait que ce 
n'est pas mieux que rien.


Je lis la version française depuis qu'elle passe sur cette liste (sinon 
je la regardais très épisodiquement).


Et je passe à la VO si elle est en allemand. En anglais aussi selon mon 
humeur.


Oui les traductions automatiques non revues par un humain sont 
"googlesques".
Peut-être vaut-il mieux se concentrer sur quelques points et bien les 
traduire.
Par contre si on offre qu'une traduction automatique et que c'est 
clairement indiqué, ça ne me choque pas. Philippe semble sous-entendre 
que certaines traductions automatiques sont à peines relues et marquées 
comme traductions humaines. Si la traduction n'est pas de qualité, il 
vaut mieux laisser "traduction automatique que de dévaloriser le travail 
des traducteurs.


Le fait qu'il faille s'inscrire sur OSMBC limite la possibilité d'aider 
: on ne va pas s'inscrire si on ne sait si on va pouvoir aider vraiment.

Les traductions pour Framasoft sont ouvertes :
https://suivi.framalang.org/trads.php?page=2
Transifex, translatewiki...

Jean-Yvon

Le 18/02/2017 à 15:47, Julien Coupey - jul...@coupey.fr a écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Ferrovie su mappa Wikipedia

[Lorenzo Mastrogiacomi]

Il giorno sab, 18/02/2017 alle 20.40 +0100, girarsi_liste ha scritto:


> 
> Sembra che qualcuno abbia messo mano alle coordinate oggi:
> 
> https://it.wikipedia.org/w/index.php?title=Ferrovia_Fano-Urbino=86014952=86012117
> 
> Probabile che i rimpristini abbiano in qualche modo modificato le
> coordinate o annullato qualche cosa legate a loro.
> 

Ho fatto io la modifica. Serviva solo a dare alla mappa uno zoom
adeguato anche se la traccia non era mostrata. E' stata annullata da
altro utente comunque.
Ma il problema non è solo su questo caso specifico. Prova a cliccare sui
link WIWOSM, vedrai che molti non trovano l'oggetto:
http://geodati.fmach.it/gfoss_geodata/osm/wtosm/

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

Re: [Talk-it] mappatura armadi telefonici

[Volker Schmidt]

per favore non mappateli, sono troppi. Qui a Padova ci sono ad ogni
incrocia circa 5 armadi di operatori diversi, tutti collegati allo stesso
cavo multifibra sotterraneo. E fra poco arriva anche ENEL per posare nuovi
cavi multifibra e probabilmente anche nuovi armadi.

On 18 February 2017 at 19:04, Andrea Solari  wrote:

> Ciao
> qualcuno ha iniziato a mappare gli armadi telefonici Tim/Telecom per la
> fibra ottica?
>
> esempi
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet#Street_
> cabinet_categories
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop
>
> saluti
> andrea
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] HebdoOSM

[Philippe Verdy]

Le 18 février 2017 à 15:47, Julien Coupey  a écrit :

> Comme ça a été dit, il vaut mieux une version française limitée que pas de
> version du tout.
>

Pas d'accord quand ça consiste juste à copier-coller directement le contenu
d'une traduction automatique SANS la relire et la comprendre. N'improte qui
fait ça directement avec son navigateur web et les outils divers (avec en
plus la possibilité de choisir le robot traducteur, ce qu'on perd
totalement ici).

Bref que ceux qui veulent traduire le fassent, mais il faut au minimum
comprendre ce qu'on lit dans la langue source (l'anglais au minimum,
parfois comparer à la cible des liens qui ne sont pas toujours en anglais
et pour lesquels il n'y a pas toujours de traduction anglaise disponible
non plus) ET comprendre ce qui est écrit en français (pour corriger les
contre-sens complets).

C'est la même chose sur la traduction de tous les wikis (OSM ou Wikimedia)
ou sur tous les projets de traduction (même s'ils incluent une mémoire de
traduction et eux aussi proposent des robots traducteurs): l'utilisation
automatique de robots (Google translate) pour insérer ces traductions
automatique sans les relire est bannie. La relecture intelligente est une
étape indispensable. Je ne vois pas pourquoi ce ne serait pas non plus le
cas pour WeeklyOSM, que ces fausses traductions déservent plus le projet
qu'elles ne le servent : quand un lecteur utilise *lui-même* un robot dans
son navigateur il sait à quoi s'attendre et sait que la traduction
automatique peut être erronée et à ne pas prendre au pied de la lettre.

Et c'est encore plus vrai pour WeeklyOSM quand la source originale n'est en
fait même pas l'anglais (souvent l'allemand, l'espagnol ou le russe), et où
la version anglais proposée comme source est en fait une traduction
approchante qui peut déjà contenir des tas de fautes de sens ou de
grammaire non corrigées (surtout celles venant en fait du russe et de
l'espagnol dont les locuteurs maîtrisent souvent plus mal l'anglais que les
germanophones...) ce qui "perd" encore plus les traducteurs automatiques
partant de cette traduction anglaise approximative.

D'ailleur WeeklyOSM se base encore en proposant toujours l'anglais comme
source, sans nécessairement montrer les autres langues originales (qui
peuvent pourtant servir à lever des ambiguités, utiles quand un détecte des
non-sens pour savoir ce quu voulait être rélelement dit et que les robots
parviennent encore moins à "comprendre")

Un bon outil de traductions doit permettre de voir les autres langues et
pas seulement la source proposée par défaut, et contenir un espace de
discussion/questions pour interroger les auteurs sur les ambiguités ou
difficultés de traduction ou compréhension de leur texte. On a ça dans le
moteur de traduction de MediaWiki, mais rarement dans plein d'autres outils
qu'on trouve sur le web, qui en plus ne disposent pas non plus de mémoire
de traduction (qui aide à maintenir un lexique homogène, mais qui n'est pas
infaillible non plus surtout s'il ne propose qu'une seule version et pas
d'autres adaptées aux autres usages réels).

Les moteurs de traduction (pour produire et publier ces traductions, ou en
ligne intégrés dans le navigateur du client) proposent divers outils, c'est
dommage d'en priver les lecteurs en ne leur offrant plus qu'une version
pseudo-traduite automatiquement et non relue, juste parce que quelqu'un a
fait quelques clics rapides dans le moteur pour faire croire qu'il a
produit très vite 100% d'une traduction. Quand on ne comprend pas ce qu'on
lit, on ne traduit pas à la place des autres.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Ferrovie su mappa Wikipedia

[girarsi_liste]

Il 18/02/2017 18:08, Lorenzo Mastrogiacomi ha scritto:
> Mi segnalano che sulla mappa Wikipedia i tracciati delle ferrovie
> venivano mostrati fino a qualche giorno fa ma ora non più. Esempio:
> https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=it=Ferrovia_Fano-Urbino
> Nel menù in alto a destra dice "OSM objects (not found)". Ho visto che
> fa così anche per altri oggetti. I fiumi funzionano.
> Ne sapete qualcosa?
> 
> Lorenzo
> 

Sembra che qualcuno abbia messo mano alle coordinate oggi:

https://it.wikipedia.org/w/index.php?title=Ferrovia_Fano-Urbino=86014952=86012117

Probabile che i rimpristini abbiano in qualche modo modificato le
coordinate o annullato qualche cosa legate a loro.




-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

[Talk-it] mappatura armadi telefonici

[Andrea Solari]

Ciao
qualcuno ha iniziato a mappare gli armadi telefonici Tim/Telecom per la
fibra ottica?

esempi
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet#Street_cabinet_categories

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

saluti
andrea

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

Re: [Talk-GB] London, network=Barclays Cycle Hire

[Phillip Barnett]

+1 for simplifying name. Adding the name of 'sponsor of the week' adds nothing 
to the utility of the map, and just means extra work for no benefit. We are 
under no obligation to promote the sponsor.


> On 18 Feb 2017, at 12:43, Philip Barnes  wrote:
> 
> I see no problem with this edit, however should we keep changing the
> name of the sponsor, or should we be even more bold and simply call it
> London Cycle Hire, or similar, in the same way the BBC refer to the FA
> Cup rather than the name of the sponsor it happens to have this year?
> 
> My 2 pence worth.
> 
> Phil (trigpoint)
> 
> 
> 
>> On Sat, 2017-02-18 at 12:31 +, Dan S wrote:
>> Hi all,
>> 
>> Exactly 1 year ago, Harry pointed out that most of London's bike hire
>> scheme was still tagged as "Barclays Cycle Hire" even though it's not
>> called that any more.
>> > London_Cycle_Hire#Santander_Cycles>
>> 
>> He said: "I think this is a case where (PROPOSAL) we Londoners should
>> be bold and swap them all over as a single edit."
>> 
>> I concurred back then, and I still do. I invite opinions as to the
>> best value to put in the network=* tag (see the discussion on the
>> wiki, for some suggestions). I've pasted at the end of this email,
>> the
>> current counts of values used.
>> 
>> I'd like to propose carrying out that edit, i.e. a simple edit to the
>> network=* values listed below, for amenity=bicycle_rental. (Note that
>> we'd avoid editing other network=* values such as "Brompton Dock",
>> different scheme.)
>> 
>> Best
>> Dan
>> 
>> 
>> 
>> 422 "network": "Barclays Cycle Hire"
>>   1 "network": "Barclays Cycle Hire Scheme"
>>   1 "network": "Barkleys Cycle Hire"
>>   1 "network": "Santander"
>>  20 "network": "Santander Cycle Hire"
>>  42 "network": "Santander Cycles"
>>   1 "network": "TfL"
>>   1 "network": "TFL"
>>   3 "network": "TfL Cycle Hire"
>>   1 "network": "TFL Cycle Hire"
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

[Talk-cz] body zachrany

[Jáchym Čepický]

Ahoj,

máme v databázi nějak evidované tzv. body záchrany - rescue points ?

http://www.hzscr.cz/clanek/body-zachrany-na-uzemi-cr.aspx

Na mapy.cz jsou

J
--
Jachym Cepicky
e-mail: jachym.cepi...@gmail.com
twitter: @jachymc

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

[Talk-it] Ferrovie su mappa Wikipedia

[Lorenzo Mastrogiacomi]

Mi segnalano che sulla mappa Wikipedia i tracciati delle ferrovie
venivano mostrati fino a qualche giorno fa ma ora non più. Esempio:
https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=it=Ferrovia_Fano-Urbino
Nel menù in alto a destra dice "OSM objects (not found)". Ho visto che
fa così anche per altri oggetti. I fiumi funzionano.
Ne sapete qualcosa?

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

Re: [Talk-it] Divieto escrementi animali.

[girarsi_liste]

Il 14/02/2017 18:15, Paolo Monegato ha scritto:
> Visto che c'è il contenitore però più che un divieto alle povere
> bestiole (che tra l'altro avrebbe poco senso) si tratta di un segnale
> che obbliga il padrone a raccogliere... Quindi imho il valore più che
> "no" dovrebbe essere un altro che indichi appunto questo obbligo di
> raccolta.

Scusa se rispondo solo adesso, ma oggi mi è venuta in mente la tua mail,
dopo averla cestinata fra l'altro.però col tuo ragionamento sono
d'accordissimo, il problema è che poi non saprei come tradurre con tag o
più tag il tutto, almeno evitando una parola lunga come valore.

QUindi obbligo di raccolta ?

una relazione restrictions? quale?

Dico la verità, non mi ci raccapezzo in questo caso.




-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [OSM-talk] Fixing broken multipolygons

[Tomas Straupis]

2017-02-18 16:26 GMT+02:00 Dave F wrote:
> Why do you believe this to be a problem? It may be pointless, but not an
> error.

  As I pointed out there is no problem with geometry. So yes, it is
not an error.
  But import(?) with lots of errors in ETL or source data.

-- 
Tomas

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

Re: [OSM-talk-be] Notes pollutie

[Marc Gemis]

2017-02-18 15:33 GMT+01:00 Philippe Casteleyn :

> Ik heb toch al geschreven dat ik stop in Brussel omdat ik er niet
> gemakkelijk meer kan werken


bedoel je nu dat die notes het moeilijk maken om te werken ? Je kan die
notes toch heel gemakkelijk afzetten met een eenvoudige klik ? Bij mij
staan die bijna altijd af.

Zijn er andere zaken die het mappen moeilijk maken ? Misschien zijn er
eenvoudige tips die het leven makkelijker kunnen maken in een druk gemapped
gebied. Ik denk daarbij bv. filters in JOSM.

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

Re: [OSM-talk-be] Notes pollutie

[Matthijs Melissen]

2017-02-18 15:33 GMT+01:00 Philippe Casteleyn :
> Iedereen spreekt altijd over lokale kennis, maar verkiest toch
buitenlandse
> inmenging.

Een kleine opheldering, met 'lokale kennis' wordt bedoeld kennis van iemand
die ter plaatse is geweest om te kijken hoe de situatie er aldaar uit ziet
(in tegenstelling tot bijvoorbeeld imports of intekenen van Bing-beelden).
De woonplaats van de mapper staat hier geheel los van.

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

Re: [OSM-talk-fr] HebdoOSM

[Julien Coupey]

Bonjour

Merci pour vos retours et avis, et merci à ceux qui se sont proposés 
pour donner un coup de main !


Je tente une rapide synthèse :

* la remontée d'infos francophones est cruciale (aspect objectivement 
sous-estimé pour l'instant par rapport à la traduction pure). Il faut 
essayer de mettre l'accent là-dessus, et voir par la suite comment 
mutualiser davantage les choses.


* la version française a une utilité en soit malgré ses imperfections 
(même si on ne peut pas facilement évaluer son audience), et le côté « 
on fait ce qu'on peut » est bien compréhensible pendant le rodage de la 
formule.


Faire une version mensuelle serait sûrement moins lourd mais poserait 
d'autres problèmes techniques vis-à-vis de l'outil existant. Je pense 
qu'il faut dans un premier temps être simplement plus modestes dans les 
objectifs (nombre d'articles dépendant des ressources dispos plutôt que 
chercher à tout traduire). Comme ça a été dit, il vaut mieux une version 
française limitée que pas de version du tout.


Encore une fois, tous ceux qui veulent participer (même peu, même à un 
seul type de tâche), sont les bienvenus ! N'hésitez pas à vous manifester !


À +
Julien

Le 16/02/2017 à 18:24, Manfred A. Reiter a écrit :

Bonjour Julien,

Excusez mon mauvais français, mais je manque de la pratique.
- et non, celui ci n'est pas une traduction automatique ;-)

Note préliminaire:
Contrairement à ce que Philippe Verdy a dit
 hebdo/weeekly/seamanario...OSM n'a rien à voir avec une hégémonie
germanophone! Oui, l'idée fut crée en Allemange, mais cést tout! Ainsi,
le construit par Ph. V. d'un problème linguistique n'existe pas, quand
vous parler un peux de l'anglais.

La communication entre les membres des équipes entre eux est l'anglais.
Bien sûr, les membres de chaque équipe communiquent dans leur propre
langue! ;-)

Pour la production de l'hebdomadaire:
OSMBC [1]est un outil dans lequel de recueillir tous les membres de
l'équipe au cours d'un message de la semaine.

Quand quelqu'un écrit un message dans sa propre langue, il est
souhaitable qu'il écrit ce message en anglais afin qu'ils puissent être
traduits par les autres équipes dans leur langue maternelle. Pour les
liens nous utilison Markdown.

Il est ainsi simple.

Je vous invite à continuer notre conversation dans Slack avec moi et les
autres membres de l'équipe. Vous verrez, pas de personne ne parle un mot
en allemand. ;-)

semanalOSM se comprise comme OSM comme une équipe international.

Donc, - pas de soucis


[1] https://github.com/TheFive/osmbc


2017-02-16 17:29 GMT+01:00 Julien Lepiller >:

Le 2017-02-16 16:27, Jérôme Amagat a écrit :

Bonjour,

Pour moi, comme David Crochet, en anglais ou dans une autre
langue que
le français, je ne le lirais pas, alors que je le lis depuis qu'il
est envoyé sur cette liste.
Et si un sujet m’intéresse mais que le lien est en anglais alors je
fais un effort (ou je regarde les images si c'est autre chose que du
français ou de l'anglais :) )


Hello,

je ne comprends pas du tout comment fonctionne la traduction, qui
traduit et comment, mais si on m'explique quels sont les outils
utilisés et qui contacter, je suis partant pour faire de la
relecture et aider à améliorer la traduction.


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





--
## Manfred Reiter - -
## N49° 25' 11.028" E6° 50' 47.328"
## www.weeklyOSM.eu 


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



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

[OSM-talk-be] Notes pollutie

[Philippe Casteleyn]

Het is toch niet zo erg iemand "dictator" te noemen ?  Ik heb mij nog 
ingehouden []   Wees blij dat er nog mensen zijn die paard en kar durven 
noemen.  Wat is dat tegenwoordig toch met al dat verplicht positivisme !


Ik heb toch al geschreven dat ik stop in Brussel omdat ik er niet gemakkelijk 
meer kan werken.  Eigenlijk wel jammer.  Ik denk dat ik de winkels in centrum 
Brussel nog zou bijgehouden hebben.


Iedereen spreekt altijd over lokale kennis, maar verkiest toch buitenlandse 
inmenging.  Als ik niet map zoals jullie willen, geef mij er dan ook maar van 
langs.



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

Re: [OSM-talk] Fixing broken multipolygons

[Dave F]

Hi

Why do you believe this to be a problem? It may be pointless, but not an 
error.


I need to point out none of these given examples are multi-polygons.

DaveF

On 18/02/2017 11:37, Tomas Straupis wrote:

   Another interesting example are polygons like this:
   http://www.openstreetmap.org/way/400182030

   Polygon geometry is fine here, but it has one pointless node close
to one of the nodes. Pointless because it does not influence the final
geometry of the polygon.
   And if you look around there are a lot of such buildings with
pointless nodes. I would say almost every building has them...




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [OSM-talk] Fixing broken multipolygons

[Maarten Deen]

On 2017-02-18 12:37, Tomas Straupis wrote:

Another interesting example are polygons like this:
  http://www.openstreetmap.org/way/400182030

  Polygon geometry is fine here, but it has one pointless node close
to one of the nodes. Pointless because it does not influence the final
geometry of the polygon.
  And if you look around there are a lot of such buildings with
pointless nodes. I would say almost every building has them...


I suppose they have the same origin as the nodes outside the main 
building causing the intersecting buildings that we fix in this 
maproulette: a click to many and there is another node.


Maarten

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

Re: [OSM-talk-fr] Réparer un carnage

[osm . sanspourriel]

https://wiki.openstreetmap.org/wiki/FR:Madagascar_tagging_guidelines#R.C3.A9seau_routier

Pour expliquer aux contributeurs comment taguer les routes à Madagascar.

Jean-Yvon

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

Re: [Talk-GB] London, network=Barclays Cycle Hire

[Philip Barnes]

I see no problem with this edit, however should we keep changing the
name of the sponsor, or should we be even more bold and simply call it
London Cycle Hire, or similar, in the same way the BBC refer to the FA
Cup rather than the name of the sponsor it happens to have this year?

My 2 pence worth.

Phil (trigpoint)



On Sat, 2017-02-18 at 12:31 +, Dan S wrote:
> Hi all,
> 
> Exactly 1 year ago, Harry pointed out that most of London's bike hire
> scheme was still tagged as "Barclays Cycle Hire" even though it's not
> called that any more.
>  London_Cycle_Hire#Santander_Cycles>
> 
> He said: "I think this is a case where (PROPOSAL) we Londoners should
> be bold and swap them all over as a single edit."
> 
> I concurred back then, and I still do. I invite opinions as to the
> best value to put in the network=* tag (see the discussion on the
> wiki, for some suggestions). I've pasted at the end of this email,
> the
> current counts of values used.
> 
> I'd like to propose carrying out that edit, i.e. a simple edit to the
> network=* values listed below, for amenity=bicycle_rental. (Note that
> we'd avoid editing other network=* values such as "Brompton Dock",
> different scheme.)
> 
> Best
> Dan
> 
> 
> 
> 422 "network": "Barclays Cycle Hire"
>   1 "network": "Barclays Cycle Hire Scheme"
>   1 "network": "Barkleys Cycle Hire"
>   1 "network": "Santander"
>  20 "network": "Santander Cycle Hire"
>  42 "network": "Santander Cycles"
>   1 "network": "TfL"
>   1 "network": "TFL"
>   3 "network": "TfL Cycle Hire"
>   1 "network": "TFL Cycle Hire"
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-it] MAPPA IMMAGINE DI SFONDO

[THESTORM375]

No ma lo sapevo già che gli URL di Google sono sbagliati  e non ho mai
avuto intenzione di usarli ... vedremo cosa potrò fare .. grazie a tutti ☺

Il Ven 17 Feb 2017 15:23 Martin Koppenhoefer  ha
scritto:

>
> 2017-02-16 23:19 GMT+01:00 Francesco Pelullo :
>
> 2. Usa fonti per le quali abbiamo licenza compatibile o autorizzazione (no
> GOOGLE MAPS, GOOGLE STREET VIEW, SFONDI o tracce prese "non dico come, non
> dico dove")
>
>
>
> giusto, le url di Google non funzionano in iD e in JOSM, appositamente,
> per evitare problemi.
>
> Ciao,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
-- 

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

[Talk-GB] London, network=Barclays Cycle Hire

[Dan S]

Hi all,

Exactly 1 year ago, Harry pointed out that most of London's bike hire
scheme was still tagged as "Barclays Cycle Hire" even though it's not
called that any more.


He said: "I think this is a case where (PROPOSAL) we Londoners should
be bold and swap them all over as a single edit."

I concurred back then, and I still do. I invite opinions as to the
best value to put in the network=* tag (see the discussion on the
wiki, for some suggestions). I've pasted at the end of this email, the
current counts of values used.

I'd like to propose carrying out that edit, i.e. a simple edit to the
network=* values listed below, for amenity=bicycle_rental. (Note that
we'd avoid editing other network=* values such as "Brompton Dock",
different scheme.)

Best
Dan



422 "network": "Barclays Cycle Hire"
  1 "network": "Barclays Cycle Hire Scheme"
  1 "network": "Barkleys Cycle Hire"
  1 "network": "Santander"
 20 "network": "Santander Cycle Hire"
 42 "network": "Santander Cycles"
  1 "network": "TfL"
  1 "network": "TFL"
  3 "network": "TfL Cycle Hire"
  1 "network": "TFL Cycle Hire"

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

Re: [OSM-talk-nl] blog.openstreetmap.nl

[Hugo Hölscher]

Is de blog soms slachtoffer van het recent ontdekte lek in PHPMailer?

Er is overigens een patch on het lek te dichten.

Groet Hugo


Op 18 feb. 2017 12:24 schreef "Stefan de Konink" :

> Ps maar als er een vrijwilliger komt die het in de lucht wil gaan houden,
>> ga uwes ganges en draag het over.
>>
>
> Ik heb nog wat liefde gegeven aan de wordpress installatie. Hij is nog
> niet weg.
>
> --
> Stefan
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk] Fixing broken multipolygons

[Tomas Straupis]

  Another interesting example are polygons like this:
  http://www.openstreetmap.org/way/400182030

  Polygon geometry is fine here, but it has one pointless node close
to one of the nodes. Pointless because it does not influence the final
geometry of the polygon.
  And if you look around there are a lot of such buildings with
pointless nodes. I would say almost every building has them...

-- 
Tomas

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

Re: [OSM-talk] Maproulette problems?

[Maarten Deen]

On 2017-02-18 12:18, Jochen Topf wrote:

On Sat, Feb 18, 2017 at 09:48:08AM +0100, Maarten Deen wrote:
Is the back-end of Maproulette offline? I can access the site, I can 
see the
challenges and the metrics, but when I want to start a challenge I 
only get

to see the OSM map in my neighborhood and it doesn't assign a task.


It does work for me currently. But the effect you describe is what you
see when a challenge is finished. Try a different challenge.


I did. But it now works again for me too.

Maarten

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

Re: [OSM-talk-be] Notes pollutie in Brussel

[Karel Adams]

Helemaal gelijk Glenn, ik zat ook al te broeden op een antwoord in die 
zin maar ik zou het niet beter kunnen verwoorden.


Karel


On 17/02/17 11:52, Glenn Plas wrote:

Mr Casteleyn,

Dit is de 2de maal dat u iemand persoonlijk aanvalt, en 2 maal dezelfde
persoon over een paar notes die u niet aanstaan.

U overdrijft gewoon.  Ik heb met de mantel der liefde al mensen
aangepakt die brokken data vernielden van mijn hand uit onwetendheid,
iedereen in OSM doet dubbel werk van tijd, live with it.  It's part of
the game.

Als de notes u werkelijk niet aanstaan, kijk er dan niet naar!  Dit is
een community, geen concurentie.  geen enkele 'dictator' verplicht u
toch om er rekening mee te houden ?

Ik vind dat Math nog heel proper reageerde op uw voorlaatste klaagzang,
ik stel voor om dezelfde diplomatische houding aan te nemen, uw
aanvallen storen mij meer dan de notes waar ik niet naar kijk.  Steek uw
energie in het editten van de kaart ipv in dit soort thrash mails te
schrijven.

Er is geen deadline voor editeren van OSM, het is een constante golf van
veranderingen en aanpassingen aan de realiteit, we zullen de factor
altijd achterlopen op de werkelijkheid.

Don't fix the blame, fix the problem.

Glenn




On 16-02-17 09:38, Philippe Casteleyn wrote:

http://www.openstreetmap.org/user/philippec

Het is beleefd op het OSM profiel te zeggen wat u waar doet.


Ik heb er altijd een punt van eer van gemaakt de foto's voor
fatsoenlijke notes de dag zelf te publiceren.  De laastste 5 maand zit
ik naar de 50 notes van Math te staren en ik zie meer beweging in de
winkels dan in de notes.  Bovendien zijn zijn notes geen notes.  Zelfs
een Brusselaar kan op de OSM kaart zien welke panden en
winkelgaanderijen niet getagd zijn.  Er is geen verdienste aan.   Het is
gewoon hondjesgedrag.


Ik ben niet van plan elke dag te kijken of er een éénenvijftigste
fatsoenlijke note tussen zit.  Ik ben ook niet van plan naar de pijpen
van een buitenlandse dictator te dansen.  Zijn er al precendenten ?  Hoe
reageren andere beschavingen op zulke D.O.S. bombardementen ?  Ik heb
ook niet de indruk dat de locals 100 procent achter mij staan.  De notes
staan er nog.  Ik zal dan ook stoppen met de winkelgaanderijen te
bolfotograferen.  Trop is te veel.



Ph Casteleyn
Dahliastraat 16
2800 Mechelen
animals.slippers.loaders
gsm 0486 516261
Ctrl+v


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



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



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

Re: [OSM-talk-nl] blog.openstreetmap.nl

[Stefan de Konink]

Ps maar als er een vrijwilliger komt die het in de lucht wil 
gaan houden, ga uwes ganges en draag het over.


Ik heb nog wat liefde gegeven aan de wordpress installatie. Hij is nog niet 
weg.


--
Stefan

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

Re: [OSM-talk] Fixing broken multipolygons

[Florian Lohoff]

On Sat, Feb 18, 2017 at 10:26:42AM +, Andy Townsend wrote:
> On 18/02/2017 10:15, Florian Lohoff wrote:
> >
> >After Europe was fixed in <24h it seems i started to wade through Africa
> >and i am seeing some error class which makes me wonder is somebody did
> >some large scale autonomous Aerial scan for buildings.
> >
> >There are literally hundrets of building which have 4 edges as nodes
> >but them beeing connected over cross so that a construct like a
> >butterfly resembles.
> 
> Any chance of a link to an example?

https://www.openstreetmap.org/way/448649947/history
https://www.openstreetmap.org/way/425323610/history
https://www.openstreetmap.org/way/425323608/history

I have definitly fixed more than 50 of these - i skipped the above
3 now - still they are in the maproulette challenge 

Users/Mappers are different ones - most carry HOT or MissingMap hashtags
still i wonder how people produce these ...

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


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

Re: [OSM-talk] Fixing broken multipolygons

[Jochen Topf]

On Sat, Feb 18, 2017 at 01:10:13PM +0200, Tomas Straupis wrote:
> >> There are literally hundrets of building which have 4 edges as nodes
> >> but them beeing connected over cross so that a construct like a
> >> butterfly resembles.
> >
> > Any chance of a link to an example?
> 
>   I guess Florian ment geometries like this:
>   http://www.openstreetmap.org/way/460032394
> 
>   There are indeed plenty of these in "less populated" areas,
> especially areas with round buildings...

Probably the result of some HOT mapping thing done by inexperiences
mappers...

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [OSM-talk] Maproulette problems?

[Jochen Topf]

On Sat, Feb 18, 2017 at 09:48:08AM +0100, Maarten Deen wrote:
> Is the back-end of Maproulette offline? I can access the site, I can see the
> challenges and the metrics, but when I want to start a challenge I only get
> to see the OSM map in my neighborhood and it doesn't assign a task.

It does work for me currently. But the effect you describe is what you
see when a challenge is finished. Try a different challenge.

> Also: there is no contact information? Is this the best way to get in
> contact with the makers?

You can open an issue on https://github.com/maproulette/maproulette2 .
I just opened an issue there to say that there is no contact info. :-)

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [OSM-talk] Fixing broken multipolygons

[Tomas Straupis]

>> There are literally hundrets of building which have 4 edges as nodes
>> but them beeing connected over cross so that a construct like a
>> butterfly resembles.
>
> Any chance of a link to an example?

  I guess Florian ment geometries like this:
  http://www.openstreetmap.org/way/460032394

  There are indeed plenty of these in "less populated" areas,
especially areas with round buildings...

-- 
Tomas

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

Re: [OSM-talk] Fixing broken multipolygons

[Andy Townsend]

On 18/02/2017 10:15, Florian Lohoff wrote:


After Europe was fixed in <24h it seems i started to wade through Africa
and i am seeing some error class which makes me wonder is somebody did
some large scale autonomous Aerial scan for buildings.

There are literally hundrets of building which have 4 edges as nodes
but them beeing connected over cross so that a construct like a
butterfly resembles.


Any chance of a link to an example?

Best Regards,

Andy


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

Re: [OSM-talk] Fixing broken multipolygons

[Florian Lohoff]

On Wed, Feb 15, 2017 at 04:20:53PM +0100, Jochen Topf wrote:
> Yesterday I launched several Maproulette challenges that allow you to
> easily help with the "cleaning up" effort. Read
> http://area.jochentopf.com/fixing.html for more details on those
> Maproulette challenges. This is a huge effort that will take a long time
> and we really need any help we get. The challenges posted today are only
> the beginning. They only show the about 6,500 ways worldwide tagged as
> buildings (with less than 100 nodes) where the way intersects itself.

After Europe was fixed in <24h it seems i started to wade through Africa
and i am seeing some error class which makes me wonder is somebody did
some large scale autonomous Aerial scan for buildings.

There are literally hundrets of building which have 4 edges as nodes
but them beeing connected over cross so that a construct like a
butterfly resembles.

I have never seen a human produce something like this.

One can easily spot human errors like using "extrude" and Josm leaving
the old edges in place, "duplicate" edges which make the polygon
self-intersect within 10cm etc ..

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


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

Re: [Talk-cz] (no subject)

[Marián Kyral]

Ahoj, už by to mělo fungovat.

A budu se muset podívat na tu vrstvu chybných rozcestníku. Taky to je nějaké  
rozbité :-(

Ale k tomu se dostanu asi až zítra večer.

Marian

18. února 2017 7:55:56 SEČ, "Marián Kyral"  napsal:
>Dne 18.2.2017 v 07:10 Zdeněk Pražák napsal(a):
>> zkusil jsem na adrese 
>> http://rawgit.com/osmcz/osmcz/improve-layer-switcher/#
>> přesunout rozcestník PA055
>> Přesouvání však nefunguje, po stisku tlačítka přesunout se nic neděje
>>
>
>Díky. Jsem to chtěl sjednotit, ale asi jsem to přehnal a rozbil to více
>
>než je zdrávo. Zkusím to nějak opravit.
>
>Marián
>
>
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz

-- 
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[OSM-talk] Maproulette problems?

[Maarten Deen]

Is the back-end of Maproulette offline? I can access the site, I can see 
the challenges and the metrics, but when I want to start a challenge I 
only get to see the OSM map in my neighborhood and it doesn't assign a 
task.


Also: there is no contact information? Is this the best way to get in 
contact with the makers?


Regards,
Maarten

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

Re: [OSM-talk] Fixing broken multipolygons

[Oleksiy Muzalyev]

On 18.02.17 08:43, Jochen Topf wrote:

On Sat, Feb 18, 2017 at 07:50:07AM +0100, Oleksiy Muzalyev wrote:

On 15.02.17 23:51, Sarah Hoffmann wrote:

... we are
currently discussing about changing the algorithm that assembles the
polygons[1]. The new algorithms will be a lot faster but that comes
at the price that it is less tolerant with invalid geometries. A lot
of bad geometries that are currently still drawn some way or another
will be simply dropped. I'm convinced that in the long run this
stricter handling will be good not only for data consumers but also
for mappers, who will see immediately when they made a mistake.
...


Hi,
It would be a good idea to generate automatically a message to an author or
authors of this geometry asking them to fix it, explaining shortly what an
error they committed, and informing them that it would be deleted, if they
do not fix it. And if there is no reaction after a tolerance period of say
one week, then drop it automatically.

Most multipolygons we are talking about here haven't been touched in
years. So this doesn't really apply. Most of this is about cleaning up
the backlog. If you look at the stats on http://area.jochentopf.com/stats/
you'll see that the number of (multi)polygons is growing constantly, but
the number of errors is not. This tells me that it is mostly a problem with
old data.

  We could inform authors when new problems are coming up, but I suspect
that this is very difficult. For one, there can be several people
involved and you don't know which fault is was. Then there is the
question of what to tell the user. If you send them an email "Your
multipolygon id 1234567 is broken", that is not very helpful for them.
We need at a minimum some guidance on how to fix things. But this
depends at least on the editor used, the language of the user, the type
of problem and the skill level of the user. Ugh.


Deleting objects from the map without a warning may cause suspicions and
misunderstanding. For example, there are areas mapped as
boundary=protected_area or landuse=nature_reserve , but local fishermen who
want to continue fishing in the area may not like it, or at least have
doubts about its shape. By deleting a Nature Reserve from the map the script
may inadvertently interfere into a balance situation.

This is why we are having this discussion. We do not want to remove
anything from the map lightly. We are doing this only after taking any
measure we can to fix those cases. In the long run the situation will
get better, because at the moment some of those "critical" polygons you
are talking about might not show up or show up wrong on the map because
of the errors they contain that the renderer is trying to fix and doing
so in the wrong way. We are doing all this to improve the accuracy of
the map!

Jochen


OK. Then I agree. Indeed sometimes it is easier to map from scratch than 
to clean up speaking figuratively the Augean Stables.


After all, there are Wiki pages and Youtube videos which explain how to 
create multipoligons correctly.


Oleksiy


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

Re: [OSM-talk-be] heiligenbeelden

[Jakka]

Deze info nog gevonden:
http://wiki.openstreetmap.org/wiki/Tag:historic%3Dwayside_shrine
http://wiki.openstreetmap.org/wiki/Tag:historic%3Dwayside_cross
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcross
http://wiki.openstreetmap.org/wiki/Tag:summit:cross%3Dyes


Op 17/02/2017 om 18:31 schreef Marc Gemis:

voor mij zijn die beelden sowieso

tourism=artwork
artwork_type=statue
name=Jesus Christus
subject:wikidata=Q302  (voor bv. Jesus)

k weet niet zeker of dit wel plekken zijn waar men heen gaat om te
bidden (het geloof te belijden) zoals je verwacht bij een
amenity=place_of_worship

m

2017-02-17 16:38 GMT+01:00 Guy Vanvuchelen :

Kan iemand me zeggen hoe ik best een heiligenbeeld langs de weg map. Het is
geen kapelletje, geen schrijn, maar toch iets in die aard. In mijn drang om
zoveel mogelijk kapelletjes, kruisen, enz te mappen omdat die op veel
toeristische kaarten voorkomen stoot ik op heiligenbeelden, soms op een
altaar, soms gewoon op een sokkel.

Ik heb al de gebruikelijke: amenity =  place_of _worship, denomination =
roman_catholic, religion = Christian gebruikt samen met tourism : artwork
maar is dat wel juist. In vele gevallen is het beeld immers geen kunst. We
kunnen ook place_of_worshop = shrine kunnen gebruiken. Als je in Google
afbeeldingen voor ‘shrine’ kiest zie je wel een heel andere selectie dan
voor het Nederlandse ‘schrijn’. In het Nederlands gaat het eerder over een
soort koffer terwijl de Engelse versie voor alle soorten heiligdom staat.

Voor het beroemde beeld in Rio de Janeiro staat gewoon ‘name’ ingevuld.



Guy Vanvuchelen




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



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





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