Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Andreas Lattmann]

>http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only

Appunto! Ed il name è "da qui a li". Lo ha stabilito il CAI il name, non 
possiamo stabilirlo noi!

Se il CAI decide di dare ad un sentiero il nome "tutti i mappatori OSM sono 
persone volenterose e lodevoli" dovremmo inserirlo nel name, non nel 
description. 

Posso capire che sarebbe più da description, ma se il CAI ha stabilito che 
quello è il nome, è quello e basta.

Fai finta che il CAI sia un comune che deve scegliere il nome delle vie. Una 
volta che il comune ha scelto il nome delle vie tu decidi se va nel description 
o nel name? 

Nel mio comune ci sono delle vie che potrebbero essere messe nel description. 
Cosa faccio, mi metto a discutere con il comune per far cambiare nome alla via?


Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Christian Quest]

Le 17 octobre 2017 à 19:22, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Sur la page **name=* en anglais, il est bien indiqué qu’il faut y mettre
> le « default name », donc, si le nom est déjà mis par défaut, il n’y a
> aucune raison logique de le doublonner, ou alors « *default* » compte
> pour du beurre.
>
> La  précision *:fr *ne peut alors concerner que ce qui ne serait pas là
> par défaut. C’est comme cela que ça marche dans la plupart des cas,où on se
> donne la peine de définir une valeur par défaut.
> Quelle raison y aurait-il de déroger à la régle du défaut ?
>

avoir name + name:fr permet:
1) de savoir que name=* est en français si les deux sont identiques
2) de permettre un rendu où l'on peut favoriser une langue...

En effet, si on a juste name, rien ne me permet de savoir que ce name est
en français et que je peux l'utiliser en priorité pour le rendu "FR"... ou
alors, je suis obligé de faire une requête géographique en plus pour savoir
que comme je suis dans un pays où la langue officielle est le français (et
donc encore un appel à d'autres infos comme une relation type-default),
j'ai de fortes chances que ce name soit en français...

Pour mémoire le rendu FR utilise (dans l'ordre):
- name:fr (c'est ce que je veux)
- intl_name (car potentiellement écrit avec alphabet roman)
- name (dernière pioche et de langue/alphabet inconnu)

Je comprends bien le risque de retrouver dans name des versions
multilingues pour de mauvaises raisons, mais à l'usage des données, avoir
les deux simplifie grandement les choses et les clarifiant !

Ceci représente très peu de données en plus dans la base, c'est marginal et
si on se pose ce genre de question il y a bien d'autres données moins
utiles qu'on pourrait du coup limiter.

Je suis donc partisan de doubler name et name:fr (et en plus ça permet de
détecter les name=* multilingues qui ne devraient pas l'être).

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

Re: [Talk-us] hydrology Alaska

[ANT Berezhnyi]

+10 to what AlaskaDave said

I myself want to be beautiful and accurate,
I make with accuracy 1 point on 1..2 meters, on the exact perimeter of the
lake (accuracy 30 ... 50 centimeters from the coastline)
then I am simplifying (because it requires
https://www.openstreetmap.org/user/bdistsoe
https://www.openstreetmap.org/changeset/52811016#map=14/60.8274/-164.9563)

Simplification creates such a crap, as you led me to an example

if I do not make it easier - I will be blocked again (((


--
2017-10-11 06:56:40 UTC bdiscoe Hi, I ran simplify with a 90cm threshold.
That is very conservative for a remote, wild area of mud and tundra. As for
accuracy, I ran the JOSM validator and fixed many of the issues you left,
with multipolygon ways intersecting each other, overlapping ways, and many
other problems. It is fixed now...
--

Define the trouble please what you want to have quality,
because the simplification script is a standard simplification of JOSM
(unchanged)

*The basis I use is:*
Bing:
bing[22]:http://www.bing.com/maps/

DigitalGlobe Premium:
tms[22]:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/digitalglobe.316c9a2e/{zoom}/{x}/{y}.png?access_token=pk.eyJ1IjoiZGlnaXRhbGdsb2JlIiwiYSI6ImNqM293YnJ5MTAwajIzMnF0bmV4dnV1MW4ifQ.psvzzOez33BOH8xmRiJZWg


DigitalGlobe Standard:  (if on DG-premium clouds)
tms[22]:https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/digitalglobe.0a8e44ba/{zoom}/{x}/{y}.png?access_token=pk.eyJ1IjoiZGlnaXRhbGdsb2JlIiwiYSI6ImNqM293Y3Y5ZjAwaWgycW55ZXFncHk0a3QifQ.6Kprj_J4oDmXqV97RricwA


*I look forward to the answer to what is the understanding of how exactly
it is necessary for the region of Alaska to carry out the mapping of
hydrology.*

*Until there is a final agreed answer,* I will put roads in the reserves,
and correct the inaccuracies of the coastline (editing existing lines)



thnx

-- 
++ =
++ ANT (Anton Berezhnyi)
++ =
++ E-mail   : velmyshanov...@gmail.com
++ Hangouts : velmyshanov...@gmail.com
++ Telegram : @velmyshanovnyi
++ Skype: velmyshanovnyi
++ Viber: +380939946993
++ Cell : +380939946993
++ https://plus.google.com/+ANTBerezhnyi
++ https://profiles.google.com/velmyshanovnyi

++ https://linkedin.com/in/velmyshanovnyi
++ https://facebook.com/velmyshanovnyi 
++ https://twitter.com/velmyshanovnyi 
++ =
++ жNtTя, яК і iTNernЕТ,
++ нAЖалb, ТЕж к0лИСь
++ KіH4аЄтьCя..
++ =
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

Lester, I agree with you that Wikidata should not contain an object for
everything that OSM may have.  I don't believe there should be an entry for
every McDonalds on the planet, or for every artist's work that someone may
decide to include in OSM.  But that's up to Wikidata contributors.  Lets
instead talk about practical usages of our data.

Here is a wonderful site I saw at a conference a few days ago.  It lets you
plan your trip based on the places you are interested in.  You can
visualise all sorts of places - cultural, religious, hotels, bars -
anything, and plot your course.  And it uses Wikidata, images from Commons,
and Wikipedia text itself to describe the places.  The authors spoke at
length how Wikidata tags in OSM has helped them build it, and the
difficulty they had in all sorts of "data voodoo" to figure things out.
For example, they often correlate OSM & Wikidata locations by proximity,
and try to guess if it's a match. They have done an outstanding job making
sense of our data, but I think we could have made their job a lot easier
with our communal data curation capabilities, and also help others who may
have similar needs.

https://opentripmap.com/en/#14/40.7355/-73.9806

You do raise an important point about 1:1 vs part of vs ...  In order to be
useful in data processing by 3rd party, data needs to answer a simple
questions:  does the linked Wikidata/Wikipedia represents this whole
object, or is it simply related to it in some way.  Here, the 1:1 is meant
somewhat loosely - there are some cases when things don't align perfectly,
but that's a separate topic.

If wiki* page is about that object, the consumer may choose to use
multilingual names, show a portion of Wikipedia articles in the user's
language, use Wikidata statements, and show images from Commons.

If wiki* is only *related* somehow to the object, no such automatic usage
is possible. The link is still very valuable for the editors of the map,
but not as much to the data consumers.  Examples include a wiki article
that has just a section about this work of art, or wiki page is a list that
includes all churches in the area, or describe a class of these objects
(e.g. brand) but not this object itself.  Moreover, I suspect our favorite
tools like Nominatim would also be mislead if they rely on Wiki* links that
relate to the object, but not about the object itself. After all, if the
object is well known, it would probably have its own wiki page, or at least
a wikidata entry.

Some translations are completely different articles?

I'm not sure what you meant here. I have heard of rare cases when unrelated
wikipedia articles are connected to each other, but usually those get fixed
as soon as someone notices.


> The problem I still see is that many of the items I am looking to link to
> are elements of an article rather than the whole article, such as the
> location of the works of a particular artist. At some point in the
> future wikidata may well have a complete index of QID's for every
> artist's work, but currently I don't have the time to add wikidata
> entries where they don't exist, so a link to the artists wikipedia
> article which may or may not actually list this particular work is
> second best and in many cases there is not even an english version :(
>

Sure, lets just add it as a different tag, not wikipedia/wikidata. We could
call it related:wikidata or related:wikipedia:en, or subdivide it even
further. Note that here, unlike the main wikipedia tag, the
related:wikipedia:en might not be the same as wikidata. Moreover, I would
argue that here we should use related:wikipedia:xx format with the language
code, because the article content is likely to differ between languages.


> Some bot then modifying that link out of context is not helpful and
> while the idea of 'nobot' flags may seem a solution, it's just adding
> another layer of complexity which potentially needs to exist for EVERY
> tag on EVERY object. Something I don't think should be allowed!
>

Agree - I think a bot injecting wikipedia/wikidata tags based on some
heuristics, e.g. "has the same object class and is nearby" is not very good
and error prone. This could be a human-curated process, e.g. ask the user
to help deciding which  Wikipedia articles does this object represent, and
offer some likely candidates, but it shouldn't be automatic.  I think
Mapbox was working on something like that?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] GRB Flanders

[Marc Gemis]

Hallo Pieter,

welkom op de mailing list.

Momenteel werkt Glenn Plas aan een tool (website), om het tekenen van
huizen met adres informatie te vereenvoudigen. De tool is grotendeels
klaar, maar omdat het hier gaat om het importeren van data uit een
andere databank, moet er een goedkeuring van de gevolgde methode komen
van de internationale community.

Glenn gaat proberen deze goedkeuring te krijgen in de loop van de
volgende maanden. Als je graag documentatie schrijft, kan je hem
hierbij helpen. Hij is iets actiever op het Riot channel, dus je kan
hem daar ook contacteren. Als je in de geschiedenis van het channel
kan scrollen, zal je zien dat deze topic daar enkele dagen geleden ook
aan bod kwam.

mvg

m

2017-10-17 21:08 GMT+02:00 Pieter Vander Vennet :
> Hallo allemaal,
>
> Waar kan ik wat meer informatie vinden over de AGIV GRB 'Flanders' kaarten?
> En hoe teken ik die het beste?
>
> De voorbije weken heb ik serieus wat huisjes getraced, maar dat moet toch
> efficiënter kunnen...
>
> Ik las ergens iets over plugins in JOSM... Is er een tutorial voor? (Of als
> iemand mij dat in een paar woorden kan uitleggen, wil ik die ook wel
> schrijven).
>
> Ik vond deze wiki-pagina maar die is erg verouderd (slechts één link die nog
> werkt).
>
> Met vriendelijke groeten,
> Pieter Vander Vennet
>
> ___
> 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: [Talk-ca] COMS2200 Ottawa, Carleton University

[Tracey P. Lauriault]

Greetings OSM Ottawa and Data Working Group;

It looks like all of the COMS2200A photos have been deleted from OSM
Ottawa.  Is that true? When I look at the map, it does look rather
unpopulated with photos.
Can you please confirm?

Sincerely
Tracey


On Tue, Oct 17, 2017 at 12:46 PM, Tracey P. Lauriault 
wrote:

> Greetings OSM folks;
>
> I wonder if you could assist.
>
> Students are still getting locked out and are unable to complete their
> assignment. Also, the message they are receiving see below states that you
> were unable to locate me, which we know is not the case.
>
> It would be really great if we let the students finish their assignment
> and that we discuss what to do with the messy data as discussed in earlier
> parts of this stream.
>
> Any assistance would be most appreciated.
> Sincerely
> Tracey
>
> "Dear COMS2200A students,
>
> welcome to OSM and we're happy to see you engaging with our shared
> database.
>
> A few of our community members have taken exception to some of the things
> that you mapped and how you mapped them; many of your edits are not exactly
> following the quality standards we have set for us in OSM which leads us to
> believe that you may not have received the requisite training, especially
> where you've made edits outside of the university district.
>
> Sadly we couldn't find out who the person responsible for this
> class/course/ activity is. A few mappers have commented on edits that you
> made, and pointed out errors or problems; this should have triggered
> e-mails to the address used when registering but the messages seem to have
> been ignored.
>
> Could you please inform your teacher/course leader to get in touch with
> the Canadian community on the talk-ca mailing list (
> lists.openstreetmap.org/listinfo/talk-ca) so that we can discuss how to
> continue this exercise without degrading OSM's data quality?
>
> Please pause your editing activity until the matter is cleared up.
> Thank you Frederik Ramm OSMF Data Working Group
>
> On Wed, Oct 11, 2017 at 9:11 AM, Tracey P. Lauriault 
> wrote:
>
>> Thank you.
>> Lets finish this assignment and then regroup to discuss whether or not
>> this should be done again next year, and if so the best way to do it.
>>
>> The students will need to put together a small reflection piece on the
>> process, that should help.  We will have identified numerous issues and
>> error types, and we will have learned something about students and the OSM
>> community.
>>
>> I am travelling quite a bit this month, if I am here I will attend the
>> next local.  Please let me know when and where they are.
>>
>> Cheerio
>> Tracey
>>
>> On Wed, Oct 11, 2017 at 8:30 AM, James  wrote:
>>
>>> I think some people are missing the point of the class by saying: Go map
>>> an african village.
>>>
>>> The point was to have students go outside and take photos of real world
>>> items(surveying) and upload them to mapillary
>>> Then the students take the mapillary photo key and add it to the item in
>>> OSM
>>> They are supposed to learn about deriving information from
>>> something(photo, text,etc)
>>>
>>> As I've said to Tracey, I welcome the project, maybe we will get some
>>> new mappers out of it, but they are new mappers(we all started out new at
>>> one point and we've made errors in the past) and if they can learn from the
>>> feedback; all the better.
>>>
>>> On Wed, Oct 11, 2017 at 8:22 AM, john whelan 
>>> wrote:
>>>
 This is primarily to Tracey ca-talk has been cced.

 There are a number of issues here.

 First OSM is growing up.  No longer is it a bunch of mappers who use
 the edit tools or web page to view the map.  The data is live and snapshots
 are taken by various players including OSMAND at points in time.  This can
 be once a month so if there are a small number of mistakes not a big deal.
 If there are a large number in the snapshot then OSMAND users are stuck
 with them until the next off line map is made available.  Because of
 bandwidth costs both to the end user and to OSMAND it can be two or three
 months before the errors are cleared.

 Second the email over Frederick's signature is extremely polite for
 Frederick.  He wrote the book on OSM and is part of the group currently
 looking at whether we need a formal policy for handling edits by groups of
 organised mappers.  The DWG working group is the highest central authority
 within OSM and is concerned with data quality or vandalism.  I think the
 Carlton students edits show there is a very definite need.  A number of
 mappers including myself were hoping there wouldn't be a need for something
 quite so formal.  Note to Frederick if you read this change my response to
 the survey.

 Third OpenStreetMap is very rich in what can be mapped.  In an urban
 area it can be very complex to map.  For 

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[Tracey P. Lauriault]

Many students have said that their OSM points were deleted. Is there a way
to hold off until this assignment is over? As noted in previous emails, I
was hoping we could keep these entries until the end of the assignment so
that we may assess them.

This is the final week, we were to assess their contribution.

Sincerely
Tracey

On Tue, Oct 17, 2017 at 8:54 PM, James  wrote:

> no photos have been deleted as OSM doesnt support photos, only XML.
>
> There has been deduplication happening as people were adding 10+ of the
> same bench/statue etc. So duplicate items might have been deleted, but
> mapillary tag was transferred over.
>
> On Oct 17, 2017 8:51 PM, "Tracey P. Lauriault"  wrote:
>
> Greetings OSM Ottawa and Data Working Group;
>
> It looks like all of the COMS2200A photos have been deleted from OSM
> Ottawa.  Is that true? When I look at the map, it does look rather
> unpopulated with photos.
> Can you please confirm?
>
> Sincerely
> Tracey
>
>
> On Tue, Oct 17, 2017 at 12:46 PM, Tracey P. Lauriault 
> wrote:
>
>> Greetings OSM folks;
>>
>> I wonder if you could assist.
>>
>> Students are still getting locked out and are unable to complete their
>> assignment. Also, the message they are receiving see below states that you
>> were unable to locate me, which we know is not the case.
>>
>> It would be really great if we let the students finish their assignment
>> and that we discuss what to do with the messy data as discussed in earlier
>> parts of this stream.
>>
>> Any assistance would be most appreciated.
>> Sincerely
>> Tracey
>>
>> "Dear COMS2200A students,
>>
>> welcome to OSM and we're happy to see you engaging with our shared
>> database.
>>
>> A few of our community members have taken exception to some of the things
>> that you mapped and how you mapped them; many of your edits are not exactly
>> following the quality standards we have set for us in OSM which leads us to
>> believe that you may not have received the requisite training, especially
>> where you've made edits outside of the university district.
>>
>> Sadly we couldn't find out who the person responsible for this
>> class/course/ activity is. A few mappers have commented on edits that you
>> made, and pointed out errors or problems; this should have triggered
>> e-mails to the address used when registering but the messages seem to have
>> been ignored.
>>
>> Could you please inform your teacher/course leader to get in touch with
>> the Canadian community on the talk-ca mailing list (
>> lists.openstreetmap.org/listinfo/talk-ca) so that we can discuss how to
>> continue this exercise without degrading OSM's data quality?
>>
>> Please pause your editing activity until the matter is cleared up.
>> Thank you Frederik Ramm OSMF Data Working Group
>>
>> On Wed, Oct 11, 2017 at 9:11 AM, Tracey P. Lauriault 
>> wrote:
>>
>>> Thank you.
>>> Lets finish this assignment and then regroup to discuss whether or not
>>> this should be done again next year, and if so the best way to do it.
>>>
>>> The students will need to put together a small reflection piece on the
>>> process, that should help.  We will have identified numerous issues and
>>> error types, and we will have learned something about students and the OSM
>>> community.
>>>
>>> I am travelling quite a bit this month, if I am here I will attend the
>>> next local.  Please let me know when and where they are.
>>>
>>> Cheerio
>>> Tracey
>>>
>>> On Wed, Oct 11, 2017 at 8:30 AM, James  wrote:
>>>
 I think some people are missing the point of the class by saying: Go
 map an african village.

 The point was to have students go outside and take photos of real world
 items(surveying) and upload them to mapillary
 Then the students take the mapillary photo key and add it to the item
 in OSM
 They are supposed to learn about deriving information from
 something(photo, text,etc)

 As I've said to Tracey, I welcome the project, maybe we will get some
 new mappers out of it, but they are new mappers(we all started out new at
 one point and we've made errors in the past) and if they can learn from the
 feedback; all the better.

 On Wed, Oct 11, 2017 at 8:22 AM, john whelan 
 wrote:

> This is primarily to Tracey ca-talk has been cced.
>
> There are a number of issues here.
>
> First OSM is growing up.  No longer is it a bunch of mappers who use
> the edit tools or web page to view the map.  The data is live and 
> snapshots
> are taken by various players including OSMAND at points in time.  This can
> be once a month so if there are a small number of mistakes not a big deal.
> If there are a large number in the snapshot then OSMAND users are stuck
> with them until the next off line map is made available.  Because of
> bandwidth costs both to the end user 

Re: [OSM-talk] DWG survey on organised editing

[john whelan]

Probably what we could do with is a set of guidelines for people organising
mapping groups.  This is not policy so much as best practices.

Could this be done before we thrash out a policy?

Thanks John

On 17 Oct 2017 8:27 pm, "Frederik Ramm"  wrote:

> Hi,
>
> the results are in!
>
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/
> Results_of_Organised_Editing_Survey_2017
>
> Thank you everyone who participated.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Umfrage zum "organisierten" Mappen

[Frederik Ramm]

Hi,

On 09/21/2017 09:21 PM, Frederik Ramm wrote:
> die DWG hat eine Umfrage zum Thema "organisiertes Mappen"
> veröffentlicht.

Und hier sind die Ergebnisse:

https://wiki.osmfoundation.org/wiki/Data_Working_Group/Results_of_Organised_Editing_Survey_2017

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: [OSM-talk] DWG survey on organised editing

[Frederik Ramm]

Hi,

the results are in!

https://wiki.osmfoundation.org/wiki/Data_Working_Group/Results_of_Organised_Editing_Survey_2017

Thank you everyone who participated.

Bye
Frederik

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

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

Re: [Talk-us] hydrology Alaska

[Ben Discoe]

+1 to what AlaskaDave said.

As far as I can tell in this case, the jaggies are a result of running
ScanAerial on imagery of a low resolution (i.e. zoomed out).  At that
level (LandSat resolution), a smooth lake edge looks like a jagged set
of individual pixels, where each pixel is 28 meters across.  Turning
each LandSat pixel into a vector edge produces these unattractive,
stair-setpped, inefficient polygons.

Please don't do that.

I don't know ScanAerial well, but it seems to me that you could run it
on a higher resolution (the Bing database/API has much better than
LandSat resolution here, if you zoom in).  The resulting polygons
would then need to run through a Simplify, to remove excessive detail,
before they could be uploaded to OSM.  That should result in
appropriate number of nodes, e.g. that smooth top edge of lake.

Anton, I can produce illustrations, if you need more help to understand.

If ScanAerial cannot be configured that way, then it's simply the
wrong tool to use for this situation.

On Tue, Oct 17, 2017 at 2:52 PM, Dave Swarthout  wrote:
> The tracing for that pond ( https://www.openstreetmap.org/way/532622119) is
> horrible IMO. This is the sort of geometry that drives me crazy when I look
> at Alaskan coastlines. The long zig-zag at the top edge could be better done
> with a few points and the adjoining ponds at the SE are very rough
> approximations at best. I don't know what method you used to draw that pond
> but please don't add any more that look like that one.
>
> I have done extensive work in Alaska and I appreciate your intent to add
> more Alaskan water bodies to OSM but please find another way to add them.
> There are thousands of tiny ponds dotting the permafrost in northern Alaska.
> Using your tracing technique will add hundreds of thousands of points, many
> of them useless.
>
> Dave
> (AlaskaDave)
>
> On Tue, Oct 17, 2017 at 8:01 AM, ANT Berezhnyi 
> wrote:
>>
>> (sorry for my english)
>>
>> question:
>>
>> On 2017-10-16 02:33:13 UTC velmyshanovnyi
>>
>> http://www.hdyc.neis-one.org/?velmyshanovnyi
>>
>> wrote:
>>
>> ===
>>
>> so on the question ...
>>
>> Is it possible to vectorize the USGS on the OSM if there is no Landsat,
>> and everything else in the clouds, or in the snow, or the quality is bad ...
>>
>> Hello velmyshanovnyi , There are a number of questions here. One is "is it
>> possible to vectorize the USGS". Another is "is it a good idea to do so".
>>
>> I'd suggest that you discuss what is the best source of imagery in this
>> region with other mappers, such as "imagico" who commented on
>> https://www.openstreetmap.org/changeset/52947504 . It may be that you need
>> to use several sources and combine them manually because none of them are
>> perfect. Also I would suggest asking on the talk-us and talk-ca mailing
>> lists for advice.
>>
>> With regard to "is this a good idea" other mappers think it is not. You
>> need to persuade them that it is. You need to explain what your process is.
>> Your comment on https://www.openstreetmap.org/changeset/52947504 that says
>> "Im fixed my soft" suggests that you might be performing some kind of
>> mechanical edit. If so, you need to follow
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy , which requires
>> you to discuss what you are proposing to do with other mappers before
>> actually doing it.
>>
>> Best Regards,
>>
>> Andy Townsend, on behalf of OSM's Data Working Group.
>> https://www.openstreetmap.org/user/SomeoneElse
>>
>> 
>> My sample island/hydrology (JOSM+digitalglobe-premium+bing) not import,
>> not bot :
>>
>> https://mc.bbbike.org/mc/?lon=-164.973165=60.843461=13=2=digitalglobe-premium=mapnik=hike_bike=ol_osm-no-labels=35
>>
>> after simplifacation (v2) :
>>
>> https://www.openstreetmap.org/changeset/52809320#map=16/60.8221/-164.9684=H
>> (before see v1)
>> 
>>
>> IF:
>> if there is a need to correct some hydrology somewhere - welcome 
>>
>>
>> --
>> ++ =
>> ++ ANT (Anton Berezhnyi)
>> ++ =
>> ++ E-mail   : velmyshanov...@gmail.com
>> ++ Hangouts : velmyshanov...@gmail.com
>> ++ Telegram : @velmyshanovnyi
>> ++ Skype: velmyshanovnyi
>> ++ Viber: +380939946993
>> ++ Cell : +380939946993
>> ++ https://plus.google.com/+ANTBerezhnyi
>> ++ https://profiles.google.com/velmyshanovnyi
>> ++ https://linkedin.com/in/velmyshanovnyi
>> ++ https://facebook.com/velmyshanovnyi
>> ++ https://twitter.com/velmyshanovnyi
>> ++ =
>> ++ жNtTя, яК і iTNernЕТ,
>> ++ нAЖалb, ТЕж к0лИСь
>> ++ KіH4аЄтьCя..
>> ++ =
>>
>>
>> ___
>> Talk-us mailing list
>> 

Re: [Talk-cl] Ayuda Como mapear esto....

[Dalacost]

Quiza la pregunta a responder sería, que tan larga la separación debe ser
para considerarla una ruta distinta y hacer la distinción?
En el caso que expongo deben ser unos 500 metros de ruta donde desaparece
el bandejon, para después volver a aparecer. En otros casos quizá serán
menos metros (como por ejemplo un punto de retorno ).



On Oct 17, 2017 4:29 PM, "Cristián Serpell"  wrote:

> También puede ser por un tema de seguridad, si un vehículo de emergencia
> tiene que dar una vuelta, por ejemplo.
>
> ___
> Talk-cl mailing list
> Talk-cl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-it] QA per il routing

[liste DOT girarsi AT posteo DOT eu]

Il 17/10/2017 15:10, Cascafico Giovanni ha scritto:

Ciao Lista,

ho abbozzato un generatore di grafi stradali a "pezze" per controllare la
navigazione. Prima di dedicarmi agli inevitabili affinamenti, qualcuno può
dare un'occhiata [1], che io non abbia inventato l'acqua calda?

[1] https://www.openstreetmap.org/user/Cascafico/diary/42428



Più che "pezza" la chiamerei semplicemente "patch", si capisce meglio 
secondo me.



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

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

Re: [Talk-it] Sabbioneta progetto Cerchio d'Acqua e richiesta supporto per possibile import

[liste DOT girarsi AT posteo DOT eu]

Il 17/10/2017 14:11, Giorgio Limonta ha scritto:

Buongiorno lista,
vi scrivo per alcuni consigli relativamente ad un potenziale import chevorrei 
attivare. Sto collaborando ad un progetto per la valorizzazioneculturale delle 
mura e degli arginelli d’acqua della città di Sabbioneta (sitoUNESCO), il 
progetto prevede la realizzazione di molti studi e rilievi chedovrebbero 
portare alla raccolta di una molteplicità di informazioni di varianatura 
(percorsi ciclabili, rilievo specie arboree, etc.) che ovviamentesaranno 
condivise attraverso un sito internet 
(http://www.amiciambientesabbioneta.it/cerchiodacqua/)e un geoblog. Ho proposto 
ai membridel progetto di condividere le informazioni raccolte non solo con i 
mezzi web“classici” ma arricchendo anche i canali di condivisione delle 
informazioni delmondo Wikimedia ed in particolare di OpenStreetMap. Nel recente 
passato ho giàavuto esperienze simili ma per altre finalità. Fatta questa 
premessa ho notato che in OSM Sabbioneta èscarsamente mappata e mi piacerebbe 
quantomeno inserire la parte edificatainterna alle mura (ma non solo) per 
ricostruire una base dati sulla quale “agganciare”le diverse informazioni che 
raccoglieremo ma anche banalmente per ricostruireuna cartografia di sfondo 
adeguata per il geoblog. Il mio obiettivo sarebbequello di fare quello che 
Ale_Zena ha già fatto per il comune di Treviglio. PurtroppoSabbioneta come 
molti dei comuni del mantovano non ha ancora un DBTopograficorilasciato da 
Regione Lombardia sotto licenza IODL 2.0 (ne presenta unosemplificato DBTS con 
un dettaglio cartografico di 1:10.000 [1]) perciò pensavodi utilizzare 
l’aerofotogrammetrico che però ovviamente non presenta unalicenza esplicita in 
quanto non realizzato secondo le disposizioni normativesuccessive alla Lr 
12/2005. Da qui le mie domande: 1.   Per l’import posso utilizzare un 
genericoaccount tipo “GiorgioL_import” che potrei utilizzare anche per 
successiviimport o ne devo creare uno specifico per Sabbioneta?; 2.   Visto che 
si tratta di un import di piccolaentità devo creare comunque una pagina ad hoc 
all’interno della wiki di OSM? a.   Ho visto che esistono una serie di moduli 
giàpronti per la richiesta di pubblicazione di materiale cartografico prodotto 
conlicenza diversa da quella di OSM ma si riferisce comunque a materiale 
Opendata,io credo di essere nel caso descritto qua [2] nella wiki di OSM perciò 
michiedevo se ci fosse un modulo da cui partire da inoltrare al comune 
perfarmelo girare firmato. Poi questo modulo lo pubblico nella pagina 
wikidedicata?    Scusate per l’eccessiva lunghezza della mail e vi 
ringrazioanticipatamente per le risposte che vorrete inviarmi    Giorgio    [1] 
http://www.geoportale.regione.lombardia.it/specifiche-tecniche#point3 [2] 
http://wiki.openstreetmap.org/wiki/IT:FAQ#Perch.C3.A9_non_posso_usare_le_mappe_catastali.2C_i_piani_regolatori_o_i_CTR.3F




Ho guardato il posto, ammesso e concesso sia questo:

http://www.openstreetmap.org/#map=16/44.9966/10.4902

Per i dati di import, dipende se sono precisi o meno, e la licenza, ma 
di questo ti deluciderà meglio chi se ne è occupato o ne capisce di più.


Io ho guardato con Josm e ortofoto PCN2012, e secondo me ci sta un bel 
tasking manager per l'edificato, in una mezz'ora con 3 o 4 utenti si 
mette su tranquillamente, ovviamente, per la precisione poi bisognerà 
vedere, perchè le ortofoto aiutano, ma non più di tanto.


Ho visto ci sono tanti terreni agricoli, anche lì le ortofoto aiutano a 
creare i landuse, poi bisognerà vedere se sono rimasti intatti o cosa, 
ed il tipo di coltivazione si fà presto ad inserirlo, ovviamente chi 
conosce il posto.




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

Re: [Talk-us] hydrology Alaska

[Dave Swarthout]

The tracing for that pond ( https://www.openstreetmap.org/way/532622119) is
horrible IMO. This is the sort of geometry that drives me crazy when I look
at Alaskan coastlines. The long zig-zag at the top edge could be better
done with a few points and the adjoining ponds at the SE are very rough
approximations at best. I don't know what method you used to draw that pond
but please don't add any more that look like that one.

I have done extensive work in Alaska and I appreciate your intent to add
more Alaskan water bodies to OSM but please find another way to add them.
There are thousands of tiny ponds dotting the permafrost in northern
Alaska. Using your tracing technique will add hundreds of thousands of
points, many of them useless.

Dave
(AlaskaDave)

On Tue, Oct 17, 2017 at 8:01 AM, ANT Berezhnyi 
wrote:

> (sorry for my english)
>
> question:
>
> On 2017-10-16 02:33:13 UTC velmyshanovnyi
>
> http://www.hdyc.neis-one.org/?velmyshanovnyi
>
> wrote:
>
> ===
>
> so on the question ...
>
> Is it possible to vectorize the USGS on the OSM if there is no Landsat,
> and everything else in the clouds, or in the snow, or the quality is bad ...
>
> Hello velmyshanovnyi , There are a number of questions here. One is "is it
> possible to vectorize the USGS". Another is "is it a good idea to do so".
>
> I'd suggest that you discuss what is the best source of imagery in this
> region with other mappers, such as "imagico" who commented on
> https://www.openstreetmap.org/changeset/52947504 . It may be that you
> need to use several sources and combine them manually because none of them
> are perfect. Also I would suggest asking on the talk-us and talk-ca mailing
> lists for advice.
>
> With regard to "is this a good idea" other mappers think it is not. You
> need to persuade them that it is. You need to explain what your process is.
> Your comment on https://www.openstreetmap.org/changeset/52947504 that
> says "Im fixed my soft" suggests that you might be performing some kind of
> mechanical edit. If so, you need to follow https://wiki.
> openstreetmap.org/wiki/Mechanical_Edit_Policy , which requires you to
> discuss what you are proposing to do with other mappers before actually
> doing it.
>
> Best Regards,
>
> Andy Townsend, on behalf of OSM's Data Working Group.
> https://www.openstreetmap.org/user/SomeoneElse
> 
> My sample island/hydrology (JOSM+digitalglobe-premium+bing) not import,
> not bot :
> https://mc.bbbike.org/mc/?lon=-164.973165=60.843461=13=2=
> digitalglobe-premium=mapnik=hike_bike=ol_
> osm-no-labels=35
>
> after simplifacation (v2) :
> https://www.openstreetmap.org/changeset/52809320#map=16/60.
> 8221/-164.9684=H
> (before see v1)
> 
>
> IF:
> if there is a need to correct some hydrology somewhere - welcome 
>
>
> --
> ++ =
> ++ ANT (Anton Berezhnyi)
> ++ =
> ++ E-mail   : velmyshanov...@gmail.com
> ++ Hangouts : velmyshanov...@gmail.com
> ++ Telegram : @velmyshanovnyi
> ++ Skype: velmyshanovnyi
> ++ Viber: +380939946993 <093%20994%206993>
> ++ Cell : +380939946993 <093%20994%206993>
> ++ https://plus.google.com/+ANTBerezhnyi
> ++ https://profiles.google.com/velmyshanovnyi
> 
> ++ https://linkedin.com/in/velmyshanovnyi
> ++ https://facebook.com/velmyshanovnyi
> 
> ++ https://twitter.com/velmyshanovnyi 
> ++ =
> ++ жNtTя, яК і iTNernЕТ,
> ++ нAЖалb, ТЕж к0лИСь
> ++ KіH4аЄтьCя..
> ++ =
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Strada agro silvo pastorale

[demon.box]

si mi sono spiegato male, scusa

intendevo per non impazzire a copiare gli stessi tags (sempre uguali)
relativi alla strada agro silvo pastorale su ogni pezzo di way che ha
caratteristiche diverse ad esempio per surface, tracktype o smoothness

ciao

--enrico




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

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

Re: [OSM-talk-be] Importing Villo! API data

[CedB12]

Hello Yves,

Thank you for sharing your thoughts.

I agree with you on the problem of importing locations in bulk. Still, I
think it is safe to use the API data to clean up the names and reference
numbers of the stations we have already mapped.

As far as I know, the API "name" values match exactly the names shown on
the stations' interactive displays, while the API "address" values match
the information reported on the Villo website. I don't know about the
app or other data sources.

So when you say that "what they present as the name" is unreliable, are
you talking about the data shown on the website, i.e., the "address"
value reported in the API? Then I agree that extracting address
information from those values is difficult because of the inconsistent
formatting.

However, as far as the name tags are concerned (name, name:fr, name:nl,
official_name), I think those are supposed to reflect the data as it is
visible on location. This means that the "name" API values should be our
source for that information. Those values are formatted more
consistently, too: with very few exceptions, the value is either "NNN -
NAME" or "NNN - FRENCH_NAME/DUTCH_NAME" where NNN is the station number,
and outliers are easy to spot. Is there any reason why we should not be
using that (or the same with the number removed) as official_name?

I actually have a spreadsheet where I converted all the "name" values
reported by the API to a properly-capitalized form and tried to fix all
the typos I could find. I will share it later.

Cédric

On 10/15/2017 06:57 PM, Yves bxl-forever wrote:

Hello,

In the past weeks I have also wanted to do some cleanup on Villo! stations and 
it’s a fact that there still quite a lot of work to be done.

Just a few thoughts about the idea of bulk data imports because this is what gave us 
really "ugly" nodes sometimes.

The name itself is a problem because what they present as the name is actually a string 
that concatenates the ID of the station, the name and its address.  This is why tagging 
this as "official_name" does not seem to make any sense.

Their JSON dataset usually looks like this:

"name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN",
"address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / PAUL 
DEJAERLAAN (TEGENOVER 35 - 39)"


And we must translate it as such in our OSM nodes:

ref=76
name="Place Van Meenen - Van Meenenplein"
name:fr="Place Van Meenen"
name:nl="Van Meenenplein"
addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein"
addr:housenumber="35-39"


It’s probably feasible to parse the fields automatically and make something 
that looks clean.
But I am not sure that the street name will always match (see example here, official name 
has "Maurice" somewhere and our parsing script will not guess it unless you 
feed it with a list of all streets).

About missing names in one language, this is tricky: normally we should stick 
with the official name given by the operator.  But another approach will be 
that if we know of an official translation (because it is the same name as the 
street or even a bus stop nearby, or a building) it should be used.  And I 
agree that we should fix typos without asking, like in your example.

Another problem is that the longitude and latitude fields must be checked to 
avoid putting stations in the middle of an intersection or inside a building.


In summary, I will recommend a safer approach, i.e. extracting a list of 
missing stations, and add them one by one manually, after checking whether the 
data looks fine.
But it will be nice to hear the thoughts of other members of the community.

Have a nice day.

Yves


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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno mar 17 ott 2017 alle ore 22:38 Andreas Lattmann <
andreas.lattm...@ga-2.it> ha scritto:

> >Come minimo è semanticamente >sbagliato e contro le "regole" di OSM, una
> >descrizione va in description, non in >name.
>
> Sono curioso di sapere di quale regola stai parlando. È nel wiki? Ne è
> stato parlato nella ml nazionale?
>

http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno mar 17 ott 2017 alle ore 10:45 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> OSM non si deve adeguare a nessuna burocrazia CAI o delle Regione.
> Semplicemente i percorsi sono accatastati cosi' e noi liberiamo i dati come
> li abbiamo.
> Togliere quello che e' stato deciso come nome ufficiale del percorso
> perche' ad alcuni non piace non ha molto senso per me, sarebbe una sorta di
> vandalismo ed allonaterebbe il CAI (come altre realta') dal mondo OSM.
>

Non si tratta di togliere nulla, si tratta di mettere in name il nome,
quando ce n'è uno vero, e in description il "da-a" sempre. Se si trattasse
di un import di massa automatizzato capirei la difficoltà, ma visto che si
fa comunque a mano proprio non vedo la difficoltà.


> I problemi di ricerca che mi elenchi sono tutti facilmente risolvibili con
> delle query
>

Mi sapresti fare un esempio di query che distingue un nome vero da una
descrizione travestita, utilizzabile in un progetto su larga scala tipo
OpenandroMaps, 4UMaps o simili? Io sono dichiaratamente scarso, ma non ci
arrivo.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Strada agro silvo pastorale

[Andreas Lattmann]

ho preferito fare una relazione anzichè impazzire a
copiare gli stessi tags per ogni pezzettino di way con caratteristiche
diverse,

Scusa ma mi sono perso un pezzo: vorrai dire con caratteristiche uguali, se 
fossero diverse saresti costretto ad inserirle in ogni pezzettino di way.
Mi sbaglio? 

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-us] Low-quality NHD imports

[Ben Discoe]

I've probably done the most NHD cleanup so far (at least some degree
of fixing on the entire state of NC, most of IL, northern MI, parts of
OK/TX/UT/CO, and a lot of CA), many hundreds of hours of manual work.

Just to chime in with agreement on what everyone has said, yes to:
1. NHD has lots of issues
2. a lot of it could have been imported better
3. there are some NHD tags (like 'nhd:com_id') which are of little use
and just get in the way
4. a lot is badly out of date
5. a lot is badly overnoded (like a perfectly straight ditch using 200
noisy nodes)
6. some is badly tagged (like waterway=canal for ditches in the western USA)
7. it's still very valuable and in some places, of surprising quality
and completeness

I never just remove useless tags for the sake of removing.  They only
get touched as part of manual cleanup, which goes through a lot of
steps.

I really should write a Diary post on the steps I go through to clean
up NHD (part of these steps I already covered in
http://www.openstreetmap.org/user/bdiscoe/diary/37421)

1. Select all the waterways ("type:way AND (natural=water OR
natural=wetland OR waterway OR (child natural=water) OR (child
natural=wetland) OR (child waterway)) AND allindownloadedarea ")
2. Use JOSM validator fix-it, which will solve topology problems like
dupe vertices.
3. If the region is badly overnoded, simplify to an appropriate value
(like 80cm), then follow up with a manual cleanup/alignment.
4. Check the "waterway ends without a connection" warnings; some can
be manually fixed
5. For at least major crossings, add the bridges and culverts (I just
JOSM scripts I wrote to make this faster, but it's still very manual,
one at a time)
6. For major features that are out of date (like streams or wetlands
that were destroyed and are now shopping malls), delete or re-align
them.
7. Look over the data and fix anything else that looks very wrong

So, to answer Frederik's original question, "Is there any systematic
(or even sporadic) effort of cleaning up these old imports?"

Answer: Yes.  In addition to all the people doing great work in their
local areas, there is me.

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Andreas Lattmann]

>Come minimo è semanticamente >sbagliato e contro le "regole" di OSM, una 
>>descrizione va in description, non in >name. 

Sono curioso di sapere di quale regola stai parlando. È nel wiki? Ne è stato 
parlato nella ml nazionale?

>Se nessuna mappa commerciale indica questi nomi c'è una
>ragione...

Forse perché non hanno i dati? :-)

>Alla fine la scelta sarà fra generare
>delle
>mappe piene di scritte ridicole o non visualizzare i nomi, perdendosi
>però
>quel 5% che sarebbe utile, e nessuna delle due è una buona soluzione.

OSM prima di tutto è un DB.
Sta a chi realizza lo stile decidere se inserire i nomi dei sentieri "da qui a 
li" o ometterli. Se cominciamo a mappare per il rendering non ci salviamo più: 
se facciamo in maniera che Mapnik renderizzi bene, ci ritroveremmo altri 1000 
servizi che renderizzeranno in maniera scorretta. Quindi dedichiamoci al nostro 
lavoro (il DB) e lasciamo a chi realizza i renderer a gestire la 
visualizzazione dei nostri dati.

>e non so perché OSM debba adeguarsi alla pigrizia burocratica del CAI.

Anche se ci fosse pigrizia burocratica da parte del CAI, è il CAI a stabilire i 
nomi dei sentieri. OSM deve prendere atto delle loro decisioni ed inserire i 
nomi ufficiali assegnati, come prende atto delle decisioni dei comuni nella 
scelta toponomastica delle vie.

Non è compito di OSM decidere i nomi dei sentieri, vie o quant'altro, ma deve 
inserire "quello che c'è" che ci piaccia o meno. E se proprio non ci va, 
possiamo iscriverci al CAI, tentare di entrare nella commissione sentieri e 
dire la nostra! :-D

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk] Publishing bot code. GPL or AGPL?

[Safwat Halaby]

Thank you everyone for the very informative replies. I've decided to
use GPLv3. (And I think the difference between it and MIT is negligible
in practice for this particular use case) 

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

Re: [Talk-de] Verzeichnis aller Straßennamen in D

[Christopher Lorenz]

Hallo Detert,

der unten genannte Vortrag ist von mir. Um die von mit entworfener 
Datenstruktur aufzubauen kannst du dir die Skript unter 
https://github.com/britiger/osm_address_db herunterladen. Dabei werden auch 
etwas zeitaufwendig die Daten für Auswertungen inkl. admin_level-Hierachie 
aufgebaut. Da könntest du dir auch die benötigten Beziehungen PLZ-Ort-Straße 
herausfiltern.

Es ist die Frage was du genau brauchst, wie schon geschrieben kann ich auch für 
Deutschland aktuell bzw. D-A-CH Stand Jahresanfang die Daten liefern. Benötigst 
du alle Straßennamen, die an den Straßen (highway=*) existieren auch wenn es 
dazu keine Adresse gibt? Dabei ist in OSM zu beachten, dass dort auch teilweise 
Beschreibungen in den Straßennamen vorhanden sind wie: McDrive, Radweg, 
Parkplatz Netto, Zufahrt Segelklub, Berliner Mauerweg (Ehemaliger Postenweg der 
DDR-Grenztruppen), ... die allesamt nicht offizielle Straßennamen zu finden 
sind. Ich habe auf meine Deutschland-Datenbank mal schnell eine Abfrage 
gestartet. 

Hier die aktuellen Werte die ich für den Deutschland ermittelt habe und im OSM 
Datenbestand sind (jeweils verschiedene):

Straßennamen (highway=*): 460011 
Straßennamen in Adressen: 282940 
Straßennamen+Stadt in Adressen: 728858 

Christopher Lorenz


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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Rory, I agree with you - there are always corner cases.  And while we
concentrate on the geographical aspect (e.g.  "somewhere there might be a
large territory where the tags mean different thing"), the corner case can
actually exist in our own neighborhood, simply because our neighbor
understood some tags to mean something different.

To use the a handball vs team_handball example - if it wasn't for you, no
one would have been aware of such a distinction, and if we had a @talk
discussion of the global bot autorename to fix it, there is a good chance
it __might__ have been overlooked, and damage would be done - we don't have
as many people monitoring @talk, as we have actually mapping things.  But
if someone made a challenge to convert handball->team_handball, someone
would have caught it in your area, thus flagging the issue globally,
documenting the distinction, and cleaning up the other areas where having a
mix of both values is incorrect.

On Tue, Oct 17, 2017 at 8:29 AM, Rory McCann  wrote:

> On 16/10/17 19:49, Tobias Zwick wrote:
>
>> Except that's not true. In Ireland "handball" is Gaelic Handball¹
>>> which is a one-on-one game, not a team sport (which is apparently a
>>> different thing²). There are some sport=handball's tagged in Ireland.
>>> Now the tag is clearly wrong, and we need to figure out something about
>>> that. But if you just change sport=handball to sport=team_handball, then
>>> you've entered incorrect data, based on incorrect assumptions.
>>>
>>
>> Good catch. So, it is no good as an example for that. But no matter, I
>> think the idea got across anyhow.
>>
>
> The idea that automated edits and tag replacements on a worldwide scale
> are a bad idea and might have edge cases you've never heard about? 
>
> but it is the only documentation we have.
>>
>
> Not really. We have editors, and what they do, map styles and what they
> do, programmes like osm2pgsql and what they do. That's a form of
> "unwritten documentation".
>
>
>
> ___
> 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] Publishing bot code. GPL or AGPL?

[Kathleen Lu]

Hi Safwat,

I thought about your hypothetical, and if someone was using a personally
modified bot for personal use, the AGPL does not impose different
conditions than GPL ("if you modify the Program, your modified version must
prominently offer all users interacting with it remotely..." doesn't apply
if you have no users other than yourself). You also would, as a practical
matter, have no idea it was happening anyway.

So it does not sound like AGPL would make a difference in the specific
hypothetical you describe.

I also do not think it is a very likely situation to come up. I have a hard
time imagining that someone would modify a GPL OSM bot for public use but
then refuse to share the code. Especially now since so much code is on GH
where it is easier to send a PR to the original or fork into a public repo
than to keep the code private. What would be their motivation? I actually
don't think you need GPL at all, as motivation for the community to help
improve a bot would not change if it were under a permissive license like
MIT.

BTW, there are downsides to AGPL - Notably, the definition of a "covered
work" is vague and some have argued that using AGPL code "to form a larger
program" means that you also have to release the source for any modules you
use with even unmodified AGPL code. This has led to many companies
prohibiting AGPL use entirely, so could decrease use of your bot. Assuming
that you are applying an open source license because you want others to use
it, this would seem to be a negative.

Best,
-Kathleen

On Tue, Oct 17, 2017 at 9:27 AM Safwat Halaby  wrote:

> I understand that GPLv3 has a loophole in which someone could modify
> your GPL-licensed code, and then run it on a server which offers some
> service. Since a service is being sent over the wire, and not the
> executable itself, then they can keep their modified code private. AGPL
> prevents this loophole.
>
> Does the same logic apply for OSM bots? Would someone using a
> personally modified GPL'ed bot not have to publish it? Should I use
> AGPL instead if I wish to force any bot user to publish the code?
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cl] Ayuda Como mapear esto....

[Julio Costa Zambelli]

Lo que pasa es que la idea es mapear la "realidad del terreno", no lo que
creamos es el espíritu detrás de esas tachas o lo que nos resulte más fácil
para gestionar relaciones.

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl

https://www.openstreetmap.cl/
Cel: +56(9)89981083

2017-10-17 16:16 GMT-03:00 Danilo Lacoste :

> yo los pondría separados, por que así es muuucho más facil
> agregar/manipular las relaciones que podrían aparecer en esas rutas.
> :D Después de todo el espíritu de esas calles es que sean separadas,
> quizá no lo han hecho solo por presupuesto.
>
> 2017-10-17 15:59 GMT-03:00 Julio Costa Zambelli <
> julio.co...@openstreetmap.cl>:
> > Mi opinión es que una segregación debe ser un disuasivo para el auto que
> > podría dar la vuelta o cruzar, es decir, debe tener 1) una cuneta de
> altura
> > que realmente evite que pase un auto, 2) una barrera "New Jersey", o como
> > mínimo 3) bastones plásticos
> > (https://www.mapillary.com/map/im/nM7GCWcYDUPFWWtTKWjB-w). Los
> reflectantes,
> > grandes o chicos, me parecen discutibles, pero podemos acordarlo entre
> > todos.
> >
> > Saludos
> >
> > Julio Costa Zambelli
> > Fundación OpenStreetMap Chile
> >
> > julio.co...@openstreetmap.cl
> >
> > https://www.openstreetmap.cl/
> > Cel: +56(9)89981083
> >
> > 2017-10-17 14:46 GMT-03:00 Danilo Lacoste :
> >>
> >> Y que pasa con las separaciones casi imperceptibles como estas tachas
> que
> >> ponen aveces ? (En Santiago las usan harto para separar).
> >> Si te fijas en este caso existe en una parte del tramo en cuestión.
> >>
> >> On Oct 17, 2017 14:36, "Julio Costa Zambelli"
> >>  wrote:
> >>>
> >>> Hola Danilo,
> >>>
> >>> Si no hay segregación física (por ejemplo un bandejon central), lo
> >>> correcto es mapear con una sola vía y la cantidad de pistas
> >>> correspondientes, agregando la cantidad de pistas en cada sentido con:
> >>> lanes=4, lanes:forward=2 y lanes:backward=2.
> >>>
> >>> Saludos,
> >>>
> >>> Julio Costa Zambelli
> >>> Fundación OpenStreetMap Chile
> >>>
> >>> julio.co...@openstreetmap.cl
> >>>
> >>> https://www.openstreetmap.cl/
> >>> Cel: +56(9)89981083
> >>>
> >>> 2017-10-17 13:01 GMT-03:00 Danilo Lacoste :
> 
>  Estimados,
> 
>  Discutiendo con un colaborador en Temuco me asaltó esta duda, ¿como
>  mapear este sector?
> 
>  Tenemos una doble pista de avenida central en Temuco, que al salir de
>  la ciudad y conectarse  a la ruta 5 debe hacerlo a través de un trébol
>  de 4 hojas (así lo llamo yo :D). Antes de enfrentarlo el bandejón
>  central desaparece y aquí en mi opinión debería mantenerse la lógica
>  de dibujar 2 pistas a pesar que no existe el bandejón durante esos
>  metros (deben ser unos 500-800 metros quizá)
> 
>  Aquí hay imágenes recientes, porfavor avanzar unos 200 metros para
>  observar el tipo de pista y cuando comienza a desaparecer el bandejón.
> 
> 
>  https://www.mapillary.com/app/?lat=-38.750955=-72.
> 609237=20=hTypOmoAbSCYTMiAFA_New=0.5144342784837512=0.
> 5551724211959315=0=photo
> 
> 
> 
>  Aquí se puede ver que el colaborador modificó el mapa, dejando sólo
>  una pista con 4 carriles en vez de 2 pistas con 2 carriles c/u.
>  http://www.openstreetmap.org/#map=19/-38.75195/-72.60911
> 
> 
>  La pregunta es, como debe hacerse?
>  Pregunto pues ahora estoy a punto de incorporar varias relaciones y
>  que afectan esa ruta y claro la idea es hacerlo de forma correcta
>  inmediatamente y no complicar a futuros editores.
> 
>  saludos.
> 
>  --
>  Danilo Lacoste Z.   dan...@lacosox.org
>  Ing. Civil en informática
>  www.lacosox.org
> 
>  ___
>  Talk-cl mailing list
>  Talk-cl@openstreetmap.org
>  https://lists.openstreetmap.org/listinfo/talk-cl
> >>>
> >>>
> >
>
>
>
> --
> Danilo Lacoste Z.   dan...@lacosox.org
> Ing. Civil en informática
> www.lacosox.org
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-cl] Ayuda Como mapear esto....

[Danilo Lacoste]

yo los pondría separados, por que así es muuucho más facil
agregar/manipular las relaciones que podrían aparecer en esas rutas.
:D Después de todo el espíritu de esas calles es que sean separadas,
quizá no lo han hecho solo por presupuesto.

2017-10-17 15:59 GMT-03:00 Julio Costa Zambelli :
> Mi opinión es que una segregación debe ser un disuasivo para el auto que
> podría dar la vuelta o cruzar, es decir, debe tener 1) una cuneta de altura
> que realmente evite que pase un auto, 2) una barrera "New Jersey", o como
> mínimo 3) bastones plásticos
> (https://www.mapillary.com/map/im/nM7GCWcYDUPFWWtTKWjB-w). Los reflectantes,
> grandes o chicos, me parecen discutibles, pero podemos acordarlo entre
> todos.
>
> Saludos
>
> Julio Costa Zambelli
> Fundación OpenStreetMap Chile
>
> julio.co...@openstreetmap.cl
>
> https://www.openstreetmap.cl/
> Cel: +56(9)89981083
>
> 2017-10-17 14:46 GMT-03:00 Danilo Lacoste :
>>
>> Y que pasa con las separaciones casi imperceptibles como estas tachas que
>> ponen aveces ? (En Santiago las usan harto para separar).
>> Si te fijas en este caso existe en una parte del tramo en cuestión.
>>
>> On Oct 17, 2017 14:36, "Julio Costa Zambelli"
>>  wrote:
>>>
>>> Hola Danilo,
>>>
>>> Si no hay segregación física (por ejemplo un bandejon central), lo
>>> correcto es mapear con una sola vía y la cantidad de pistas
>>> correspondientes, agregando la cantidad de pistas en cada sentido con:
>>> lanes=4, lanes:forward=2 y lanes:backward=2.
>>>
>>> Saludos,
>>>
>>> Julio Costa Zambelli
>>> Fundación OpenStreetMap Chile
>>>
>>> julio.co...@openstreetmap.cl
>>>
>>> https://www.openstreetmap.cl/
>>> Cel: +56(9)89981083
>>>
>>> 2017-10-17 13:01 GMT-03:00 Danilo Lacoste :

 Estimados,

 Discutiendo con un colaborador en Temuco me asaltó esta duda, ¿como
 mapear este sector?

 Tenemos una doble pista de avenida central en Temuco, que al salir de
 la ciudad y conectarse  a la ruta 5 debe hacerlo a través de un trébol
 de 4 hojas (así lo llamo yo :D). Antes de enfrentarlo el bandejón
 central desaparece y aquí en mi opinión debería mantenerse la lógica
 de dibujar 2 pistas a pesar que no existe el bandejón durante esos
 metros (deben ser unos 500-800 metros quizá)

 Aquí hay imágenes recientes, porfavor avanzar unos 200 metros para
 observar el tipo de pista y cuando comienza a desaparecer el bandejón.


 https://www.mapillary.com/app/?lat=-38.750955=-72.609237=20=hTypOmoAbSCYTMiAFA_New=0.5144342784837512=0.5551724211959315=0=photo



 Aquí se puede ver que el colaborador modificó el mapa, dejando sólo
 una pista con 4 carriles en vez de 2 pistas con 2 carriles c/u.
 http://www.openstreetmap.org/#map=19/-38.75195/-72.60911


 La pregunta es, como debe hacerse?
 Pregunto pues ahora estoy a punto de incorporar varias relaciones y
 que afectan esa ruta y claro la idea es hacerlo de forma correcta
 inmediatamente y no complicar a futuros editores.

 saludos.

 --
 Danilo Lacoste Z.   dan...@lacosox.org
 Ing. Civil en informática
 www.lacosox.org

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



-- 
Danilo Lacoste Z.   dan...@lacosox.org
Ing. Civil en informática
www.lacosox.org

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

Re: [OSM-talk] Publishing bot code. GPL or AGPL?

[James]

You could always release it under Mozilla Public License 2.0 and that
explicitely requires people to offer source code.

On Tue, Oct 17, 2017 at 3:01 PM, Nicolás Alvarez 
wrote:

> 2017-10-17 13:27 GMT-03:00 Safwat Halaby :
> > I understand that GPLv3 has a loophole in which someone could modify
> > your GPL-licensed code, and then run it on a server which offers some
> > service. Since a service is being sent over the wire, and not the
> > executable itself, then they can keep their modified code private. AGPL
> > prevents this loophole.
> >
> > Does the same logic apply for OSM bots? Would someone using a
> > personally modified GPL'ed bot not have to publish it? Should I use
> > AGPL instead if I wish to force any bot user to publish the code?
>
> If I run a modified bot against the OSM server, that doesn't mean you
> are interacting with my bot over the network, so even with AGPL I'm
> not required to give you the source code.
>
> --
> Nicolás
>
> ___
> 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-be] GRB Flanders

[Pieter Vander Vennet]

Hallo allemaal,

Waar kan ik wat meer informatie vinden over de AGIV GRB 'Flanders' kaarten?
En hoe teken ik die het beste?

De voorbije weken heb ik serieus wat huisjes getraced, maar dat moet toch
efficiënter kunnen...

Ik las ergens iets over plugins in JOSM... Is er een tutorial voor? (Of als
iemand mij dat in een paar woorden kan uitleggen, wil ik die ook wel
schrijven).

Ik vond deze wiki-pagina

maar die is erg verouderd (slechts één link die nog werkt).

Met vriendelijke groeten,
Pieter Vander Vennet
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] Publishing bot code. GPL or AGPL?

[Nicolás Alvarez]

2017-10-17 13:27 GMT-03:00 Safwat Halaby :
> I understand that GPLv3 has a loophole in which someone could modify
> your GPL-licensed code, and then run it on a server which offers some
> service. Since a service is being sent over the wire, and not the
> executable itself, then they can keep their modified code private. AGPL
> prevents this loophole.
>
> Does the same logic apply for OSM bots? Would someone using a
> personally modified GPL'ed bot not have to publish it? Should I use
> AGPL instead if I wish to force any bot user to publish the code?

If I run a modified bot against the OSM server, that doesn't mean you
are interacting with my bot over the network, so even with AGPL I'm
not required to give you the source code.

-- 
Nicolás

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

Re: [Talk-cl] Ayuda Como mapear esto....

[Julio Costa Zambelli]

Mi opinión es que una segregación debe ser un disuasivo para el auto que
podría dar la vuelta o cruzar, es decir, debe tener 1) una cuneta de altura
que realmente evite que pase un auto, 2) una barrera "New Jersey", o como
mínimo 3) bastones plásticos (
https://www.mapillary.com/map/im/nM7GCWcYDUPFWWtTKWjB-w). Los reflectantes,
grandes o chicos, me parecen discutibles, pero podemos acordarlo entre
todos.

Saludos

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl

https://www.openstreetmap.cl/
Cel: +56(9)89981083

2017-10-17 14:46 GMT-03:00 Danilo Lacoste :

> Y que pasa con las separaciones casi imperceptibles como estas tachas que
> ponen aveces ? (En Santiago las usan harto para separar).
> Si te fijas en este caso existe en una parte del tramo en cuestión.
>
> On Oct 17, 2017 14:36, "Julio Costa Zambelli" <
> julio.co...@openstreetmap.cl> wrote:
>
>> Hola Danilo,
>>
>> Si no hay segregación física (por ejemplo un bandejon central), lo
>> correcto es mapear con una sola vía y la cantidad de pistas
>> correspondientes, agregando la cantidad de pistas en cada sentido con:
>> lanes=4, lanes:forward=2 y lanes:backward=2.
>>
>> Saludos,
>>
>> Julio Costa Zambelli
>> Fundación OpenStreetMap Chile
>>
>> julio.co...@openstreetmap.cl
>>
>> https://www.openstreetmap.cl/
>> Cel: +56(9)89981083 <09%208998%201083>
>>
>> 2017-10-17 13:01 GMT-03:00 Danilo Lacoste :
>>
>>> Estimados,
>>>
>>> Discutiendo con un colaborador en Temuco me asaltó esta duda, ¿como
>>> mapear este sector?
>>>
>>> Tenemos una doble pista de avenida central en Temuco, que al salir de
>>> la ciudad y conectarse  a la ruta 5 debe hacerlo a través de un trébol
>>> de 4 hojas (así lo llamo yo :D). Antes de enfrentarlo el bandejón
>>> central desaparece y aquí en mi opinión debería mantenerse la lógica
>>> de dibujar 2 pistas a pesar que no existe el bandejón durante esos
>>> metros (deben ser unos 500-800 metros quizá)
>>>
>>> Aquí hay imágenes recientes, porfavor avanzar unos 200 metros para
>>> observar el tipo de pista y cuando comienza a desaparecer el bandejón.
>>>
>>> https://www.mapillary.com/app/?lat=-38.750955=-72.609237
>>> =20=hTypOmoAbSCYTMiAFA_New=0.51443427848375
>>> 12=0.5551724211959315=0=photo
>>>
>>>
>>>
>>> Aquí se puede ver que el colaborador modificó el mapa, dejando sólo
>>> una pista con 4 carriles en vez de 2 pistas con 2 carriles c/u.
>>> http://www.openstreetmap.org/#map=19/-38.75195/-72.60911
>>>
>>>
>>> La pregunta es, como debe hacerse?
>>> Pregunto pues ahora estoy a punto de incorporar varias relaciones y
>>> que afectan esa ruta y claro la idea es hacerlo de forma correcta
>>> inmediatamente y no complicar a futuros editores.
>>>
>>> saludos.
>>>
>>> --
>>> Danilo Lacoste Z.   dan...@lacosox.org
>>> Ing. Civil en informática
>>> www.lacosox.org
>>>
>>> ___
>>> Talk-cl mailing list
>>> Talk-cl@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cl
>>>
>>
>>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-us] Low-quality NHD imports

[Michael Patrick]

> Maybe we can get someone to host NHD data for others to trace in. If
anyone
is reading this and is willing to host the data, I'm willing to help with
the design and conversions.

The USGS provides several WMS endpoints for the NHD
 , most likely these will connect with
JOSM ( and qGIS ) for tracing or import.

Depending when imports were made will affect the quality - NHD is a moving
target, and as high resolution aerial Lidar and Satellite SAR elevation
data is made available, the resolution improves dramatically. Also, there
are different datasets available for different scales. See
https://nhd.usgs.gov/NHDPlus_HR.html

> (Winters can be miserable.)

I miss Chinooks! https://en.wikipedia.org/wiki/Chinook_wind

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Philippe Verdy]

Il y a une raison pour ça: le "name=*" peut ne pas être seul et accompagné
par exemple de "name:de=*".
Quand un nom est cherché, il l'est d'abord dans la langue la plus précise
et ensuite dans l'ordre des autres langues préférées de l'utilisateur (s'il
y a un utilisateur), puis ensuite en utilsiant des langues "fallbacks" sur
chacune de ces langues. le nom par défaut (sans langue précisée) ne sera
utilisé qu'en **dernier** ressort. (voir pour ça les RFC de BCP 47 qui
document comment àa marche). Maintenant imaginons un utilisateur alsacien
qui cherche un nom alémanique (name:gsw=*) et n'en trouve pas, puis un nom
en français (name:fr=*), il n'en trouve pas, donc se rabat sur l'allemand
(name:de=*) alors que le français était bien là (mais pas explicitement
indiqué!). Avec "name:fr=*" explicitement indiqué, il aurait eu le nom
français cherché!

Le problème est que le nom par défaut n'indique pas explicitement dans
quelle langue il est indiqué, ce peut être n'importe laquelle (même en
France, où les noms anglais ou dans d'autres langues étrangères ou
régionales sont courants et quand la norme française ne s'impose pas pour
les toponymes officiels).

Je veux bien qu'on ne soit pas obligé de "dupliquer" les noms mais on n'a
en fait rien pour indiquer dans quelle(s) langue(s) est écrit le "name=*"
(où il peut y en avoir plusieurs tout aussi officiels pour les objets
frontaliers ou dans les régions officiellement multilingues), permettant de
dire que si on recherche un "name:fr=*", on peut le prendre directement
dans le "name=*".

Tu as pris le mauvais exemple avec Londres (qui n'est pas officiellement
francophone ni en France): on s'attend à trouver un "name:fr=Londres" mais
par défaut on voudra aussi "name:en=London" mais pas un "name=Lone Done"
qui pourrait être un 'slang' en jargon londonnien, ni name="London
/ Llundain" (avec l'adjonction bilingue en gallois/cymraeg pour peu que le
gallois soit co-officiel dans la ville comme indiqué alors avec
"name:cy=Llundain") !


Le 17 octobre 2017 à 19:22, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Le 2017 Here 17 à 19:12, Philippe Verdy  a écrit :
>
>>
>>
> Pas du tout d'accord, il n'y a strictement AUCUNE différence de statut
> officiel entre name=* et name=fr pour les objets situés en France. Si un
> nom est officiel en France c'est le même dans name=* et name:fr=*.
>
> Les noms vernaculaires français sont à mettre ailleurs (alt_name:fr=*)
>
> Et dans ce cas il n'y a strictement aucune "incitation" et même c'est la
> meilleure façon d'éviter un écrasement brutal qui ne conserve aucun nom
> français officiel indispensable aux recherches et le géocodage, ou pour
> trouver les adresses postales correctes (telles qu'on les trouve sur les
> annuaires, cartes de visite, annonces publicitaires, guides touristiques,
> et qui sont toujours aussi sur les panneaux de rues quand ce sont des noms
> de rues, et aussi dans le Fantoir, etc.).
>
> Il y a des cas particuliers de noms bilingues (les objets frontaliers
> comme les nouds de cols ou pics frontière qui ont deux noms co-officiels
> (par exemple un en français ET un en espagnol) et dans ce seul cas name=*
> peut contenir les deux puisqu'on ne peut pas choisir une langue au
> détriment d'une autre.
> Et alors on mettre le nom français (seul) dans name:fr=*, et le nom
> espagnol (seul) dans name:es=*.
> On peut ensuite ajouter un name:oc=*, ou name:eu=* (ou name:la=* pour les
> noms latins des voies de Compostelle).
>
>
>
> Sur la page **name=* en anglais, il est bien indiqué qu’il faut y mettre
> le « default name », donc, si le nom est déjà mis par défaut, il n’y a
> aucune raison logique de le doublonner, ou alors « *default* » compte
> pour du beurre.
>
> La  précision *:fr *ne peut alors concerner que ce qui ne serait pas là
> par défaut. C’est comme cela que ça marche dans la plupart des cas,où on se
> donne la peine de définir une valeur par défaut.
> Quelle raison y aurait-il de déroger à la régle du défaut ?
>
>
> Christian R.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cl] Ayuda Como mapear esto....

[Danilo Lacoste]

Y que pasa con las separaciones casi imperceptibles como estas tachas que
ponen aveces ? (En Santiago las usan harto para separar).
Si te fijas en este caso existe en una parte del tramo en cuestión.

On Oct 17, 2017 14:36, "Julio Costa Zambelli" 
wrote:

> Hola Danilo,
>
> Si no hay segregación física (por ejemplo un bandejon central), lo
> correcto es mapear con una sola vía y la cantidad de pistas
> correspondientes, agregando la cantidad de pistas en cada sentido con:
> lanes=4, lanes:forward=2 y lanes:backward=2.
>
> Saludos,
>
> Julio Costa Zambelli
> Fundación OpenStreetMap Chile
>
> julio.co...@openstreetmap.cl
>
> https://www.openstreetmap.cl/
> Cel: +56(9)89981083 <09%208998%201083>
>
> 2017-10-17 13:01 GMT-03:00 Danilo Lacoste :
>
>> Estimados,
>>
>> Discutiendo con un colaborador en Temuco me asaltó esta duda, ¿como
>> mapear este sector?
>>
>> Tenemos una doble pista de avenida central en Temuco, que al salir de
>> la ciudad y conectarse  a la ruta 5 debe hacerlo a través de un trébol
>> de 4 hojas (así lo llamo yo :D). Antes de enfrentarlo el bandejón
>> central desaparece y aquí en mi opinión debería mantenerse la lógica
>> de dibujar 2 pistas a pesar que no existe el bandejón durante esos
>> metros (deben ser unos 500-800 metros quizá)
>>
>> Aquí hay imágenes recientes, porfavor avanzar unos 200 metros para
>> observar el tipo de pista y cuando comienza a desaparecer el bandejón.
>>
>> https://www.mapillary.com/app/?lat=-38.750955=-72.609237
>> =20=hTypOmoAbSCYTMiAFA_New=0.51443427848375
>> 12=0.5551724211959315=0=photo
>>
>>
>>
>> Aquí se puede ver que el colaborador modificó el mapa, dejando sólo
>> una pista con 4 carriles en vez de 2 pistas con 2 carriles c/u.
>> http://www.openstreetmap.org/#map=19/-38.75195/-72.60911
>>
>>
>> La pregunta es, como debe hacerse?
>> Pregunto pues ahora estoy a punto de incorporar varias relaciones y
>> que afectan esa ruta y claro la idea es hacerlo de forma correcta
>> inmediatamente y no complicar a futuros editores.
>>
>> saludos.
>>
>> --
>> Danilo Lacoste Z.   dan...@lacosox.org
>> Ing. Civil en informática
>> www.lacosox.org
>>
>> ___
>> Talk-cl mailing list
>> Talk-cl@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cl
>>
>
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-cl] Ayuda Como mapear esto....

[Julio Costa Zambelli]

Hola Danilo,

Si no hay segregación física (por ejemplo un bandejon central), lo correcto
es mapear con una sola vía y la cantidad de pistas correspondientes,
agregando la cantidad de pistas en cada sentido con: lanes=4,
lanes:forward=2 y lanes:backward=2.

Saludos,

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl

https://www.openstreetmap.cl/
Cel: +56(9)89981083

2017-10-17 13:01 GMT-03:00 Danilo Lacoste :

> Estimados,
>
> Discutiendo con un colaborador en Temuco me asaltó esta duda, ¿como
> mapear este sector?
>
> Tenemos una doble pista de avenida central en Temuco, que al salir de
> la ciudad y conectarse  a la ruta 5 debe hacerlo a través de un trébol
> de 4 hojas (así lo llamo yo :D). Antes de enfrentarlo el bandejón
> central desaparece y aquí en mi opinión debería mantenerse la lógica
> de dibujar 2 pistas a pesar que no existe el bandejón durante esos
> metros (deben ser unos 500-800 metros quizá)
>
> Aquí hay imágenes recientes, porfavor avanzar unos 200 metros para
> observar el tipo de pista y cuando comienza a desaparecer el bandejón.
>
> https://www.mapillary.com/app/?lat=-38.750955=-72.
> 609237=20=hTypOmoAbSCYTMiAFA_New=0.5144342784837512=0.
> 5551724211959315=0=photo
>
>
>
> Aquí se puede ver que el colaborador modificó el mapa, dejando sólo
> una pista con 4 carriles en vez de 2 pistas con 2 carriles c/u.
> http://www.openstreetmap.org/#map=19/-38.75195/-72.60911
>
>
> La pregunta es, como debe hacerse?
> Pregunto pues ahora estoy a punto de incorporar varias relaciones y
> que afectan esa ruta y claro la idea es hacerlo de forma correcta
> inmediatamente y no complicar a futuros editores.
>
> saludos.
>
> --
> Danilo Lacoste Z.   dan...@lacosox.org
> Ing. Civil en informática
> www.lacosox.org
>
> ___
> Talk-cl mailing list
> Talk-cl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

[talk-au] NTLIS data licensing

[Jubal Harpster]

Hi All,

We we're wondering if anyone has approached the Northern Territories LIS 
department and checked about compatibility with OSM. Their web services 
(https://transport.nt.gov.au/lands-and-planning/northern-territory-land-information-systems-ntlis/about-ntlis)
  would be a great source for corroborating information if available. I don't 
see them listed anywhere in the contributors page on wiki, has anyone 
approached them?

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Christian Rogel]

> Le 2017 Here 17 à 19:12, Philippe Verdy  a écrit :
> 
> 
> Pas du tout d'accord, il n'y a strictement AUCUNE différence de statut 
> officiel entre name=* et name=fr pour les objets situés en France. Si un nom 
> est officiel en France c'est le même dans name=* et name:fr=*.
> 
> Les noms vernaculaires français sont à mettre ailleurs (alt_name:fr=*)
> 
> Et dans ce cas il n'y a strictement aucune "incitation" et même c'est la 
> meilleure façon d'éviter un écrasement brutal qui ne conserve aucun nom 
> français officiel indispensable aux recherches et le géocodage, ou pour 
> trouver les adresses postales correctes (telles qu'on les trouve sur les 
> annuaires, cartes de visite, annonces publicitaires, guides touristiques, et 
> qui sont toujours aussi sur les panneaux de rues quand ce sont des noms de 
> rues, et aussi dans le Fantoir, etc.).
> 
> Il y a des cas particuliers de noms bilingues (les objets frontaliers comme 
> les nouds de cols ou pics frontière qui ont deux noms co-officiels (par 
> exemple un en français ET un en espagnol) et dans ce seul cas name=* peut 
> contenir les deux puisqu'on ne peut pas choisir une langue au détriment d'une 
> autre.
> Et alors on mettre le nom français (seul) dans name:fr=*, et le nom espagnol 
> (seul) dans name:es=*.
> On peut ensuite ajouter un name:oc=*, ou name:eu=* (ou name:la=* pour les 
> noms latins des voies de Compostelle).
> 


Sur la page *name= en anglais, il est bien indiqué qu’il faut y mettre le « 
default name », donc, si le nom est déjà mis par défaut, il n’y a aucune raison 
logique de le doublonner, ou alors « default » compte pour du beurre.

La  précision :fr ne peut alors concerner que ce qui ne serait pas là par 
défaut. C’est comme cela que ça marche dans la plupart des cas,où on se donne 
la peine de définir une valeur par défaut.
Quelle raison y aurait-il de déroger à la régle du défaut ?


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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Philippe Verdy]

Le 17 octobre 2017 à 18:11, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Le 2017 Here 17 à 14:57, Julien Lepiller  a écrit :
>
> Le 2017-10-17 14:07, marc marc a écrit :
>
> Bonjour,
> comme je disais la dernière fois :
> - il faut corriger l’ambiguïté sur la page wiki (edit de Philippe, je
> n'ai pas été vérifié la situation actuelle, peux-être ais-je raté l'info
> que cela a été fait).
>
>
> C'était toujours là. J'ai tenté une modif pour clarifier, mais si ça ne va
> pas, n'hésitez pas à reverter, je ne m'en offusquerai pas. Peut-être
> faudrait-il ajouter un paragraphe pour expliquer le coup d'iness et fantoir
> avant ? J'ai peut-être utilisé un ton un peu trop catégorique dans le wiki.
>
> - mettre un commentaire publique sur le changeset rappelant que la
> France n'est pas une zone bilingue et que par conséquent il n'y a qu'un
> seul name, celui repris dans l'usage courant tel que renseigné dans
> iness ou fantoir et que les autres versions sont les bienvenue dans name:xx
> inviter la personne concernée au dialogue ici par exemple.
> - si une personne prévenue continue alors on pourra passer au dgw,
> idéalement par un membre d'osm-fr pour la légitimité de la communauté,
> à défaut tout le monde peux le faire.
> Mais n'ayant pas eu de retour ni trouvé de commentaire sur les
> changeset, je n'ai pour ma part pas encore contacté le dgw, n'ayant pas
> le détail de qui a prévenu qui.
> Cordialement,
> Marc
>
>
>
> J’ai corrigé la page en Multilingual names en révoquant des modifications
> de Philippe (28-05-16), ce qui donne la nouvelle rédaction suivante
>
> name =* for the default
> official name, as defined by the State-runned INSEE or by the municipal
> land registry (the cadastre). It may contain a local language name in
> bilingual areas, none of them official in France
> name:fr =* for the
> vernacular French name (needed exclusively off territories of the French
> Republic, especially for French variants like *Londres* for *London
> * or *Munich* for *München
> *)
>
>
Pas du tout d'accord, il n'y a strictement AUCUNE différence de statut
officiel entre name=* et name=fr pour les objets situés en France. Si un
nom est officiel en France c'est le même dans name=* et name:fr=*.

Les noms vernaculaires français sont à mettre ailleurs (alt_name:fr=*)

Et dans ce cas il n'y a strictement aucune "incitation" et même c'est la
meilleure façon d'éviter un écrasement brutal qui ne conserve aucun nom
français officiel indispensable aux recherches et le géocodage, ou pour
trouver les adresses postales correctes (telles qu'on les trouve sur les
annuaires, cartes de visite, annonces publicitaires, guides touristiques,
et qui sont toujours aussi sur les panneaux de rues quand ce sont des noms
de rues, et aussi dans le Fantoir, etc.).

Il y a des cas particuliers de noms bilingues (les objets frontaliers comme
les nouds de cols ou pics frontière qui ont deux noms co-officiels (par
exemple un en français ET un en espagnol) et dans ce seul cas name=* peut
contenir les deux puisqu'on ne peut pas choisir une langue au détriment
d'une autre.
Et alors on mettre le nom français (seul) dans name:fr=*, et le nom
espagnol (seul) dans name:es=*.
On peut ensuite ajouter un name:oc=*, ou name:eu=* (ou name:la=* pour les
noms latins des voies de Compostelle).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[Tracey P. Lauriault]

Greetings OSM folks;

I wonder if you could assist.

Students are still getting locked out and are unable to complete their
assignment. Also, the message they are receiving see below states that you
were unable to locate me, which we know is not the case.

It would be really great if we let the students finish their assignment and
that we discuss what to do with the messy data as discussed in earlier
parts of this stream.

Any assistance would be most appreciated.
Sincerely
Tracey

"Dear COMS2200A students,

welcome to OSM and we're happy to see you engaging with our shared database.

A few of our community members have taken exception to some of the things
that you mapped and how you mapped them; many of your edits are not exactly
following the quality standards we have set for us in OSM which leads us to
believe that you may not have received the requisite training, especially
where you've made edits outside of the university district.

Sadly we couldn't find out who the person responsible for this
class/course/ activity is. A few mappers have commented on edits that you
made, and pointed out errors or problems; this should have triggered
e-mails to the address used when registering but the messages seem to have
been ignored.

Could you please inform your teacher/course leader to get in touch with the
Canadian community on the talk-ca mailing list (
lists.openstreetmap.org/listinfo/talk-ca) so that we can discuss how to
continue this exercise without degrading OSM's data quality?

Please pause your editing activity until the matter is cleared up.
Thank you Frederik Ramm OSMF Data Working Group

On Wed, Oct 11, 2017 at 9:11 AM, Tracey P. Lauriault 
wrote:

> Thank you.
> Lets finish this assignment and then regroup to discuss whether or not
> this should be done again next year, and if so the best way to do it.
>
> The students will need to put together a small reflection piece on the
> process, that should help.  We will have identified numerous issues and
> error types, and we will have learned something about students and the OSM
> community.
>
> I am travelling quite a bit this month, if I am here I will attend the
> next local.  Please let me know when and where they are.
>
> Cheerio
> Tracey
>
> On Wed, Oct 11, 2017 at 8:30 AM, James  wrote:
>
>> I think some people are missing the point of the class by saying: Go map
>> an african village.
>>
>> The point was to have students go outside and take photos of real world
>> items(surveying) and upload them to mapillary
>> Then the students take the mapillary photo key and add it to the item in
>> OSM
>> They are supposed to learn about deriving information from
>> something(photo, text,etc)
>>
>> As I've said to Tracey, I welcome the project, maybe we will get some new
>> mappers out of it, but they are new mappers(we all started out new at one
>> point and we've made errors in the past) and if they can learn from the
>> feedback; all the better.
>>
>> On Wed, Oct 11, 2017 at 8:22 AM, john whelan 
>> wrote:
>>
>>> This is primarily to Tracey ca-talk has been cced.
>>>
>>> There are a number of issues here.
>>>
>>> First OSM is growing up.  No longer is it a bunch of mappers who use the
>>> edit tools or web page to view the map.  The data is live and snapshots are
>>> taken by various players including OSMAND at points in time.  This can be
>>> once a month so if there are a small number of mistakes not a big deal.  If
>>> there are a large number in the snapshot then OSMAND users are stuck with
>>> them until the next off line map is made available.  Because of bandwidth
>>> costs both to the end user and to OSMAND it can be two or three months
>>> before the errors are cleared.
>>>
>>> Second the email over Frederick's signature is extremely polite for
>>> Frederick.  He wrote the book on OSM and is part of the group currently
>>> looking at whether we need a formal policy for handling edits by groups of
>>> organised mappers.  The DWG working group is the highest central authority
>>> within OSM and is concerned with data quality or vandalism.  I think the
>>> Carlton students edits show there is a very definite need.  A number of
>>> mappers including myself were hoping there wouldn't be a need for something
>>> quite so formal.  Note to Frederick if you read this change my response to
>>> the survey.
>>>
>>> Third OpenStreetMap is very rich in what can be mapped.  In an urban
>>> area it can be very complex to map.  For example currently there is a push
>>> within OpenStreetMap to add more information for the disabled.
>>> http://wiki.openstreetmap.org/wiki/Disabilities but exactly how one adds
>>> tactile_paving = yes correctly is something I still have to work out.  The
>>> City of Ottawa is currently adding  tactile_paving at many road
>>> junctions and for blind people it is very useful as many junctions now have
>>> slopes rather than curb stones which makes it difficult to know 

[OSM-talk] Publishing bot code. GPL or AGPL?

[Safwat Halaby]

I understand that GPLv3 has a loophole in which someone could modify
your GPL-licensed code, and then run it on a server which offers some
service. Since a service is being sent over the wire, and not the
executable itself, then they can keep their modified code private. AGPL
prevents this loophole.

Does the same logic apply for OSM bots? Would someone using a
personally modified GPL'ed bot not have to publish it? Should I use
AGPL instead if I wish to force any bot user to publish the code?

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Julien Lepiller]

Le 2017-10-17 18:11, Christian Rogel a écrit :

Le 2017 Here 17 à 14:57, Julien Lepiller  a écrit :

Le 2017-10-17 14:07, marc marc a écrit :

Bonjour,
comme je disais la dernière fois :
- il faut corriger l’ambiguïté sur la page wiki (edit de Philippe, je
n'ai pas été vérifié la situation actuelle, peux-être ais-je raté 
l'info

que cela a été fait).


C'était toujours là. J'ai tenté une modif pour clarifier, mais si ça 
ne va

pas, n'hésitez pas à reverter, je ne m'en offusquerai pas. Peut-être
faudrait-il ajouter un paragraphe pour expliquer le coup d'iness et 
fantoir
avant ? J'ai peut-être utilisé un ton un peu trop catégorique dans le 
wiki.



- mettre un commentaire publique sur le changeset rappelant que la
France n'est pas une zone bilingue et que par conséquent il n'y a 
qu'un

seul name, celui repris dans l'usage courant tel que renseigné dans
iness ou fantoir et que les autres versions sont les bienvenue dans 
name:xx

inviter la personne concernée au dialogue ici par exemple.
- si une personne prévenue continue alors on pourra passer au dgw,
idéalement par un membre d'osm-fr pour la légitimité de la 
communauté,

à défaut tout le monde peux le faire.
Mais n'ayant pas eu de retour ni trouvé de commentaire sur les
changeset, je n'ai pour ma part pas encore contacté le dgw, n'ayant 
pas

le détail de qui a prévenu qui.
Cordialement,
Marc



J’ai corrigé la page en Multilingual names en révoquant des
modifications de Philippe (28-05-16), ce qui donne la nouvelle
rédaction suivante

name =* for the default
official name, as defined by the State-runned INSEE or by the
municipal land registry (the cadastre). It may contain a local
language name in bilingual areas, none of them official in France
name:fr =* for the
vernacular French name (needed exclusively off territories of the
French Republic, especially for French variants like Londres for
London  or Munich for
München )

Ce qui me semble important :
Ne pas référer systématiquement le name à la langue française, même si
le nom officiel a, généralement, une graphie traditionnelle française
malaxant les origines linguistiques plurielles (gaulois, ligure et
celtibère inclus)
Ne pas doubler les name par un name:fr sur le territoire de la RF,
car, c’est non seulement un énorme gaspillage d’énergie, mais, une
incitation indirecte à mettre en name autre chose que ce qu’il y a
dans le COG et le cadastre (logiquement, on doit les supprimer si on
en trouve)

Il restera à vérifier si la version française doit être améliorée,
mais, à mon sens, elle était déjà assez claire.


Super ! Finalement c'est bien mieux que ce que j'ai essayé de faire, 
merci :)






Christian R.
___
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] Utilisation du tag 'name' avec les langues régionales

[Christian Rogel]

> Le 2017 Here 17 à 14:57, Julien Lepiller  a écrit :
> 
> Le 2017-10-17 14:07, marc marc a écrit :
>> Bonjour,
>> comme je disais la dernière fois :
>> - il faut corriger l’ambiguïté sur la page wiki (edit de Philippe, je
>> n'ai pas été vérifié la situation actuelle, peux-être ais-je raté l'info
>> que cela a été fait).
> 
> C'était toujours là. J'ai tenté une modif pour clarifier, mais si ça ne va
> pas, n'hésitez pas à reverter, je ne m'en offusquerai pas. Peut-être
> faudrait-il ajouter un paragraphe pour expliquer le coup d'iness et fantoir
> avant ? J'ai peut-être utilisé un ton un peu trop catégorique dans le wiki.
> 
>> - mettre un commentaire publique sur le changeset rappelant que la
>> France n'est pas une zone bilingue et que par conséquent il n'y a qu'un
>> seul name, celui repris dans l'usage courant tel que renseigné dans
>> iness ou fantoir et que les autres versions sont les bienvenue dans name:xx
>> inviter la personne concernée au dialogue ici par exemple.
>> - si une personne prévenue continue alors on pourra passer au dgw,
>> idéalement par un membre d'osm-fr pour la légitimité de la communauté,
>> à défaut tout le monde peux le faire.
>> Mais n'ayant pas eu de retour ni trouvé de commentaire sur les
>> changeset, je n'ai pour ma part pas encore contacté le dgw, n'ayant pas
>> le détail de qui a prévenu qui.
>> Cordialement,
>> Marc


J’ai corrigé la page en Multilingual names en révoquant des modifications de 
Philippe (28-05-16), ce qui donne la nouvelle rédaction suivante 

name =* for the default official 
name, as defined by the State-runned INSEE or by the municipal land registry 
(the cadastre). It may contain a local language name in bilingual areas, none 
of them official in France
name:fr =* for the vernacular 
French name (needed exclusively off territories of the French Republic, 
especially for French variants like Londres for London 
 or Munich for München 
)

Ce qui me semble important :
Ne pas référer systématiquement le name à la langue française, même si le nom 
officiel a, généralement, une graphie traditionnelle française malaxant les 
origines linguistiques plurielles (gaulois, ligure et celtibère inclus)
Ne pas doubler les name par un name:fr sur le territoire de la RF, car, c’est 
non seulement un énorme gaspillage d’énergie, mais, une incitation indirecte à 
mettre en name autre chose que ce qu’il y a dans le COG et le cadastre 
(logiquement, on doit les supprimer si on en trouve)

Il restera à vérifier si la version française doit être améliorée, mais, à mon 
sens, elle était déjà assez claire.



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

[Talk-cl] Ayuda Como mapear esto....

[Danilo Lacoste]

Estimados,

Discutiendo con un colaborador en Temuco me asaltó esta duda, ¿como
mapear este sector?

Tenemos una doble pista de avenida central en Temuco, que al salir de
la ciudad y conectarse  a la ruta 5 debe hacerlo a través de un trébol
de 4 hojas (así lo llamo yo :D). Antes de enfrentarlo el bandejón
central desaparece y aquí en mi opinión debería mantenerse la lógica
de dibujar 2 pistas a pesar que no existe el bandejón durante esos
metros (deben ser unos 500-800 metros quizá)

Aquí hay imágenes recientes, porfavor avanzar unos 200 metros para
observar el tipo de pista y cuando comienza a desaparecer el bandejón.

https://www.mapillary.com/app/?lat=-38.750955=-72.609237=20=hTypOmoAbSCYTMiAFA_New=0.5144342784837512=0.5551724211959315=0=photo



Aquí se puede ver que el colaborador modificó el mapa, dejando sólo
una pista con 4 carriles en vez de 2 pistas con 2 carriles c/u.
http://www.openstreetmap.org/#map=19/-38.75195/-72.60911


La pregunta es, como debe hacerse?
Pregunto pues ahora estoy a punto de incorporar varias relaciones y
que afectan esa ruta y claro la idea es hacerlo de forma correcta
inmediatamente y no complicar a futuros editores.

saludos.

-- 
Danilo Lacoste Z.   dan...@lacosox.org
Ing. Civil en informática
www.lacosox.org

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

Re: [Talk-in] How to get a bot account to upload translated strings for OSM?

[muzirian]

Nice project 

On Tuesday, October 17, 2017, Shrinivasan T  wrote:

> > This is such an awesome project and love how easy it is to translate!
> Such
> > an easy to use mobile interface is a great contribution to localize the
> > world map [1].
>
> Thanks :-)
>
> Join the OSM_Tamil bot and give a try.
>
> >
> > Before getting a bot account, it would be great to demonstrate that the
> > quality of translations sourced by this method is of sufficiently high
> > quality. That would greatly help build a case for an automated upload
> > system.
> >
>
> We are translating Chennai Bus Stop names now.
> Will share the results once they are completed.
>
> Will use name:ta= when syncing with OSM.
>
> Thanks.
>
> --
> Regards,
> T.Shrinivasan
>
>
> My Life with GNU/Linux : http://goinggnu.wordpress.com
> Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com
>
> Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
> http://FreeTamilEbooks.com
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-in
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-cz] SimpleSAMLphp error report

[Petr Vejsada]

Ahoj Majko & All,

hlavně pro ostatní, problém byl v IPV6 konektivitě u Contabo. Komunikace 
probíhá přednostně po IPV6, což ale nešlo a tak vše padalo na timeoutech.

Contabo na problému ještě pracuje, ale poradili mi nastavit natvrdo MAC 
příslušného routeru, což pomohlo a teď IPV6 jde (a doufám, že už půjde stále).

--
Zdraví
Petr

Dne Út 17. října 2017 14:02:29 jsi napsal(a):

> SimpleSAMLphp Error Report
> 
> Message from user:
> 
> snaha o přihlášení na openstreetmap pro nahlášení chyby budovy na RUIAN
> 
> 
> Exception: SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
> Backtrace:
> 0 /var/www/simplesamlphp/www/module.php:180 (N/A)
> Caused by: Exception: Contacting request_token endpoint on the OAuth Provider 
> [statuscode: unknown]: 
> :https://www.openstreetmap.org/oauth/request_token?oauth_callback=http%3A%2F%2Fruian.poloha.net%2Fsimplesaml%2Fmodule.php%2Fauthosm%2Flinkback.php%3Fstateid%3D_c4d26469434846fc65e82538ea99fc56f72bec2a4a_consumer_key=6PzdmV00PZ0mX9SRkbCb4uxoWZyUrCFmpzwOiMev_nonce=6c4d6facfc8efd526b7378182252e53d_signature=k8XL96muA9%2BrlVGhLSIZVNe3TtM%3D_signature_method=HMAC-SHA1_timestamp=1508241509_version=1.0
> Backtrace:
> 7 /var/www/simplesamlphp/modules/oauth/lib/Consumer.php:65 
> (sspmod_oauth_Consumer::getHTTP)
> 6 /var/www/simplesamlphp/modules/oauth/lib/Consumer.php:76 
> (sspmod_oauth_Consumer::getRequestToken)
> 5 /var/www/simplesamlphp/modules/authosm/lib/Auth/Source/OSM.php:72 
> (sspmod_authosm_Auth_Source_OSM::authenticate)
> 4 /var/www/simplesamlphp/lib/SimpleSAML/Auth/Source.php:193 
> (SimpleSAML_Auth_Source::initLogin)
> 3 /var/www/simplesamlphp/lib/SimpleSAML/Auth/Simple.php:141 
> (SimpleSAML_Auth_Simple::login)
> 2 /var/www/simplesamlphp/lib/SimpleSAML/Auth/Simple.php:83 
> (SimpleSAML_Auth_Simple::requireAuth)
> 1 /var/www/simplesamlphp/modules/core/www/as_login.php:33 (require)
> 0 /var/www/simplesamlphp/www/module.php:137 (N/A)
> 
> URL:
> http://ruian.poloha.net/simplesaml/module.php/core/as_login.php
> 
> Host:
> mapserv
> 
> Directory:
> /var/www/simplesamlphp
> 
> Track ID:
> ac280c89a4
> 
> Version: 1.14.8
> 
> Report ID: d16091bf
> 
> Referer: http://ruian.poloha.net/building.php
> 
> 
> 
> This message was sent using SimpleSAMLphp. Visit the SimpleSAMLphp 
> homepage.
> 

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

Re: [Talk-de] Verzeichnis aller Straßennamen in D

[Harald Hartmann]

Hallo Detert,

um es mit den Worten eines anderen Mappers zu sagen ... "mit aller Liebe
zur OSM" würde ich dir bei so einem Vorhaben definitiv eher zu der
Adressdatenbank (DataFactory [1]) der Deutschen Post raten, kostet zwar
ein paar Hunderter, aber dafür musst du dir nichts zusammensuchen etc,
und hast die beste Zuordnung zwischen PLZ Ort Straße Hausnummer

Und wenn du es unbedingt mit OSM machen möchtest, dann sei dir das
"osm_address_db - Adressdaten in der OSM Datenbank" Video [2] der
letzten FOSSGIS ans Herz gelegt (am Ende des Videos gibt es weitere Links)

[1] https://www.deutschepost.de/de/d/deutsche-post-direkt/datafactory.html
[2] https://www.youtube.com/watch?v=ALlEIJlANEA

Viele Grüße,
Harald

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

Re: [Talk-us] hydrology Alaska

[Christoph Hormann]

On Tuesday 17 October 2017, ANT Berezhnyi wrote:
>
> so on the question ...
>
> Is it possible to vectorize the USGS on the OSM if there is no
> Landsat, and everything else in the clouds, or in the snow, or the
> quality is bad ...

There are no parts of the US where there is no better imagery available 
than the 15 year old Landsat Geocover background image in Bing.  Most 
of Alaska is now covered by high resolution images in at least one of 
the available imagery layers (Bing/Mapbox/DG/ESRI).  And where this is 
not the case or images are unsuitable you will be able to find newer 
Landsat or Sentinel-2 images.  If you have troubles finding a suitable 
image for a specific area just ask - someone will likely be able to 
point you to them.  The Russian community has used open data images for 
quite some time in remote areas of the north.

But no image, no matter how suitable it is for the mapping task at hand, 
absolves you from carefully verifying what you map.  Tracing helper 
tools like scanaerial do not do this for you.

Old USGS maps are useful for names and as hints to interpreting imagery 
but should never be used for tracing geometries - they are just too old 
for that in most cases.

And as Ben Discoe pointed out you need to adjust your methods of tracing 
water areas, Something like https://www.openstreetmap.org/way/532622119 
is just not a good geometry representation (lots of nodes but with 
coordinates rounded to an arbitrary pixel grid is just wasteful).

-- 
Christoph Hormann
http://www.imagico.de/

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

[Talk-it] QA per il routing

[Cascafico Giovanni]

Ciao Lista,

ho abbozzato un generatore di grafi stradali a "pezze" per controllare la
navigazione. Prima di dedicarmi agli inevitabili affinamenti, qualcuno può
dare un'occhiata [1], che io non abbia inventato l'acqua calda?

[1] https://www.openstreetmap.org/user/Cascafico/diary/42428
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Verzeichnis aller Straßennamen in D

[Detert Wurps]

Hallo Martin,

ich versuche , in Python eine Art Adressenerkennung innerhalb von Texten 
umzusetzen.
Eine Liste PLZ-Ort habe ich bereits sowie eine Liste mit ~ 96000 Straßennamen.

Allerdings habe ich gelesen, dass es deutlich mehr Straßennamen in Deutschland 
gibt und Du sagst ja ebenfalls, es seien über eine halbe Millionen 
unterschiedlicher - wenn ich die bekommen könnte, wäre das gut für mich.

Wenn ich jetzt noch die Info hätte, welche Straßen überhaupt zu welchem Ort 
gehören können, wäre es sogar noch etwas einfacher...

Mit Openstreetmap als Karte/Geodaten hat das Ganze aber nicht zu tun.

VG,
Detert

-Ursprüngliche Nachricht-
Von: Martin Trautmann [mailto:tr...@gmx.de] 
Gesendet: Dienstag, 17. Oktober 2017 15:02
An: Openstreetmap allgemeines in Deutsch 
Betreff: Re: [Talk-de] Verzeichnis aller Straßennamen in D

On 17-10-17 11:21, Detert Wurps wrote:
> Hallo,
> 
> ich bin ganz neu bei talk-de.
> 
> Ich bin auf der Suche nach einem Verzeichnis (einer Datei, wenn es geht) 
> aller Straßennamen - gerne auch mit zugehörigem Ort (ist aber nicht 
> Bedingung).

Eine entsprechende Liste könnte ich dir geben - Deutschland hat etwa 15 
Millionen Straßen. Davon sind hier 571120 unterschiedliche Straßennamen.

Es gibt unterschiedliche Auswertungen zur Abdeckung der Openstreetmap - da 
kannst du sie dir auch zusammen sammeln.

Was hast du mit solchen Mengen vor?

Schönen Gruß
Martin

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

Re: [Talk-de] Verzeichnis aller Straßennamen in D

[Martin Trautmann]

On 17-10-17 11:21, Detert Wurps wrote:

Hallo,

ich bin ganz neu bei talk-de.

Ich bin auf der Suche nach einem Verzeichnis (einer Datei, wenn es geht) aller 
Straßennamen - gerne auch mit zugehörigem Ort (ist aber nicht Bedingung).


Eine entsprechende Liste könnte ich dir geben - Deutschland hat etwa 15 
Millionen Straßen. Davon sind hier 571120 unterschiedliche Straßennamen.


Es gibt unterschiedliche Auswertungen zur Abdeckung der Openstreetmap - 
da kannst du sie dir auch zusammen sammeln.


Was hast du mit solchen Mengen vor?

Schönen Gruß
Martin

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Julien Lepiller]

Le 2017-10-17 14:07, marc marc a écrit :

Bonjour,

comme je disais la dernière fois :
- il faut corriger l’ambiguïté sur la page wiki (edit de Philippe, je
n'ai pas été vérifié la situation actuelle, peux-être ais-je raté 
l'info

que cela a été fait).


C'était toujours là. J'ai tenté une modif pour clarifier, mais si ça ne 
va

pas, n'hésitez pas à reverter, je ne m'en offusquerai pas. Peut-être
faudrait-il ajouter un paragraphe pour expliquer le coup d'iness et 
fantoir
avant ? J'ai peut-être utilisé un ton un peu trop catégorique dans le 
wiki.



- mettre un commentaire publique sur le changeset rappelant que la
France n'est pas une zone bilingue et que par conséquent il n'y a qu'un
seul name, celui repris dans l'usage courant tel que renseigné dans
iness ou fantoir et que les autres versions sont les bienvenue dans 
name:xx

inviter la personne concernée au dialogue ici par exemple.
- si une personne prévenue continue alors on pourra passer au dgw,
idéalement par un membre d'osm-fr pour la légitimité de la communauté,
à défaut tout le monde peux le faire.
Mais n'ayant pas eu de retour ni trouvé de commentaire sur les
changeset, je n'ai pour ma part pas encore contacté le dgw, n'ayant pas
le détail de qui a prévenu qui.

Cordialement,
Marc
___
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] New OSM Quick-Fix service

[Rory McCann]

On 16/10/17 19:49, Tobias Zwick wrote:

Except that's not true. In Ireland "handball" is Gaelic Handball¹
which is a one-on-one game, not a team sport (which is apparently a
different thing²). There are some sport=handball's tagged in Ireland.
Now the tag is clearly wrong, and we need to figure out something about
that. But if you just change sport=handball to sport=team_handball, then
you've entered incorrect data, based on incorrect assumptions.


Good catch. So, it is no good as an example for that. But no matter, I
think the idea got across anyhow.


The idea that automated edits and tag replacements on a worldwide scale 
are a bad idea and might have edge cases you've never heard about? 



but it is the only documentation we have.


Not really. We have editors, and what they do, map styles and what they
do, programmes like osm2pgsql and what they do. That's a form of
"unwritten documentation".



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

[Talk-it] Sabbioneta progetto Cerchio d'Acqua e richiesta supporto per possibile import

[Giorgio Limonta]

Buongiorno lista, 
vi scrivo per alcuni consigli relativamente ad un potenziale import chevorrei 
attivare. Sto collaborando ad un progetto per la valorizzazioneculturale delle 
mura e degli arginelli d’acqua della città di Sabbioneta (sitoUNESCO), il 
progetto prevede la realizzazione di molti studi e rilievi chedovrebbero 
portare alla raccolta di una molteplicità di informazioni di varianatura 
(percorsi ciclabili, rilievo specie arboree, etc.) che ovviamentesaranno 
condivise attraverso un sito internet 
(http://www.amiciambientesabbioneta.it/cerchiodacqua/)e un geoblog. Ho proposto 
ai membridel progetto di condividere le informazioni raccolte non solo con i 
mezzi web“classici” ma arricchendo anche i canali di condivisione delle 
informazioni delmondo Wikimedia ed in particolare di OpenStreetMap. Nel recente 
passato ho giàavuto esperienze simili ma per altre finalità. Fatta questa 
premessa ho notato che in OSM Sabbioneta èscarsamente mappata e mi piacerebbe 
quantomeno inserire la parte edificatainterna alle mura (ma non solo) per 
ricostruire una base dati sulla quale “agganciare”le diverse informazioni che 
raccoglieremo ma anche banalmente per ricostruireuna cartografia di sfondo 
adeguata per il geoblog. Il mio obiettivo sarebbequello di fare quello che 
Ale_Zena ha già fatto per il comune di Treviglio. PurtroppoSabbioneta come 
molti dei comuni del mantovano non ha ancora un DBTopograficorilasciato da 
Regione Lombardia sotto licenza IODL 2.0 (ne presenta unosemplificato DBTS con 
un dettaglio cartografico di 1:10.000 [1]) perciò pensavodi utilizzare 
l’aerofotogrammetrico che però ovviamente non presenta unalicenza esplicita in 
quanto non realizzato secondo le disposizioni normativesuccessive alla Lr 
12/2005. Da qui le mie domande: 1.   Per l’import posso utilizzare un 
genericoaccount tipo “GiorgioL_import” che potrei utilizzare anche per 
successiviimport o ne devo creare uno specifico per Sabbioneta?; 2.   Visto che 
si tratta di un import di piccolaentità devo creare comunque una pagina ad hoc 
all’interno della wiki di OSM? a.   Ho visto che esistono una serie di moduli 
giàpronti per la richiesta di pubblicazione di materiale cartografico prodotto 
conlicenza diversa da quella di OSM ma si riferisce comunque a materiale 
Opendata,io credo di essere nel caso descritto qua [2] nella wiki di OSM perciò 
michiedevo se ci fosse un modulo da cui partire da inoltrare al comune 
perfarmelo girare firmato. Poi questo modulo lo pubblico nella pagina 
wikidedicata?    Scusate per l’eccessiva lunghezza della mail e vi 
ringrazioanticipatamente per le risposte che vorrete inviarmi    Giorgio    [1] 
http://www.geoportale.regione.lombardia.it/specifiche-tecniche#point3 [2] 
http://wiki.openstreetmap.org/wiki/IT:FAQ#Perch.C3.A9_non_posso_usare_le_mappe_catastali.2C_i_piani_regolatori_o_i_CTR.3F
 

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[marc marc]

Bonjour,

comme je disais la dernière fois :
- il faut corriger l’ambiguïté sur la page wiki (edit de Philippe, je 
n'ai pas été vérifié la situation actuelle, peux-être ais-je raté l'info 
que cela a été fait).
- mettre un commentaire publique sur le changeset rappelant que la 
France n'est pas une zone bilingue et que par conséquent il n'y a qu'un 
seul name, celui repris dans l'usage courant tel que renseigné dans 
iness ou fantoir et que les autres versions sont les bienvenue dans name:xx
inviter la personne concernée au dialogue ici par exemple.
- si une personne prévenue continue alors on pourra passer au dgw, 
idéalement par un membre d'osm-fr pour la légitimité de la communauté,
à défaut tout le monde peux le faire.
Mais n'ayant pas eu de retour ni trouvé de commentaire sur les 
changeset, je n'ai pour ma part pas encore contacté le dgw, n'ayant pas
le détail de qui a prévenu qui.

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

Re: [OSM-talk] New OSM Quick-Fix service

[Frederik Ramm]

Hi,

On 17.10.2017 10:32, Yuri Astrakhan wrote:
> The thing is - we have been discussing hypothetical issues so far, not
> the real ones.

Users have been blocked and edits reverted for indiscriminately applying
JOSM's autofixer to large swaths of data. But those who do that are
usually aware that they are mis-using the feature, which is meant to
support you in mapping an area. The usual workflow is that you open
JOSM, choose an area to edit, and then use available material and
knowledge to improve the map in that area. It is not "some query directs
you to a random area, you open the editor and click the fix button just
as someone else has told you to".

> some hypothetical individual might not pay attention and go
> clicking trigger happy -- in other words we don't trust our users to be
> diligent. 

This is not a faithful argument. You have said, multiple times, that you
consider the diligence we ask of people a waste of time because certain
tasks could just as well be done by the computer. You have written a
tool that will, at least as currently presented, lower the diligence
standard.

> And that's the fundamental problem - we are worried about things that
> might happen, at the expense of ignoring significant number of existing
> data issues.

You are personally responsible for quite a few of these existing data
issues. -- Yes there are many bugs in OSM and there are many tools that
help find and fix them. Most fixes are not "quick", they require manual
intervention, switching on your brain, and usually knowledge of the
place or at the very least knowledge of the culture where the edit
happens. It appears to me that after the myriad of emails that have been
sent to you over the last half year, you still haven't understood that.
Initially I thought you simply needed some time to "get" OSM, but now I
am convinced that you don't really want to understand. You believe that
you are right and everyone else should finally admit that.

Bye
Frederik

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

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

Re: [Talk-GB] Oxford Railway Station

[Dave F]

On 13/10/2017 13:54, Richard Mann wrote:

More correct than it was.


I'm struggling to believe that.

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


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

[Talk-us] hydrology Alaska

[ANT Berezhnyi]

(sorry for my english)

question:

On 2017-10-16 02:33:13 UTC velmyshanovnyi

http://www.hdyc.neis-one.org/?velmyshanovnyi

wrote:

===

so on the question ...

Is it possible to vectorize the USGS on the OSM if there is no Landsat, and
everything else in the clouds, or in the snow, or the quality is bad ...

Hello velmyshanovnyi , There are a number of questions here. One is "is it
possible to vectorize the USGS". Another is "is it a good idea to do so".

I'd suggest that you discuss what is the best source of imagery in this
region with other mappers, such as "imagico" who commented on
https://www.openstreetmap.org/changeset/52947504 . It may be that you need
to use several sources and combine them manually because none of them are
perfect. Also I would suggest asking on the talk-us and talk-ca mailing
lists for advice.

With regard to "is this a good idea" other mappers think it is not. You
need to persuade them that it is. You need to explain what your process is.
Your comment on https://www.openstreetmap.org/changeset/52947504 that says
"Im fixed my soft" suggests that you might be performing some kind of
mechanical edit. If so, you need to follow
https://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy , which requires
you to discuss what you are proposing to do with other mappers before
actually doing it.

Best Regards,

Andy Townsend, on behalf of OSM's Data Working Group.
https://www.openstreetmap.org/user/SomeoneElse

My sample island/hydrology (JOSM+digitalglobe-premium+bing) not import, not
bot :
https://mc.bbbike.org/mc/?lon=-164.973165=60.843461=13=2=digitalglobe-premium=mapnik=hike_bike=ol_osm-no-labels=35

after simplifacation (v2) :
https://www.openstreetmap.org/changeset/52809320#map=16/60.8221/-164.9684=H
(before see v1)


IF:
if there is a need to correct some hydrology somewhere - welcome 


-- 
++ =
++ ANT (Anton Berezhnyi)
++ =
++ E-mail   : velmyshanov...@gmail.com
++ Hangouts : velmyshanov...@gmail.com
++ Telegram : @velmyshanovnyi
++ Skype: velmyshanovnyi
++ Viber: +380939946993 <093%20994%206993>
++ Cell : +380939946993 <093%20994%206993>
++ https://plus.google.com/+ANTBerezhnyi
++ https://profiles.google.com/velmyshanovnyi

++ https://linkedin.com/in/velmyshanovnyi
++ https://facebook.com/velmyshanovnyi 
++ https://twitter.com/velmyshanovnyi 
++ =
++ жNtTя, яК і iTNernЕТ,
++ нAЖалb, ТЕж к0лИСь
++ KіH4аЄтьCя..
++ =
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Vincent Bergeot]

Le 03/10/2017 à 19:34, Christian Rogel a écrit :


Le 2017 Here 3 à 02:06, Philippe Verdy > a écrit :


Tous ces noms basques ont pour la plupart été changés en masse par
http://www.openstreetmap.org/user/izpura/history

(tous les changesets avec le commentiare "euskaraz")

C'est un utilisateur francophone d'après la locale de son editeur. 
Aui a envoyés des milliers de changesets avec un changement de nom.


Cela concerne toutes les communes, tous les villages, toutes les 
rivières, une bonne partie des rues, tous les sommets, bon nombre de 
services publics.
Le tout très rapidement. Il a certainement du utiliser un bot non 
autorisé...


Il fait aussi des modifs en Espagne (et pas qu'au Pays Basque 
espagnol ou en Navarre mais bien au delà…)


Il faut trouver le moyen de le stopper, car, il continue à perturber 
la carte.


J’ai regardé son dernier changement d’appellation (Arbouet-Sussaute > 
Arboti) et j’ai entrepris, non seulement de le rétablir, mais de 
superviser la commune.
J’ai corrigé des noms de voie partagés entre 2 communs et j’ai vu que 
certaines étaient inscrites comme bilingues dans le cadastre.  Chemin 
de X / X Karrika
Conformément à ce que j’ai déjà écrit, je ne les vois pas comme un 
bilinguisme officiel et j’ai mis un « name » et un « name:eu ».


Quelqu’un lui a-t’il écrit ?


Egun On,

j'ai l'impression que cela redémarre sur les admin-centre avec les 2 
noms en français et basque avec "-" pour séparer : exemple : 
http://www.openstreetmap.org/node/1826736640/history  et ici 
http://www.openstreetmap.org/node/1690923675/history (dans ce cas le 
changeset est explicite, "ajout du nom basque au nom français")


Au regard des multiples discussions, je ne sais pas comment les 
contacter, du moins pour le nouveau 
http://www.openstreetmap.org/user/Baxe%20Nafarroa


Pour lui : http://www.openstreetmap.org/node/1690923675/history on 
rentre dans la bataille d'édition je pense ! Je viens de renvoyer un mot 
en proposant de réfléchir plutôt au rendu cartographique qu'au 
changement de contenu du "name".



Bonne journée


--
Vincent Bergeot

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

Re: [Talk-in] How to get a bot account to upload translated strings for OSM?

[Shrinivasan T]

> This is such an awesome project and love how easy it is to translate! Such
> an easy to use mobile interface is a great contribution to localize the
> world map [1].

Thanks :-)

Join the OSM_Tamil bot and give a try.

>
> Before getting a bot account, it would be great to demonstrate that the
> quality of translations sourced by this method is of sufficiently high
> quality. That would greatly help build a case for an automated upload
> system.
>

We are translating Chennai Bus Stop names now.
Will share the results once they are completed.

Will use name:ta= when syncing with OSM.

Thanks.

--
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
http://FreeTamilEbooks.com

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

Re: [Talk-in] How to get a bot account to upload translated strings for OSM?

[Arun Ganesh]

>
> As we can not get the user's OSM credentials as text in telegramBot,
> we need  a bot account to update OSM with  the tamil names to all the
> relevant english names that volunteers have translated.
>
> Is this process is fine?
>
>
This is such an awesome project and love how easy it is to translate! Such
an easy to use mobile interface is a great contribution to localize the
world map [1].

Before getting a bot account, it would be great to demonstrate that the
quality of translations sourced by this method is of sufficiently high
quality. That would greatly help build a case for an automated upload
system.


The name:* tags in OSM are for names in different languages, not for
> translations of names to different languages.


Paul, these are translations and not transliterations[2]. Is that what you
were asking?


[1] https://wiki.openstreetmap.org/wiki/Translation#OpenStreetMap_map_data
[2] https://wiki.openstreetmap.org/wiki/Names#Avoid_transliteration
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Marciapiede alberato

[Max1234Ita]

Ciao,
io comincerei col mappare i filari di alberi: una way per ciascuno, i cui
nodi sono in corrispondenza dei tronchi.  (usando le ortofoto, io di solito
"ipotizzo" il tronco al centro della chioma visibile... ma non è sempre
proprio così, diciamo che non sbagli di molto)

Il tag da usare per queste way è /natural = tree_row/ .

Di solito, le tree_row le interrompo in corrispondenza dei punti in cui la
strada ne incrocia un'altra (sia essa un'altra via oppure un vialetto
d'accesso ad una proprietà. 
In ogni caso non credo che JOSM segnali un errore se il filare incrocia
un'altra way, lo trovo solo brutto da vedere e poco logico (sembra che ci
sia una barriera dove invece non c'è).

Per quanto riguarda il marciapiedi, puoi usare una way parallela alla
strada, segnandola come footway, e/o puoi seguire le direttive del Wiki di
OSM: http://wiki.openstreetmap.org/wiki/Sidewalks

Se l'area adibita a marciapiedi è molto ampia, potrebbe anche starci una way 
chiusa che la comprende tutta, con tag /place=square/ e /name=*/ .
Volendo, puoi anche dare un nome alla footway, anche se replica quello del
place (io però di solito, salvo casi particolari, in caso di
footway-marciapiedi lascio il nome della via sollo sulla way che indica la
strada vera e propria (higway=residential/living_street/service/ecc.)


Ti lascio il link ad un esempio di "lavoro già fatto" (almeno in buona
parte): http://www.openstreetmap.org/#map=17/44.98620/9.00974

Se trovi qualcosa di sbagliato... il colpevole del misfatto con buona
probabilità sono io :p


Spero di esserti stato utile!
Max




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

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

Re: [Talk-it] [Talk-it-cai] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Alfredo Gattai]

Ciao Massimo,

ottimo, c'e' bisogno di molto aiuto in Piemonte perche' il lavoro e' molto.
Ci sono altri che stanno operando in zona Torino ed nel VCO poi ti passo i
loro contatti senza annoiari tutti gli altri nella talk.
Io avevo cominciato a lavorare un po' sulla Provincia di Biella con i dati
rilasciati dalla Provincia prima che la Regione ce li dessi formalmente.
Ottimo anche il discorso sui guidepost, prendi spunto dalla wiki e poi
magari sviluppiamo da li. Probabilmente non e' un buona idea allegarci
anche tutte le foto perche' temo che andremmo ad appesantire il database.
Per quello possiamo usare INFOMONT e poi chi le vuole se le scarica da li.

Alfredo


2017-10-17 10:46 GMT+02:00 Massimo :

> Il 17/10/2017 08:19, Massimiliano Guidi ha scritto:
>
> Il problema pratico è che i nomi propri servono a identificare delle cose.
> Se metti name=Canale dei Genovesi e name=Canale dei Torinesi permetti di
> identificare due percorsi non altrimenti evidenti. Se cominci ad aggiungere
> dei "da qui a lì" su tutti i sentieri circostanti l'informazione importante
> (i nomi veri) viene diluita perché devi cercare in mezzo a enne stringhe
> esteticamente uguali. Allo stesso tempo non aggiungi nulla di utile perché
> il sentiero Carnino-Colle del Pas lo identifico molto prima e molto meglio
> tramite i POI. Se nessuna mappa commerciale indica questi nomi c'è una
> ragione... sarebbe illeggibile. Alla fine la scelta sarà fra generare delle
> mappe piene di scritte ridicole o non visualizzare i nomi, perdendosi però
> quel 5% che sarebbe utile, e nessuna delle due è una buona soluzione.
>
> Ciao
> visto che citi aree locali che entrambi conosciamo le Alpi Liguri,
> provo ad aggiungere qualcosa alla discussione. In quella zona, così come in
> molte altre delle Alpi c'è un'enorme quantità di sentieri soltanto
> nella nostra Alta Valle ci sono circa 500 km di sentieri formalmente
> accatastati  Ho iniziato un lavoro di "razionalizzazione" del Catasto
> Sentieristico insieme al settore della Regione Piemonte che si occupa di
> questo (IPLA)...e appena ho un po' di tempo (a breve) inizierò
> l'aggiornamento OSM sulla base delle indicazioni CAI-wikimedia.
> 
> A livello teorico eviterei di assegnare i vari nomi "toponomici" a tutti i
> sentieri presenti (cioè le singole tratte-way) a meno che non siano degli
> "itinerari"- tipo Giro del Marguareis  o Via Alpina - che a quel punto
> andrebbe in network:rwn    o , come hai citato, situazioni come
> "canali" o "vie" che per la loro forma o natura (+ o - alpinistica) non
> sono accatastati nella Rete dei Senitieri altrimenti se moltilpichiamo
> 500 km per singole way con nomi specifici presi dalla toponomastica locale
> -  diventerbbe veramente un gran pasticcio certo ci sono Sentieri che
> hanno storicamente un nome conosciuto da tutti e allora è giusto che vada
> inserito... ma io tenderei ad inserirlo nella "relation"
> Diverso invece è l'assegnazione del ref, perchè di fatto permette di
> individuare le singole tratte accatastate a livello regionale con
> codificazioni tipo  A04 che si ritrova o sui segni sulle pietre o sulle
> paline verticali presenti sul sentiero quindi un CATASTO reale oltre
> che teorico (CAI).
>
> L'assegnazione del codice rende la mappa molto leggibile, infatti le
> principali mappe commerciali, ad esempio, utilizzano esclusivamente il
> CODICE del CATASTO 
>
> Questa è la base di lavoro del Catasto locale che a breve aggiorneremo su
> OSM (se qualcuno vuole dare una mano è il benvenuto !)
> Il tratto da te citato sarebbe il sentiero A04 (da Pian Ciucchea a Colla
> del Pas ) .
> https://umap.openstreetmap.fr/it/map/cartografia-
> escursionistica-1-5-alpi-liguri_109355#14/44.1628/7.7122
>
> Su quella tratta insiste la tappa R150 della Via Alpina
> http://www.via-alpina.org/it/stage/330
> purtroppo quasi tutto questo settore escursionistico non è ancora
> aggiornato in termini di Relazioni e Itinerari e REf sentieri...
> e quindi ad oggi ci sono informazioni non organiche e a macchia di
> leopardo...
> https://hiking.waymarkedtrails.org/#?map=14!44.1663!7.7181
>
> Un esempio "locale" che avevo iniziato a fare tempo addietro era questo su
> cui - con i vari aggiornamenti intercorsi nel frattempo - imposterò tutto
> il catasto di valle (gli oltre 500 km già accatastati ) :
> Sentiero A26
> https://hiking.waymarkedtrails.org/#route?id=6991952
> Sentiero A36
> https://hiking.waymarkedtrails.org/#route?id=6730399
> Come vedi sul Sentiero A26, ad esempio, insiste anche la Via Alpina. Nello
> specifico la Sezione R153 della Via Alpina Rossa
> https://hiking.waymarkedtrails.org/#route?id=2644202
>
> Last but not Least
> Visto che mi sono occupato della "palinatura" di moltissimi di questi
> sentieri... vorrei aggiornare un po' sperimentale, anche i "guidepost"
> Luoghi di Posa nell'ottica di trattarli (in relazione al sentiero) come
> 

Re: [Talk-in] How to get a bot account to upload translated strings for OSM?

[Shrinivasan T]

>Are you generating strings for the software which runs openstreetmap.org, or 
>translating place names in >OpenStreetMap data? If the latter, you shouldn't 
>upload them. The name:* tags in OSM are for names in >different languages, not 
>for translations of names to different languages.


Later is we want.

Our goal is to display all the street names, village,city names, POI
in Tamil language.

we export the interested strings from OSM.
using a telegram bot, contributors can see a string in english and
types in tamil name.

As we can not get the user's OSM credentials as text in telegramBot,
we need  a bot account to update OSM with  the tamil names to all the
relevant english names that volunteers have translated.

Is this process is fine?

Share your thoughts.





-- 
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
http://FreeTamilEbooks.com

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

[Talk-de] Verzeichnis aller Straßennamen in D

[Detert Wurps]

Hallo,

ich bin ganz neu bei talk-de.

Ich bin auf der Suche nach einem Verzeichnis (einer Datei, wenn es geht) aller 
Straßennamen - gerne auch mit zugehörigem Ort (ist aber nicht Bedingung).

Über Hinweise würde ich mich sehr freuen.

Mit freundlichen Grüßen / With best regards

Detert Wurps

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

Re: [Talk-it] Strada agro silvo pastorale

[demon.box]

liste DOT girarsi AT posteo DOT eu wrote
> La relazione la capirei se vi sono tratti differenti

dipende cosa intendi per differenti, perchè se ti riferisci alle
caratteristiche fisiche della strada (tracktype, surface, smoothness)
ovviamente questi si possono cambiare un sacco di volte lungo una stessa
strada agro silvo pastorale.
ecco perchè, ripeto, ho preferito fare una relazione anzichè impazzire a
copiare gli stessi tags per ogni pezzettino di way con caratteristiche
diverse, inoltre così facendo mi sembra che ne esca un dato molto più chiaro
e pulito.

--enrico





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

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimo]

Il 17/10/2017 10:46, Massimo ha scritto:

Last but not Least
Visto che mi sono occupato della "palinatura" di moltissimi di questi 
sentieri... vorrei aggiornare un po' sperimentale, anche i "guidepost" 
Luoghi di Posa nell'ottica di trattarli (in relazione al sentiero) 
come parte del sentiero  arrivando ad avere nella etichetta oltre 
alle varie informazioni obbligatori e rilevanti anche un riferimento 
ad una fotografia georef della palina. questo avrà un duplice 
scopo : a) fornire informazioni utili e rilevanti per chi vuole 
pianificare un'escursione  b) avere un database reale e aggiornato di 
tutte le paline presenti sul territorio funzionale alla manutenzione - 
riparazione, ecc...

https://www.openstreetmap.org/node/4928595531#map=19/44.21028/8.02325

avevo dimenticato il link sull'ultimo punto in questione


Anche su questo punto la mole di lavoro è ingente  (se qualcuno 
vuole dare una mano è il benvenuto !) 




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

Re: [Talk-it] Strada agro silvo pastorale

[demon.box]

si, all'inizio delle strade agro silvo pastorali che ho mappato io c'è sempre
un cartello e molto spesso anche una sbarra.

ho pensato di mapparle con una apposita relazione per maggior chiarezza
visto che poi spessissimo alcuni tratti di queste a loro volte fanno parte
di relazioni di sentieri CAI.


ciao

--enrico




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

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

Re: [OSM-talk-fr] 3 jours de carto partie à Caen – 13-15 oct.

[Charles MILLET]

Un bref retour sur les 3 jours de TurFu Festival à Caen :

J'ai pas les nombres exacts mais a priori plus de 2000 personnes sont 
passées. En plus des participants aux ateliers OSM, une centaine de 
personnes sont passés découvrir OSM pendant les 3 jours. Concernant les 
participants aux ateliers, environ 60 personnes le vendredi et samedi 
pour l'atelier cartoparti des arbres, deux naturalistes sont intervenus 
pour aider à l'identification des arbres, beaucoup d'étudiants le 
vendredi et une dizaine de personnes sur la thématique déchets du 
dimanche... et pas mal de "badges" ont été délivrés...


Merci beaucoup à Francescu Garoby et David Crochet pour leur aide pour 
accompagner les participants, merci à Vincent Bergeot et à ses contacts 
de francophonelibre.org pour l'accès au Tasking Manager.


Pour le retour d'expérience et la partage je dirais qu'un MapContrib qui 
tourne avec la bonne thématique c'est toujours bien utile pour initier 
les personnes de passage ; le Tasking Manager est un peu surdimensionné 
mais bien utile et pédagogique quand même surtout lorsqu'il est couplé 
avec un atlas papier. Enfin, plus on a d'écrans et d'ordinateurs pour 
faire tourner des outils, mieux c'est. Sinon, coup de chance, l'imagerie 
du Calvados de 2016 avait été ajoutée au fond Ortho IGN avant 
l'événement et on a pu en profiter.


Je me répète un peu mais voilà, le Dôme de Caen est vraiment un lieu 
super adapté pour organiser des événements type cartoparties et les 
acteurs sont de plus en plus convaincus et impliqués dans OpenStreetMap. 
On va d'ailleurs lancer une réflexion sur les Open Badge qui à mon avis 
sont un super outil mais c'est un autre sujet...


Charles MILLET
charlesmil...@free.fr

Le 03/10/2017 à 13:55, Charles MILLET a écrit :

Bonjour,

Je me permets encore d'utiliser la liste pour ce rappel : la 
cartopartie des arbres et la cartopartie « déchets » de la presqu'île 
de Caen sont dans une dizaine de jour.


Bonne journée

Charles MILLET
charlesmil...@free.fr

Le 13/09/2017 à 19:23, Charles MILLET a écrit :

Bonjour,

Le Dôme de Caen organise 3 jours de carto partie :
– 2 jours dédiés à la cartographie des arbres de la presqu'île de 
Caen (vendredi 13 et samedi 14 octobre) ;
– 1 jour pour la cartographie liée aux déchets (point d'apport 
volontaire, poubelle, etc.).


Le principe est entre autres d'utiliser OpenStreetMap comme un 
support de type « état des lieux » pour du dialogue autour de 
l'aménagement.


Ces carto parties sont organisées dans le cadre du Turfu Festival à 
l'invitation de Société Publique Locale d'Aménagement de la 
Presqu’île de Caen et de Suez. Le Turfu Festival est une 
manifestation portée par Le Dôme dans le cadre de la Fête de la 
science et co-organisée par Relais d’sciences et Casus Belli.


Voici les liens :

https://turfu-festival.fr/ateliers/carto-partie-les-arbres-de-la-presquile/ 


https://turfu-festival.fr/living-room/carto-partie/
https://turfu-festival.fr/living-room/carto-partie-environnement-dechets/ 



C'est sur inscription mais c'est relativement souple. N'hésitez pas à 
me contacter si vous avez des questions au sujet de ces carto 
parties. N'hésitez pas à partager, twitter, etc.


C'est la troisième fois que le dernier étage du Dôme (super toit 
terrasse avec une partie abritée) est mis à disposition pour des 
opérations d'initiation à OSM telles qu'une cartopartie et le lieu 
est bien adapté – un tout petit peu éloigné du centre mais puisqu'on 
s'intéresse plus particulièrement à la presqu'île, ce n'est pas très 
grave. La dernière fois j'ai eu le plaisir de croiser quelques 
contributeurs de la communauté Caennaise qui m'ont bien aidé et j'en 
profite pour les remercier et les inviter à nouveau.


Au delà de la carto partie j'invite la communauté à venir découvrir 
le Dôme qui est un lieu excellent à la philosophie très "libre" 
(http://ledome.info/).


PS: Il y a de l'imagerie HD récente en Normandie qui pourrait être 
utile. Je vois si son utilisation est simple et possible dans JOSM 
et/ou iD mais si quelqu'un a une remarque ou un conseil à ce sujet je 
suis preneur (j'ai vu que le sujet était un peu actif sur le talk, il 
faut que je reprenne ça).


Amicalement.




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



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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimo]

Il 17/10/2017 08:19, Massimiliano Guidi ha scritto:
Il problema pratico è che i nomi propri servono a identificare delle 
cose. Se metti name=Canale dei Genovesi e name=Canale dei Torinesi 
permetti di identificare due percorsi non altrimenti evidenti. Se 
cominci ad aggiungere dei "da qui a lì" su tutti i sentieri 
circostanti l'informazione importante (i nomi veri) viene diluita 
perché devi cercare in mezzo a enne stringhe esteticamente uguali. 
Allo stesso tempo non aggiungi nulla di utile perché il sentiero 
Carnino-Colle del Pas lo identifico molto prima e molto meglio tramite 
i POI. Se nessuna mappa commerciale indica questi nomi c'è una 
ragione... sarebbe illeggibile. Alla fine la scelta sarà fra generare 
delle mappe piene di scritte ridicole o non visualizzare i nomi, 
perdendosi però quel 5% che sarebbe utile, e nessuna delle due è una 
buona soluzione.



Ciao
visto che citi aree locali che entrambi conosciamo le Alpi Liguri, 
provo ad aggiungere qualcosa alla discussione. In quella zona, così come 
in molte altre delle Alpi c'è un'enorme quantità di sentieri 
soltanto nella nostra Alta Valle ci sono circa 500 km di sentieri 
formalmente accatastati  Ho iniziato un lavoro di 
"razionalizzazione" del Catasto Sentieristico insieme al settore della 
Regione Piemonte che si occupa di questo (IPLA)...    e appena ho un po' 
di tempo (a breve) inizierò l'aggiornamento OSM sulla base delle 
indicazioni CAI-wikimedia. 
A livello teorico eviterei di assegnare i vari nomi "toponomici" a tutti 
i sentieri presenti (cioè le singole tratte-way) a meno che non siano 
degli "itinerari"- tipo Giro del Marguareis  o Via Alpina - che a quel 
punto andrebbe in network:rwn    o , come hai citato, situazioni 
come "canali" o "vie" che per la loro forma o natura (+ o - alpinistica) 
non sono accatastati nella Rete dei Senitieri altrimenti se 
moltilpichiamo 500 km per singole way con nomi specifici presi dalla 
toponomastica locale -  diventerbbe veramente un gran pasticcio 
certo ci sono Sentieri che hanno storicamente un nome conosciuto da 
tutti e allora è giusto che vada inserito... ma io tenderei ad inserirlo 
nella "relation"
Diverso invece è l'assegnazione del ref, perchè di fatto permette di 
individuare le singole tratte accatastate a livello regionale con 
codificazioni tipo  A04 che si ritrova o sui segni sulle pietre o sulle 
paline verticali presenti sul sentiero quindi un CATASTO reale oltre 
che teorico (CAI).


L'assegnazione del codice rende la mappa molto leggibile, infatti le 
principali mappe commerciali, ad esempio, utilizzano esclusivamente il 
CODICE del CATASTO 


Questa è la base di lavoro del Catasto locale che a breve aggiorneremo 
su OSM (se qualcuno vuole dare una mano è il benvenuto !)
Il tratto da te citato sarebbe il sentiero A04 (da Pian Ciucchea a Colla 
del Pas ) .

https://umap.openstreetmap.fr/it/map/cartografia-escursionistica-1-5-alpi-liguri_109355#14/44.1628/7.7122

Su quella tratta insiste la tappa R150 della Via Alpina
http://www.via-alpina.org/it/stage/330
purtroppo quasi tutto questo settore escursionistico non è ancora 
aggiornato in termini di Relazioni e Itinerari e REf sentieri...
e quindi ad oggi ci sono informazioni non organiche e a macchia di 
leopardo...

https://hiking.waymarkedtrails.org/#?map=14!44.1663!7.7181

Un esempio "locale" che avevo iniziato a fare tempo addietro era questo 
su cui - con i vari aggiornamenti intercorsi nel frattempo - imposterò 
tutto il catasto di valle (gli oltre 500 km già accatastati ) :

Sentiero A26
https://hiking.waymarkedtrails.org/#route?id=6991952
Sentiero A36
https://hiking.waymarkedtrails.org/#route?id=6730399
Come vedi sul Sentiero A26, ad esempio, insiste anche la Via Alpina. 
Nello specifico la Sezione R153 della Via Alpina Rossa

https://hiking.waymarkedtrails.org/#route?id=2644202

Last but not Least
Visto che mi sono occupato della "palinatura" di moltissimi di questi 
sentieri... vorrei aggiornare un po' sperimentale, anche i "guidepost" 
Luoghi di Posa nell'ottica di trattarli (in relazione al sentiero) come 
parte del sentiero  arrivando ad avere nella etichetta oltre alle 
varie informazioni obbligatori e rilevanti anche un riferimento ad una 
fotografia georef della palina. questo avrà un duplice scopo : a) 
fornire informazioni utili e rilevanti per chi vuole pianificare 
un'escursione  b) avere un database reale e aggiornato di tutte le 
paline presenti sul territorio funzionale alla manutenzione - 
riparazione, ecc...


Anche su questo punto la mole di lavoro è ingente  (se qualcuno 
vuole dare una mano è il benvenuto !)


Ciao

attendo feedback


Massimo







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

Re: [Talk-in] How to get a bot account to upload translated strings for OSM?

[Paul Norman]

Are you generating strings for the software which runs 
openstreetmap.org, or translating place names in OpenStreetMap data? If 
the latter, you shouldn't upload them. The name:* tags in OSM are for 
names in different languages, not for translations of names to different 
languages.



On 10/17/2017 1:08 AM, Shrinivasan T wrote:

We are working on a TelegramBOT to translate strings for OSM.

Last saturday, we released and demonstrated a telegram bot  
'osm_tamil' to translate strings for openstrertmaps.org 
 at ilugc meet.



Here is a quick walk through video in Tamil.

https://youtube.com/watch?v=dJkeRKuu1F8 




Source code is here
https://github.com/Dineshkarthik/OSM-Translate-TelegramBot 



Explore this and share your thoughts.


Once the strings got translated by volunteers, hope we can use a bot 
account to upload the works.


How to apply and get a bot account for OSM?

Thanks.


--
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer : 
http://FreeTamilEbooks.com



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


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

[Talk-it] Marciapiede alberato

[Catonano]

Riprovo:

Come si mappa questo marciapiede alberato ?

È un'area ?

https://photos.app.goo.gl/BvrSNLYOS6Bh7ugX2
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Palermo - marciapiedi

[Catonano]

Il 07 ott 2017 2:22 PM, "Irene Saltini"  ha scritto:

Riguardo alla relazione, esistono sia street che associatedStreet, la
seconda mi pare di ricordare sia più utilizzata, ma dovrebbe includere
soltanto gli indirizzi. La prima invece può includere anche altre entità e
io personalmente l’ho usata per includere cestini dei rifiuti, parcheggi
per biciclette, etc.


Grazie Irene

Terrò presente !


Ciao,
Irene.

___
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] New OSM Quick-Fix service

[Yuri Astrakhan]

Polyglot, I don't think there is a substantial **real** problem in JOSM
with the autofixes.  And yes, I have worked with JOSM devs and was
impressed at the speed of response.

The thing is - we have been discussing hypothetical issues so far, not the
real ones.   And hypothetically, allowing a simple way for users to review
one specific change on one object and click save is dangerous,  because
some hypothetical individual might not pay attention and go clicking
trigger happy -- in other words we don't trust our users to be diligent.
And so is **hypothetically** dangerous the JOSM's autofix feature,
especially because in JOSM, unilke the new tool, it is possible to click
"fix" without actually seeing what was changed.  On the other hand, JOSM's
autofix has been around for a long time, thus validating its own existence
by trial rather than by philosophy - or at least showing that for those
cases, the number of errors is so small, they don't surface to a major
community attention.

And that's the fundamental problem - we are worried about things that might
happen, at the expense of ignoring significant number of existing data
issues.  But I think this is fairly normal - after all, we are usually more
comfortable with a well understood existing problem than with a potential
unknown harm.

On Tue, Oct 17, 2017 at 4:13 AM, Jo  wrote:

> If there would be real problems with autofixes in JOSM, it's easy to
> report those as a bugs or enhancement requests. JOSM's issue tracker may be
> antiquated, but it does work and JOSM's developers are very responsive.
>
> If JOSM users who apply these auto fixes would worsen the data, then they
> would get remarks through their changeset messages. I'm convinced that if
> there are real problems on that side, we would already know about them and
> they would be fixed very fast. Most likely by disabling the fix button for
> that particular validator warning.
>
> So if you find actual issues, please report them.
>
> Polyglot
>
> 2017-10-17 9:50 GMT+02:00 Yuri Astrakhan :
>
>> Well, you kind of can fix one with the other - by introducing a better
>> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
>> complex approach would clearly require a separate topic(s) and a
>> substantial dev involvement.
>>
>> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any
>> real data (it shows maps from live servers, but editing shows just a few
>> objects).
>>
>> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:
>>
>>> I get your point, especially regarding the appliance of the JOSM
>>> fix-button as a "by-the-way" fixing.
>>>
>>> Though, you can't fix possible issues with of one tool by introducing
>>> another tool. People will not stop using (that feature of) JOSM. That is
>>> why I think, if you think you detected a problematic issue there in that
>>> editor, it should be discussed in a separate topic.
>>>
>>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>>> > Michael, I can only judge by my own experience adding validation
>>> autofix
>>> > rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
>>> > they were reviewed by one or two JOSM developers and merged, probably
>>> > because they were deemed benign.  I don't know about the other rules,
>>> > but I suspect many of them also went this route.  Should have they been
>>> > discussed more widely? I don't know, but that question is complicated,
>>> > just like "what is a local community?" question. What a few devs may
>>> see
>>> > as benign, others may say needs a discussion, right?
>>> >
>>> > Mass editing is a different matter.  We consider mass editing when one
>>> > person goes out to fix something everywhere in the world.  But when we
>>> > provide a tool that automatically fixes something that you are looking
>>> > at, we don't view it as such.  Or at least we don't view it when it
>>> > happens as part of JOSM, but we do when it happens in my new tool. Of
>>> > course there is an important difference - JOSM doesn't guide you
>>> towards
>>> > those cases.
>>> >
>>> > I think massive "by-the-way" fixing is far worse than the targeted fix
>>> > of a single issue.
>>> >
>>> > When you want to fix a single issue in many places, you become a
>>> subject
>>> > matter expert.  You know all about that change, how it interacts with
>>> > other tags, what to watch out for, how to handle bad values, etc.  For
>>> > example, when fixing wikipedia tags, you would see the types of
>>> mistakes
>>> > people make, wrong prefixes people use, incorrect url encodings, hash
>>> > tags in urls, incorrect multiple values, ... .When you simply click
>>> > "fix" because JOSM validator tells you it can fix it automatically, you
>>> > don't have that knowledge, so it effectively becomes a distributed
>>> > mechanical edit without the "reject" capability.  My tool tries to
>>> > address this - to build domain experts in a narrow 

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Alfredo Gattai]

Guarda, possiamo starne a discutere per anni, tanto ognuno rimarra' della
sua opinione e non c'e' niente di male in questo.
OSM non si deve adeguare a nessuna burocrazia CAI o delle Regione.
Semplicemente i percorsi sono accatastati cosi' e noi liberiamo i dati come
li abbiamo.
Togliere quello che e' stato deciso come nome ufficiale del percorso
perche' ad alcuni non piace non ha molto senso per me, sarebbe una sorta di
vandalismo ed allonaterebbe il CAI (come altre realta') dal mondo OSM.
Le mappe commerciali hanno tutte una lista a pie' pagina con i numeri dei
sentieri, i loro nomi e descrizioni. Sul percorso hanno solo il numero per
ovvie ragioni di clutter ma i nomi e le descizioni ci sono.
I problemi di ricerca che mi elenchi sono tutti facilmente risolvibili con
delle query e mi sembra che qui il CAI una volta tanto sia tutto fuorche'
pigro. Se non c'e' il luogo che cerchi semplicemente non ti uscira' dalla
query sia che il nome sia vuoto sia che contenga valori diversi da quelli
che cerchi.
Non e' che voglio sminuire il tuo punto di vista ma sei l'unico che riporta
questi problemi. Io uso abitualmente diversi strumenti sia web che
applicazioni mobile e trovo che non ci siano problemi di clutter, problemi
di utilizzo derivanti da questo.
Noi le mappe le facciamo estraendo i dati da OSM e non incontriamo nessun
problema a farlo e nessuno dei produttori di mappe che ci ha chiesto aiuto
si e' lamentato quando gli abbiamo detto che potevano scaricarseli da OSM.

Io di mestiere faccio cartografia elettronica e so benissimo quali sono i
problemi di clutter e quanto possa essere laborioso fare la query giusta ma
l'ultima cosa che si fa per ottenere un risultato e' togliere dati dal
database, semmai si fa un'export con il massimo dei dati e poi si ripulisce
per i propri bisogni.

Se ritieni che ci sia un oggettivo problema semantico e vuoi sottoporre la
cosa alla comunita' fai pure, OSM per fortuna e' libero, si autoregola e
rifugge da logiche protezionistiche.

Alfredo







2017-10-17 8:19 GMT+02:00 Massimiliano Guidi :

> Il giorno lun 16 ott 2017 alle ore 23:01 Alfredo Gattai <
> alfredo.gat...@gmail.com> ha scritto:
>
>> Non vedo dove sia controproducente
>>
>
> Beh, nel momento in cui capisci che possa non piacere direi che lo sai
> già... :-)
>
> Ne avevamo già parlato. Come minimo è semanticamente sbagliato e contro le
> "regole" di OSM, una descrizione va in description, non in name. Capisco
> che CAI e Regioni abbiano le loro regole, e capisco l'esigenza di
> inventarsi un nome quando devi scrivere l'indice di un libro, ma questo non
> è il CAI e neanche un libro.
>
> Il problema pratico è che i nomi propri servono a identificare delle cose.
> Se metti name=Canale dei Genovesi e name=Canale dei Torinesi permetti di
> identificare due percorsi non altrimenti evidenti. Se cominci ad aggiungere
> dei "da qui a lì" su tutti i sentieri circostanti l'informazione importante
> (i nomi veri) viene diluita perché devi cercare in mezzo a enne stringhe
> esteticamente uguali. Allo stesso tempo non aggiungi nulla di utile perché
> il sentiero Carnino-Colle del Pas lo identifico molto prima e molto meglio
> tramite i POI. Se nessuna mappa commerciale indica questi nomi c'è una
> ragione... sarebbe illeggibile. Alla fine la scelta sarà fra generare delle
> mappe piene di scritte ridicole o non visualizzare i nomi, perdendosi però
> quel 5% che sarebbe utile, e nessuna delle due è una buona soluzione.
>
> Ma a prescindere da tutto il resto è semplicemente sbagliato
> semanticamente e non so perché OSM debba adeguarsi alla pigrizia
> burocratica del CAI.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Strada agro silvo pastorale

[liste DOT girarsi AT posteo DOT eu]

Il 17/10/2017 08:18, demon.box ha scritto:

Si in effetti pare anche più logico mettere

motor_vehicle=private

soltanto sulla way.

Il dubbio mi nasceva dal fatto che una strada agro silvo pastorale è SEMPRE
ad accesso privato e quindi la limitazione all'accesso l'ho messa sulla
relazione anzichè sulla way ma ripensandoci dopo anche a me non pare
corretto.

Ecco il link:

https://www.openstreetmap.org/relation/4846549

ovviamente rimane ancora da sistemare il tag

motor_vehicle=private

in questione.

Grazie, ciao.

--enrico




Sempre non lo so, nel caso in questione.

Nel caso delle strade forestali trentine, la strada inizia sempre, o 
almeno in teoria, dalla presenza di segnaletica ad inizio/fine strada, 
laddove alla fine si interseca con una strada normale/altro tipo.


La relazione la capirei se vi sono tratti differenti, e ripensandoci nel 
mio caso avrei fatto bene a farlo in alcune strade forestali, ma in 
questo caso vedo ce ne sono, ma non sono del posto, per cui non so dove 
inizia e finisce e se è appositamente segnalata con segnaletica.


Ad ogni modo c'è un preset per Josm per le strade forestali trentine, 
che può essere adattato a questi casi:


http://bit.ly/2goVT2Q



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

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

Re: [OSM-talk] New OSM Quick-Fix service

[Jo]

If there would be real problems with autofixes in JOSM, it's easy to report
those as a bugs or enhancement requests. JOSM's issue tracker may be
antiquated, but it does work and JOSM's developers are very responsive.

If JOSM users who apply these auto fixes would worsen the data, then they
would get remarks through their changeset messages. I'm convinced that if
there are real problems on that side, we would already know about them and
they would be fixed very fast. Most likely by disabling the fix button for
that particular validator warning.

So if you find actual issues, please report them.

Polyglot

2017-10-17 9:50 GMT+02:00 Yuri Astrakhan :

> Well, you kind of can fix one with the other - by introducing a better
> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
> complex approach would clearly require a separate topic(s) and a
> substantial dev involvement.
>
> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any real
> data (it shows maps from live servers, but editing shows just a few
> objects).
>
> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:
>
>> I get your point, especially regarding the appliance of the JOSM
>> fix-button as a "by-the-way" fixing.
>>
>> Though, you can't fix possible issues with of one tool by introducing
>> another tool. People will not stop using (that feature of) JOSM. That is
>> why I think, if you think you detected a problematic issue there in that
>> editor, it should be discussed in a separate topic.
>>
>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>> > Michael, I can only judge by my own experience adding validation autofix
>> > rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
>> > they were reviewed by one or two JOSM developers and merged, probably
>> > because they were deemed benign.  I don't know about the other rules,
>> > but I suspect many of them also went this route.  Should have they been
>> > discussed more widely? I don't know, but that question is complicated,
>> > just like "what is a local community?" question. What a few devs may see
>> > as benign, others may say needs a discussion, right?
>> >
>> > Mass editing is a different matter.  We consider mass editing when one
>> > person goes out to fix something everywhere in the world.  But when we
>> > provide a tool that automatically fixes something that you are looking
>> > at, we don't view it as such.  Or at least we don't view it when it
>> > happens as part of JOSM, but we do when it happens in my new tool. Of
>> > course there is an important difference - JOSM doesn't guide you towards
>> > those cases.
>> >
>> > I think massive "by-the-way" fixing is far worse than the targeted fix
>> > of a single issue.
>> >
>> > When you want to fix a single issue in many places, you become a subject
>> > matter expert.  You know all about that change, how it interacts with
>> > other tags, what to watch out for, how to handle bad values, etc.  For
>> > example, when fixing wikipedia tags, you would see the types of mistakes
>> > people make, wrong prefixes people use, incorrect url encodings, hash
>> > tags in urls, incorrect multiple values, ... .When you simply click
>> > "fix" because JOSM validator tells you it can fix it automatically, you
>> > don't have that knowledge, so it effectively becomes a distributed
>> > mechanical edit without the "reject" capability.  My tool tries to
>> > address this - to build domain experts in a narrow field, and let those
>> > experts review changes one by one. I do not discount the value of local
>> > knowledge, but it is not a panacea - you must be both to make
>> > intelligent choices, and in some cases, the domain knowledge is more
>> > important than the knowledge of a specific locale.
>> >
>> > On Mon, Oct 16, 2017 at 4:00 PM, Michael Reichert
>> > > wrote:
>> >
>> > Hi Yuri,
>> >
>> > Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan:
>> > > Rory, most of those queries were copied from the current JOSM
>> validator
>> > > autofixes.  I don't think they were discussed, but they might
>> have been
>> > > mass applied without much thought by all sorts of editors.
>> >
>> > Could you please give examples for (a) the mass appliance of these
>> rules
>> > and (b) rules which have not been discussed but should have been
>> > discussed?
>> > > There are two ways to use the tool - you can write your own
>> query, run it,
>> > > and fix whatever it is you want to fix. That's the power user
>> mode -
>> > > anything goes, no different from JOSM or Level0. And there is
>> another one -
>> > > where you go to osm wiki, read the instructions, find the task
>> you may want
>> > > to work on, and go at it.   The community reviews wiki content,
>> tags
>> > > different pages with different explanation or warning boxes, etc.
>> The
>> > > 

[Talk-in] How to get a bot account to upload translated strings for OSM?

[Shrinivasan T]

We are working on a TelegramBOT to translate strings for OSM.

Last saturday, we released and demonstrated a telegram bot  'osm_tamil' to
translate strings for openstrertmaps.org at ilugc meet.


Here is a quick walk through video in Tamil.

https://youtube.com/watch?v=dJkeRKuu1F8


Source code is here
 https://github.com/Dineshkarthik/OSM-Translate-TelegramBot

Explore this and share your thoughts.


Once the strings got translated by volunteers, hope we can use a bot
account to upload the works.

How to apply and get a bot account for OSM?

Thanks.


-- 
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
http://FreeTamilEbooks.com
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-in] Fwd: Telegram bot to translate strings for openstreetmaps.org

[Shrinivasan T]

-- Forwarded message --
From: "Shrinivasan T" 
Date: Oct 15, 2017 12:45 AM
Subject: Telegram bot to translate strings for openstreetmaps.org
To: 
Cc:

Yesterday, we released and demonstrated a telegram bot  'osm_tamil' to
translate strings for openstrertmaps.org at ilugc meet.


Here is a quick walk through video

https://youtube.com/watch?v=dJkeRKuu1F8


Source code is here
 https://github.com/Dineshkarthik/OSM-Translate-TelegramBot

Explore this and share your thoughts.

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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Well, you kind of can fix one with the other - by introducing a better tool
and disabling some of the autofixes in JOSM (very easy to do).  A more
complex approach would clearly require a separate topic(s) and a
substantial dev involvement.

P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any real
data (it shows maps from live servers, but editing shows just a few
objects).

On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick  wrote:

> I get your point, especially regarding the appliance of the JOSM
> fix-button as a "by-the-way" fixing.
>
> Though, you can't fix possible issues with of one tool by introducing
> another tool. People will not stop using (that feature of) JOSM. That is
> why I think, if you think you detected a problematic issue there in that
> editor, it should be discussed in a separate topic.
>
> On 17/10/2017 00:57, Yuri Astrakhan wrote:
> > Michael, I can only judge by my own experience adding validation autofix
> > rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
> > they were reviewed by one or two JOSM developers and merged, probably
> > because they were deemed benign.  I don't know about the other rules,
> > but I suspect many of them also went this route.  Should have they been
> > discussed more widely? I don't know, but that question is complicated,
> > just like "what is a local community?" question. What a few devs may see
> > as benign, others may say needs a discussion, right?
> >
> > Mass editing is a different matter.  We consider mass editing when one
> > person goes out to fix something everywhere in the world.  But when we
> > provide a tool that automatically fixes something that you are looking
> > at, we don't view it as such.  Or at least we don't view it when it
> > happens as part of JOSM, but we do when it happens in my new tool. Of
> > course there is an important difference - JOSM doesn't guide you towards
> > those cases.
> >
> > I think massive "by-the-way" fixing is far worse than the targeted fix
> > of a single issue.
> >
> > When you want to fix a single issue in many places, you become a subject
> > matter expert.  You know all about that change, how it interacts with
> > other tags, what to watch out for, how to handle bad values, etc.  For
> > example, when fixing wikipedia tags, you would see the types of mistakes
> > people make, wrong prefixes people use, incorrect url encodings, hash
> > tags in urls, incorrect multiple values, ... .When you simply click
> > "fix" because JOSM validator tells you it can fix it automatically, you
> > don't have that knowledge, so it effectively becomes a distributed
> > mechanical edit without the "reject" capability.  My tool tries to
> > address this - to build domain experts in a narrow field, and let those
> > experts review changes one by one. I do not discount the value of local
> > knowledge, but it is not a panacea - you must be both to make
> > intelligent choices, and in some cases, the domain knowledge is more
> > important than the knowledge of a specific locale.
> >
> > On Mon, Oct 16, 2017 at 4:00 PM, Michael Reichert
> > > wrote:
> >
> > Hi Yuri,
> >
> > Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan:
> > > Rory, most of those queries were copied from the current JOSM
> validator
> > > autofixes.  I don't think they were discussed, but they might have
> been
> > > mass applied without much thought by all sorts of editors.
> >
> > Could you please give examples for (a) the mass appliance of these
> rules
> > and (b) rules which have not been discussed but should have been
> > discussed?
> > > There are two ways to use the tool - you can write your own query,
> run it,
> > > and fix whatever it is you want to fix. That's the power user mode
> -
> > > anything goes, no different from JOSM or Level0. And there is
> another one -
> > > where you go to osm wiki, read the instructions, find the task you
> may want
> > > to work on, and go at it.   The community reviews wiki content,
> tags
> > > different pages with different explanation or warning boxes, etc.
> The
> > > discussion could still be on the forum, or here, or in IRC, 
> >
> > Just for future readers: IRC and Telegram channels are no replacement
> > for a mailing list or a forum with a public readable archive where
> you
> > can look up the discussions years later.
> >
> > Best regards
> >
> > Michael
> >
> >
> >
> > --
> > Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
> (Mailinglisten
> > ausgenommen)
> > I prefer GPG encryption of emails. (does not apply on mailing lists)
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk
> > 

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

> compromise between the two, how about I disable the "embed edit".  If
> the query is executed from a link, without the query editor mode, users
> can only view results.  But in the power mode, the users can still use
> the tool to write a query they need, test and edit things as they need. 
>  So its ok to use it as a power editor (e.g. JOSM or Level0), but not as
> mass contribution.

I like this idea, that also goes into the right direction.
Something like this is what I had in mind when I said the tool should
not lend itself for a purpose it is intended for (mass re-taggings
without prior discussion and consensus).
> In the mean time, I will add the "two person approval required", which
> should alleviate expressed concern.  Should be ready fairly soon.

+1
A reject feature plus a two-person approval feature sounds like a
solution with which noone should have a problem with the tool thereafter.

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

Re: [OSM-talk] New OSM Quick-Fix service

[Andy Townsend]

On 17/10/2017 08:29, Tobias Zwick wrote:


Does the dev API have real (=mirrored) data?


It has whatever data you add to it.  I've used it in the past to 
demonstrate a "different way of mapping something" by copying everything 
from live to dev in a small area and then making the changes in that 
small area.


Best Regards,

Andy


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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

I get your point, especially regarding the appliance of the JOSM
fix-button as a "by-the-way" fixing.

Though, you can't fix possible issues with of one tool by introducing
another tool. People will not stop using (that feature of) JOSM. That is
why I think, if you think you detected a problematic issue there in that
editor, it should be discussed in a separate topic.

On 17/10/2017 00:57, Yuri Astrakhan wrote:
> Michael, I can only judge by my own experience adding validation autofix
> rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
> they were reviewed by one or two JOSM developers and merged, probably
> because they were deemed benign.  I don't know about the other rules,
> but I suspect many of them also went this route.  Should have they been
> discussed more widely? I don't know, but that question is complicated,
> just like "what is a local community?" question. What a few devs may see
> as benign, others may say needs a discussion, right?
> 
> Mass editing is a different matter.  We consider mass editing when one
> person goes out to fix something everywhere in the world.  But when we
> provide a tool that automatically fixes something that you are looking
> at, we don't view it as such.  Or at least we don't view it when it
> happens as part of JOSM, but we do when it happens in my new tool. Of
> course there is an important difference - JOSM doesn't guide you towards
> those cases.
> 
> I think massive "by-the-way" fixing is far worse than the targeted fix
> of a single issue.
> 
> When you want to fix a single issue in many places, you become a subject
> matter expert.  You know all about that change, how it interacts with
> other tags, what to watch out for, how to handle bad values, etc.  For
> example, when fixing wikipedia tags, you would see the types of mistakes
> people make, wrong prefixes people use, incorrect url encodings, hash
> tags in urls, incorrect multiple values, ... .    When you simply click
> "fix" because JOSM validator tells you it can fix it automatically, you
> don't have that knowledge, so it effectively becomes a distributed
> mechanical edit without the "reject" capability.  My tool tries to
> address this - to build domain experts in a narrow field, and let those
> experts review changes one by one. I do not discount the value of local
> knowledge, but it is not a panacea - you must be both to make
> intelligent choices, and in some cases, the domain knowledge is more
> important than the knowledge of a specific locale.
> 
> On Mon, Oct 16, 2017 at 4:00 PM, Michael Reichert
> > wrote:
> 
> Hi Yuri,
> 
> Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan:
> > Rory, most of those queries were copied from the current JOSM validator
> > autofixes.  I don't think they were discussed, but they might have been
> > mass applied without much thought by all sorts of editors.
> 
> Could you please give examples for (a) the mass appliance of these rules
> and (b) rules which have not been discussed but should have been
> discussed?
> > There are two ways to use the tool - you can write your own query, run 
> it,
> > and fix whatever it is you want to fix. That's the power user mode -
> > anything goes, no different from JOSM or Level0. And there is another 
> one -
> > where you go to osm wiki, read the instructions, find the task you may 
> want
> > to work on, and go at it.   The community reviews wiki content, tags
> > different pages with different explanation or warning boxes, etc. The
> > discussion could still be on the forum, or here, or in IRC, 
> 
> Just for future readers: IRC and Telegram channels are no replacement
> for a mailing list or a forum with a public readable archive where you
> can look up the discussions years later.
> 
> Best regards
> 
> Michael
> 
> 
> 
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 
> 
> 
> ___
> 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] New OSM Quick-Fix service

[Tobias Zwick]

>> Anyway, generally, with everyone raising the alarm about this tool, it
>> would be a friendly gesture to either take the tool offline for now or
>> set it to read-only mode
> 
> Or have it run on the dev API.

Does the dev API have real (=mirrored) data?

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

Re: [OSM-talk-fr] Zone naturelle protégée, chemin à accès restreint

[Nicolas Toublanc]

Ok, merci.

2017-10-16 14:55 GMT+02:00 Philippe Verdy :

> On peut aussi mettre access=private pour la deuxième question.
> L'exploitant local décide alors seul ceux qui peuvent y aller. Comparable
> aussi aux allées de service dans les parcs d'attraction qui peuvent
> utiliser les moyens appropriés (tracteurs et autres véhicules si
> nécessaire, ou même camions, par exemple pour un transport d'animaux ou des
> livraisons de matériels/matériaux/nourriture animale ou enlèvements de bois
> coupés et gravas). Cependant access=private interdit normalement aussi les
> visiteurs à pied.
>
> Il devrait aussi y avoir une barrière ou un portail (on en trouve aussi
> dans les zoos et grandes volières.
>
> Si c'est vraiment uniquement pour les piétons, ce devrait être un
> "highway=footway" plutôt que "highway=path", surtout si le sol est préparé
> pour permettre les poussettes d'enfants et la visite pour les personnes à
> mobilité restreinte (y compris en fauteuil, même à assistance électrique).
> Le "footway" élimine alors d'office les véhicules motorisés, motocycles,
> vélos, chevaux, mais pas l'accès des personnes à mobilité restreinte et
> rend aussi implicite foot=yes non nécessaire.
>
> Le 16 octobre 2017 à 12:00, djakk djakk  a écrit :
>
>> Salut, pour ta 2e question je mettrai simplement un access=no avec
>> éventuellement une note= pour expliquer …
>>
>> Le 16 octobre 2017 à 08:22, Nicolas Toublanc  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> J'ai 2 questions relatives aux mapping de chemins piétons;
>>>
>>> *Question 1)*
>>>
>>> Dans une zone naturelle protégée, contenant des chemins pour piétons et
>>> cyclistes, explicitement interdits aux chevaux et véhicules motorisés, mais
>>> accessibles au tracteur de service pour l'entretien.
>>>
>>> En pratique, quand j'y suis allé il n'y avait que des piétons.
>>>
>>> Actuellement, on a les tags:
>>>
>>>- highway: path
>>>- foot: yes
>>>
>>> Sur le wiki (http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Acc
>>> ess-Restrictions#France), je vois qu'un path, en France, est considéré
>>> par défaut comme accessible aux:
>>>
>>>- mobylette
>>>- chevaux
>>>- piétons
>>>- bicyclettes
>>>
>>> Donc dans ce cas, je suppose qu'il faut explicitement ajouter:
>>>
>>>- bicycle: yes
>>>- moped: no
>>>- horse: no
>>>
>>> Ou est-ce même plutôt designated qu'il faut utiliser, au lieu de yes (au
>>> moins pour les piétons) ?
>>>
>>> Dans quel cas doit-on plutôt utiliser highway: footway ?
>>> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway
>>>
>>> *Question 2) *
>>>
>>> Une partie des chemins sont interdits au public, et appelés "Zone de
>>> quiétude", pour protéger la faune.
>>>
>>> Comment indiquer cette restriction d'accès?
>>>
>>>
>>> Merci de votre aide!
>>>

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


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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno lun 16 ott 2017 alle ore 23:01 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> Non vedo dove sia controproducente
>

Beh, nel momento in cui capisci che possa non piacere direi che lo sai
già... :-)

Ne avevamo già parlato. Come minimo è semanticamente sbagliato e contro le
"regole" di OSM, una descrizione va in description, non in name. Capisco
che CAI e Regioni abbiano le loro regole, e capisco l'esigenza di
inventarsi un nome quando devi scrivere l'indice di un libro, ma questo non
è il CAI e neanche un libro.

Il problema pratico è che i nomi propri servono a identificare delle cose.
Se metti name=Canale dei Genovesi e name=Canale dei Torinesi permetti di
identificare due percorsi non altrimenti evidenti. Se cominci ad aggiungere
dei "da qui a lì" su tutti i sentieri circostanti l'informazione importante
(i nomi veri) viene diluita perché devi cercare in mezzo a enne stringhe
esteticamente uguali. Allo stesso tempo non aggiungi nulla di utile perché
il sentiero Carnino-Colle del Pas lo identifico molto prima e molto meglio
tramite i POI. Se nessuna mappa commerciale indica questi nomi c'è una
ragione... sarebbe illeggibile. Alla fine la scelta sarà fra generare delle
mappe piene di scritte ridicole o non visualizzare i nomi, perdendosi però
quel 5% che sarebbe utile, e nessuna delle due è una buona soluzione.

Ma a prescindere da tutto il resto è semplicemente sbagliato semanticamente
e non so perché OSM debba adeguarsi alla pigrizia burocratica del CAI.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Strada agro silvo pastorale

[demon.box]

Si in effetti pare anche più logico mettere

motor_vehicle=private

soltanto sulla way.

Il dubbio mi nasceva dal fatto che una strada agro silvo pastorale è SEMPRE
ad accesso privato e quindi la limitazione all'accesso l'ho messa sulla
relazione anzichè sulla way ma ripensandoci dopo anche a me non pare
corretto.

Ecco il link:

https://www.openstreetmap.org/relation/4846549

ovviamente rimane ancora da sistemare il tag

motor_vehicle=private

in questione.

Grazie, ciao.

--enrico




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

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

Re: [Talk-it] Strada agro silvo pastorale

[simone_girardelli]

Relazione?

A me risulta direttamente sulle way, puoi mettere il link?
Quelle mappate da me sono tag tutti sulle singole way.

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

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