Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[majka]

Podle mého jednoznačně loc_name. Ve chvíli, kdy se to objeví na cedulích
pak přesunout do name

2018-01-18 6:56 GMT+01:00 Jan Dudík :

> Já bych měl jeden související dotaz.
> V naší obci ulice oficiálně jména nemají.
> Ovšem třeba do projektu opravy po mně starosta chtěl, abych tam uvedl
> určité jméno. Jak případně tagovat takováto neoficiální (= nejsou v žádném
> registru) jména?
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Mark Wagner]

On Thu, 18 Jan 2018 06:14:17 +0100
Oleksiy Muzalyev  wrote:

> Good morning,
> 
> I started to experiment with the OSM data [1] on a local computer,
> and I begin to realize how big these data files are. It takes quite a
> while to load into the local database just the data for one country.
> 
> What can I as a map editor do to keep these data files to a
> reasonable size without compromising  data quality? I mean in the
> sense, - take care of the pennies and the pounds will take care of
> themselves?
> 
> I could think of the following three approaches so far:
> 
> - using as short an URL as possible, website=http://somewebsite.com 
> instead of website=http://www.somewebsite.com , three characters
> less; [2]
> 
> - correct phone number ISO format, phone=+12 345 678 90 12 instead of 
> phone=+12 (345) 678 90 12 , two characters less;  [3]
> 
> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with 
> consequent verification of its geometry;
> 
> What else, if anything, could be done?

Honestly, the best thing you can do is not worry about it.  The world
is a big, complicated place.  The three bytes you save from shortening
a URL?  You'd need to repeat it 400 times to fit one extra gas station
on the map.

As an experiment, I tried applying various data-saving
options to a park I've mapped.  I managed to reduce the size from
1240354 bytes to 1218966 bytes for a savings of 1.7% -- savings that
will vanish almost instantly this spring once I resume mapping
seasonal wetlands.

-- 
Mark

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Dudík]

Já bych měl jeden související dotaz.
V naší obci ulice oficiálně jména nemají.
Ovšem třeba do projektu opravy po mně starosta chtěl, abych tam uvedl
určité jméno. Jak případně tagovat takováto neoficiální (= nejsou v žádném
registru) jména?

JAnD

---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195

Dne 18. ledna 2018 1:01 jzvc  napsal(a):

> Dne 17.1.2018 v 14:49 majka napsal(a):
>
>>
>>
>> 2018-01-17 13:49 GMT+01:00 Matej Lieskovský > >:
>>
>>
>> 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
>>
>>
>> Trocha teorie - správně by to snad mělo být podle údajů ČÚZK
>>
>
> To se obavam ze je dost naivni ... vzhledem ke kvalite dat.
>
> Jinak ad nedelitelna mezera, podle me je to zbytecnej udaj navic dost
> casto komplikujici spoustu veci (co si budem rikat, je to mnoha editory
> nesdelitelna informace a o renederu ani nemluve).
>
> Nehlede na to, ze tam tech znaku znamenajicich totez muze byt vicero ...
>
> Jednak samozrejme unicode ... pak taky napriklad  nebo  to se
> nam to komplikuje coz?
>
>
> A ad unicode znaky ... to bych svym zpusobem prenechal "prirode", jelikoz
> a protoze u zdroje to nebude (nejmin po dobu nasich zivotu bude pro
> libovolny podobny data unicode sprosty slovo) a na druhou stranu nema smysl
> ani nekomu branit to pouzivat.
>
> Ostatne, tech znaku ktery v ceskych podminkach maji vyuzitelnost je
> pomerne dost, jen se obavam, ze opet skoncime u toho, ze na klavesnici
> nejsou (na ty ostatne neni ani pomlcka).
>
> BTW: To ze ulice vznika z nejakyho obecne pouzivanyho pojmenovani danyho
> mista je asi celkem beznej zpusob.
>
> > ni-udaju-RUIAN-ISUI-VDP/Ciselniky-ISUI/Nizsi-uzemni-
>> prvky-a-uzemne-evidencni-jednotky.aspx>
>>
>> A teď praxe: vím o změně adresy (nejde o přestěhování ani přejmenování,
>> jen formálně ulice + správná adresa) v letech 2002, 2008 a 2015.
>> Celý ten rozdíl se točí kolem toho, jestli je správně uvedeno "Pražská",
>> "Pražská třída" nebo "Pražská tř." Momentálně je správně to poslední.
>> Musím to znovu zkontrolovat v datech, ale kdysi jsem tam přidávala
>> alt_name, protože s tím vyhledávače měly problémy.
>>
>> A nejlepší jsou "zavedené" ulice v určitých městech, které vůbec
>> neexistovaly. Jako příklad je ulice U Panelárny
>>  v Jindřichově Hradci. Nemovitosti na ní se
>> nacházející používající tuhle adresu totiž (snad až na jedinou výjimku)
>> do katastru Jindřichova Hradce vůbec nepatří, a ten název se užíval co
>> já pamatuji minimálně patnáct let, než byl podle těch informací ČÚZK
>> 11.09.2014 oficiálně zaveden.
>>
>> Asi jsem Ti moc nepomohla, co říkáš?
>>
>> Majka
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Oleksiy Muzalyev]

Good morning,

I started to experiment with the OSM data [1] on a local computer, and I 
begin to realize how big these data files are. It takes quite a while to 
load into the local database just the data for one country.


What can I as a map editor do to keep these data files to a reasonable 
size without compromising  data quality? I mean in the sense, - take 
care of the pennies and the pounds will take care of themselves?


I could think of the following three approaches so far:

- using as short an URL as possible, website=http://somewebsite.com 
instead of website=http://www.somewebsite.com , three characters less; [2]


- correct phone number ISO format, phone=+12 345 678 90 12 instead of 
phone=+12 (345) 678 90 12 , two characters less;  [3]


- deleting unnecessary nodes from a way (Shift-Y in JOSM) with 
consequent verification of its geometry;


What else, if anything, could be done?

[1] https://wiki.openstreetmap.org/wiki/Downloading_data
[2] https://wiki.openstreetmap.org/wiki/Key:website
[3] https://wiki.openstreetmap.org/wiki/Key:phone

With best regards,
Oleksiy
osm: Alex-7

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

Re: [OSM-talk] place=hamlet in cities

[Mike N]

On 1/17/2018 6:53 PM, Dave F wrote:
Have you been in contact with the two contributors to see if they can 
revoke/reupload?
I presume it came from a database. If it's still available it can be 
amended as required.


  At this point it would be much better to just manually fix anything 
that doesn't look right - it will be much more up to date than trying to 
conflate any new data with potentially edited data which could be a mix 
of nodes and areas.


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

Re: [OSM-talk] place=hamlet in cities

[Martin Koppenhoefer]

2018-01-18 0:33 GMT+01:00 Kevin Broderick :

>  I'm leaning towards place=neighbourhood as being more correct than
> place=hamlet, although it clearly leaves room for improvement in the form
> of proper landuse polygons and local knowledge re: names.
>


+1, the examples are very clearly no hamlets.

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[jzvc]

Dne 17.1.2018 v 14:49 majka napsal(a):



2018-01-17 13:49 GMT+01:00 Matej Lieskovský >:


6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně


Trocha teorie - správně by to snad mělo být podle údajů ČÚZK


To se obavam ze je dost naivni ... vzhledem ke kvalite dat.

Jinak ad nedelitelna mezera, podle me je to zbytecnej udaj navic dost 
casto komplikujici spoustu veci (co si budem rikat, je to mnoha editory 
nesdelitelna informace a o renederu ani nemluve).


Nehlede na to, ze tam tech znaku znamenajicich totez muze byt vicero ...

Jednak samozrejme unicode ... pak taky napriklad  nebo  to 
se nam to komplikuje coz?



A ad unicode znaky ... to bych svym zpusobem prenechal "prirode", 
jelikoz a protoze u zdroje to nebude (nejmin po dobu nasich zivotu bude 
pro libovolny podobny data unicode sprosty slovo) a na druhou stranu 
nema smysl ani nekomu branit to pouzivat.


Ostatne, tech znaku ktery v ceskych podminkach maji vyuzitelnost je 
pomerne dost, jen se obavam, ze opet skoncime u toho, ze na klavesnici 
nejsou (na ty ostatne neni ani pomlcka).


BTW: To ze ulice vznika z nejakyho obecne pouzivanyho pojmenovani danyho 
mista je asi celkem beznej zpusob.





A teď praxe: vím o změně adresy (nejde o přestěhování ani přejmenování,
jen formálně ulice + správná adresa) v letech 2002, 2008 a 2015.
Celý ten rozdíl se točí kolem toho, jestli je správně uvedeno "Pražská",
"Pražská třída" nebo "Pražská tř." Momentálně je správně to poslední.
Musím to znovu zkontrolovat v datech, ale kdysi jsem tam přidávala
alt_name, protože s tím vyhledávače měly problémy.

A nejlepší jsou "zavedené" ulice v určitých městech, které vůbec
neexistovaly. Jako příklad je ulice U Panelárny
 v Jindřichově Hradci. Nemovitosti na ní se
nacházející používající tuhle adresu totiž (snad až na jedinou výjimku)
do katastru Jindřichova Hradce vůbec nepatří, a ten název se užíval co
já pamatuji minimálně patnáct let, než byl podle těch informací ČÚZK
11.09.2014 oficiálně zaveden.

Asi jsem Ti moc nepomohla, co říkáš?

Majka


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




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

[talk-au] Vicmap Datasets in OpenStreetMap

[Andrew Harvey]

I've secured the OSMF CC BY 4.0 waiver from DELWP for use of their
Vicmap Datasets in OpenStreetMap. Some of these datasets were already
listed at
https://wiki.openstreetmap.org/wiki/Contributors#Victorian_Government_data,
but now I've updated that section with the waiver details so it's clear
from a licensing point of view this data can be used in OSM.
This covers any of the Vicmap data at
https://www.data.vic.gov.au/data/dataset?sort=score+desc%2C+metadata_modified+desc=vicmap=department-of-environment-land-water-planning
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] place=hamlet in cities

[Dave F]

Have you been in contact with the two contributors to see if they can 
revoke/reupload?
I presume it came from a database. If it's still available it can be 
amended as required.


DaveF

On 17/01/2018 23:33, Kevin Broderick wrote:

In Annapolis, Maryland, for instance:

https://www.openstreetmap.org/node/158283000
https://www.openstreetmap.org/node/157577529
http://www.openstreetmap.org/node/150949243

All of the points for which I've reviewed the history were created ten 
years ago, edited nine years ago, by the same accounts, and have not 
been updated since.


It seems the same issue was brought up on the forum a couple of years 
ago (https://forum.openstreetmap.org/viewtopic.php?id=53057), and the 
suggestion was that landuse polygons were probably most appropriate, 
and place=subdivision was next-best. I don't think I can effectively 
armchair-map landuse in cities, but hamlets in densely populated areas 
clearly don't meet the wiki definition (and, I'd argue, are distinct 
on-the-ground situations; an isolated hamlet in a rural area is very 
different than an urban neighbourhood or subdivision). I'm leaning 
towards place=neighbourhood as being more correct than place=hamlet, 
although it clearly leaves room for improvement in the form of proper 
landuse polygons and local knowledge re: names.


On Wed, Jan 17, 2018 at 4:14 PM, Martin Koppenhoefer 
> wrote:


can you post some examples?


cheers,
Martin




--
Kevin Broderick
k...@kevinbroderick.com 


___
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-ph] intro to Kaart initiative in PH

[Erwin Olario]

Glen, thank you for sharing.

Road surface types, and lanes, is one of the attributes we hope to collect
and add into the the OSM database. The challenge of "how" to collect these,
is another matter altogether. We have limited street-level imagery (and
that's one way of doing that), and in many urban areas, users can use
aerial imagery to distinguish paved and unpaved roads.

/Erwin



On Wed, Jan 17, 2018 at 7:13 PM Glen Scott  wrote:

> Nothing to offer by my own personal experiences
>
> I'm a regular user of GPS for navigation at home (Australia) in urban and
> country environments.  I've noted in OSM (Philippines - specifically N-W
> Pangasinan) two things that are undefined in 99% of roads, but used by the
> routing engine - road surface and speed limit. With 99% of roads undefined
> for surface and speed limit the route chosen by the GPS will be a lottery
> as far as driving experience goes.  I guess the most critical would be the
> ability to chose to avoid unpaved roads?  I've had a number of Garmin GPSs
> and they always assume 80 km/h where the map has no defined limit.  Maybe
> 10+ years ago I had some experiences where the GPS would attempt to take me
> on "short-cuts" over long-unused dirt tracks (in preference to the
> highway!).  I guess this is the potential result of not defining the
> surface at the very least.  Hard to tell the speed limit from satellite
> imagery!
>
> In the urban environment the most common and frustrating errors (Garmin
> maps) would be undefined one-way streets.
>
> My one attempt to navigate in the Philippines on OSM (~2008-2009) led me
> into a military camp and some interested military personnel who directed me
> back out the way I came in!  Gates are important but no always so easy to
> see from space
>
> Cheers
> Glen
>
> On Wed, Jan 17, 2018 at 5:40 PM, Erwin Olario  wrote:
>
>>
>> Thank you for bringing this up, Maning. This is also a concern I've
>> discussed with other mappers in the past, and this doesn't just apply to
>> road navigation, but with other features, as well.
>>
>> The Mapbox data team is a pioneer in this road network initiatives in
>> OSM, and we look up to your team for inspiration. 
>>
>> Our current (in the next few months) interest in PH road network
>> improvement are low-hanging fruits (missing geometries, restrictions,
>> turning lanes, etc), but in due time, we'd like to explore how to further
>> improve road network data from OSM for naviation, etc. PH is only one of
>> the many countries we're working in, so we need a more inclusive
>> understanding of tagging nuances, too.
>>
>> I hope such a discussion can  attract more inputs from the wider
>> community, especially those who've been lurking in the background, who
>> follows the exchanges here, but for reasons known only to them, doesn't
>> engage publicly.
>>
>> /Erwin
>>
>> On Mon, Jan 15, 2018 at 8:35 PM maning sambale <
>> emmanuel.samb...@gmail.com> wrote:
>>
>>> Hi Erwin,
>>>
>>> Thanks for leading this work.  As many of you know, I work in Mapbox
>>> and my primary focus is to make OSM navigable.
>>> I wonder what would be the best approach in the context of driving in
>>> the Philippines.
>>> Would love to share notes and approaches.  One thing I have in mind (I
>>> shared this during the meetup), while every country
>>> has specific nuances tagging, there is a danger of making the tags too
>>> specific as its difficult to create routing engines for each country.
>>>
>>>
>>> On Thu, Jan 11, 2018 at 11:58 AM, Erwin Olario  wrote:
>>> > Happy new year everyone.
>>> >
>>> > In case some of you are wondering about some of my recent changeset
>>> comments
>>> > with the phrase,  "Better PH data with #Kaart", I've recently linked
>>> up with
>>> > Kaart [0], and their initiative to improve OSM data in the Philippines.
>>> >
>>> > One of the things we'd like to tackle is road network improvement,
>>> initially
>>> > in Metro Manila, and later (maybe soon?), expanding to other regions.
>>> >
>>> > Improvements that are intended to be addressed include the following:
>>> > * Adding missing roads
>>> > * Improving road attributes (names, lanes, restrictions, etc.)
>>> > * Correcting road connectivity issues
>>> > * Improving road classification consistency according to OSM
>>> guidelines and
>>> > local convention
>>> > * Correcting road alignment issues
>>> > * Other one-off fixes
>>> >
>>> > Of course, we intend to work closely with the community, and other
>>> > stakeholders, especially at the local level.
>>> >
>>> > We also hope to organize, or lead, activities for developing technical
>>> > skills, and enhancing collaboration, and community mapa-thons.  Think
>>> of
>>> > this as an extension of my earlier MapAmore [1] initiatives.
>>> >
>>> > The tasking for Metro Manila [2] is now up, and is hosted by HOT
>>> Tasking
>>> > Manager instance, and open to all interested contributors.
>>> >
>>> > In tomorrow's 

Re: [Talk-GB] Petrol stations with fixme tag

[Michael Booth]

For the overpass-turbo link on your blog, I suggest you use this one 
instead: https://overpass-turbo.eu/s/uZR - which includes "in UK" in the 
query to limit the search to the UK instead of a normal bbox. The same 
can be done for other countries, councils and towns/cities with areas.


On 17/01/2018 21:52, Rob Nickerson wrote:

Hi all,

I just published the third blog update for the quarterly project to 
map petrol stations. This time focused on the 130 forecourts with a 
fixme tag.


Read more at 
http://www.mappa-mercia.org/2018/01/petrol-stations-with-a-fixme-tag.html


Upcoming topics:

- My experience with the OSM Conflate and Community Validation tool.
- Mapping as ways

As always, happy to have guest content if you are feeling eager to put 
pen to paper :-)


Thanks,
*Rob*


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



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

[OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

[Sébastien Dinot]

Bonsoir,

Ce soir, en voulant résoudre quelques erreurs qu'Osmose m'attribue parce
que je suis le dernier contributeur à avoir modifié les objets en
question, je suis tombé sur la zone suivante :

http://osmose.openstreetmap.fr/fr/map/#item=2060=18=44.664133=-0.848937=1,2,3=T

Comme vous le verrez, Osmose signale que la ville de Lacanau-de-Mios est
inconnue au bataillon. Sur Wikipédia, il est effectivement indiqué que
Lacanau-de-Mios est un quartier de Mios et non une ville :

https://fr.wikipedia.org/wiki/Mios

En outre, sur le site de la ville de Mios, Lacanau-de-Mios est
explicitement indiqué comme étant un quartier de Mios :

http://www.villemios.fr/vivre-a-mios/les-conseils-de-quartier/

J'ai donc contacté le contributeur qui a ajouté ces adresses postales et
il m'a répondu :

1. Qu'il habite là-bas depuis quelques mois (il a eu la courtoisie de ne
   pas l'exprimer ainsi mais il est donc bien mieux placé que moi pour
   savoir quelle est l'adresse postale et donc, comment renseigner
   l'attribut « addr:city »).

2. Il m'a transmis un lien vers Google Street View où on voit clairement
   un panneau de signalisation indiquant l'entrée dans l'agglomération
   de « Lacanau de Mios » :

   https://goo.gl/maps/TEhQwaTkUKN2

Et là, le doute m'envahit. Qu'appelle-t-on une agglomération (zone
urbaine comptant au moins 2000 habitants dont les habitations sont
séparées de moins de 200 m) ? Existe-t-il des agglomérations qui ne sont
pas des villes et des communes ? Il semblerait que oui à la lumière de
cet exemple. Quid des panneaux de signalisation correspondants ? J'en
viendrais presque à oublier Osmose qui, pour le coup, me semble faire
erreur.

Qu'en pensez-vous ? Comment trancher ?

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

Re: [OSM-talk] place=hamlet in cities

[Kevin Broderick]

In Annapolis, Maryland, for instance:

https://www.openstreetmap.org/node/158283000
https://www.openstreetmap.org/node/157577529
http://www.openstreetmap.org/node/150949243

All of the points for which I've reviewed the history were created ten
years ago, edited nine years ago, by the same accounts, and have not been
updated since.

It seems the same issue was brought up on the forum a couple of years ago (
https://forum.openstreetmap.org/viewtopic.php?id=53057), and the suggestion
was that landuse polygons were probably most appropriate, and
place=subdivision was next-best. I don't think I can effectively
armchair-map landuse in cities, but hamlets in densely populated areas
clearly don't meet the wiki definition (and, I'd argue, are distinct
on-the-ground situations; an isolated hamlet in a rural area is very
different than an urban neighbourhood or subdivision). I'm leaning towards
place=neighbourhood as being more correct than place=hamlet, although it
clearly leaves room for improvement in the form of proper landuse polygons
and local knowledge re: names.

On Wed, Jan 17, 2018 at 4:14 PM, Martin Koppenhoefer  wrote:

> can you post some examples?
>
>
> cheers,
> Martin
>



-- 
Kevin Broderick
k...@kevinbroderick.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] place=hamlet in cities

[Mike N]

On 1/17/2018 5:55 PM, Kevin Broderick wrote:
Does anyone see a problem with armchair-mapping these to 
place:neighbourhood? I am not planning to do this in an automated 
fashion, but instead to pick away at it while reviewing areas of 
interest to some of my coworkers, who have noted that an appropriate 
rendering for an isolated hamlet doesn't make a lot of sense in a 
more-populated area.


 This happened quite a bit in the US.  I have been converting the 
hamlet points to area where I could identify a subdivision, and add the 
name if I knew it along with place=neighborhood.


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

Re: [OSM-talk] place=hamlet in cities

[Martin Koppenhoefer]

can you post some examples?


cheers,
Martin 

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

[OSM-talk] place=hamlet in cities

[Kevin Broderick]

It seems like a previous import resulted in a lot of place=hamlet for
smaller localities that clearly don't meet the hamlet definition on the
wiki. Some are mobile home parks (trailer parks); others are housing
developments/apartment complexes, and I think there are probably some that
are more properly subdivisions, but all are parts of larger, populated
areas, not isolated, rural places with populations less than 200.

Does anyone see a problem with armchair-mapping these to
place:neighbourhood? I am not planning to do this in an automated fashion,
but instead to pick away at it while reviewing areas of interest to some of
my coworkers, who have noted that an appropriate rendering for an isolated
hamlet doesn't make a lot of sense in a more-populated area.

Thanks,
Kevin

-- 
Kevin Broderick
k...@kevinbroderick.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] doctoral public defense

[Nicolas Pettiaux]

I'll try to attend.

Thanks for the notice

-- 
*Nicolas Pettiaux* PhD, AESS, EMM - Tel +32 496 24 55 01
Maître-assistant - École supérieure d'informatique - ESI
http://esi-bru.be Haute école Bruxelles-Brabant - HE2B - http://he2b.be
Laboratories of Image, Signal processing & Acoustics - ULB
http://lisa.ulb.ac.be/ *http://EduCode.be - Conférence internationale
sur l'enseignement et le codage, Bozar, Bruxelles, 27-29 août 2018*
*http://EduCode.be - An international conference on teaching and coding,
Bozar, Brussels, 27-29 August 2018*
<>___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Première réunion du bureau de l'OSMF jeudi 18 janvier, 22h françaises

[Vincent Privat]

Merci Séverin pour le message et ton implication :)

Le 17 janvier 2018 à 20:03, Severin Menard  a
écrit :

> a priori l'instance de Mumble utilisée est celle du serveur de l'ONG HOT
> US Inc.
>
>
... pardon ? ça pourra être la première question à poser au board: pourquoi
ne pas mettre en place un serveur opéré par la Fondation et localisé en
dehors des US ?

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

[Talk-GB] Petrol stations with fixme tag

[Rob Nickerson]

Hi all,

I just published the third blog update for the quarterly project to map
petrol stations. This time focused on the 130 forecourts with a fixme tag.

Read more at
http://www.mappa-mercia.org/2018/01/petrol-stations-with-a-fixme-tag.html

Upcoming topics:

- My experience with the OSM Conflate and Community Validation tool.
- Mapping as ways

As always, happy to have guest content if you are feeling eager to put pen
to paper :-)

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

Re: [Talk-cz] opendata Agentura ochrany přírody a krajiny ČR

[Jan Macura]

2018-01-17 22:17 GMT+01:00 Matej Lieskovský :

> Ok, takže to chce jim napsat, zda to nechtějí všechno uvolnit pod CC-0,
> nebo nám alespoň dát plošně výjimku podobnou jako nám dal IPR, ať to
> nemusíme tahat přes WD?
>

Takže jestli si s nimi chceme dopisovat, tak to chce rozdělit na 2 části:
1) památné stromy: slušně je upozornit, že na vlastním webu publikovat data
pod jinou licencí, než na webu jiném nedává smysl
2) zbylé datasety: a) jestli by je nechtěli zveřejnit pod ODbL, protože je
šitá na míru datům a databázím, na rozdíl od CC, která se častěji používá
pro jiné typy děl, protože by to bylo kompatibilní s OSM a dalšími
databázemi, protože tím pořád bude zachována povinnost uvést původ, atd.
atp. nebo b) je prostě požádat o výslovný souhlas, že do OSM to importovat
lze [ref] .

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Dave F]

This a purely an iD problem. It should be down to their core programmers 
to sort it out.
We should be encouraging users, especially newbies, to save frequently. 
Potlatch does this without the problem of numerous changesets.


DaveF

On 17/01/2018 13:26, Michał Brzozowski wrote:
Many new users have a habit of e.g. sending one or few objects per 
changeset, resulting in a dozen or even more changesets per day. 
Obviously this makes them PITA to review quickly in Achavi or whatever 
tool you use.


This habit is probably caused by non-knowledge of how auto-save works 
in iD (which makes the work reasonably secure), as well as just not 
knowing better thus forming their own judgement.


How should we teach about optimal changeset size? This is quite tricky 
- how we would define it?


Can the iD nudge users towards better practice? (Linking to Good 
changeset comments wiki page would be useful as well)


Michał


___
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] How to teach novices about optimal changeset size?

[Tobias Zwick]

This is how StreetComplete does it. Good thing is that the OSM server
automatically closes changesets where nothing was added after one hour,
so one does not need to worry that a changeset gets "stuck" if the user
exits the application without closing the changeset.

On 17/01/2018 18:47, Rory McCann wrote:
> On 17/01/18 15:13, Michał Brzozowski wrote:
>> Certainly not:
>> - one changeset per building, repeated 20 times
> 
> Couldn't this be done with the "upload" vs "new changeset" feature of
> the OSM API? A technical solution. Multiple uploads in a single changeset?
> 
> Users want to save/upload frequently (because computers), so we'll never
> stop them pressing the button often. Maybe iD could keep a changeset
> open and an upload rather than open a new changeset? There would have to
> be an option to "close current changeset and open a new one" (& close
> current changeset), and to word that in a more friendly way for people
> who don't know the terminology.
> 
> I don't think linking to documentation will solve this issue. Too many
> users don't read things like that, no matter how much we'd want them to.
> 
> Yes, I know I'm suggesting a software change without offering a patch.
> 
> 
> ___
> 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-cz] opendata Agentura ochrany přírody a krajiny ČR

[Matej Lieskovský]

Ok, takže to chce jim napsat, zda to nechtějí všechno uvolnit pod CC-0,
nebo nám alespoň dát plošně výjimku podobnou jako nám dal IPR, ať to
nemusíme tahat přes WD?

Matej

2018-01-17 16:37 GMT+01:00 Jan Macura :

> 2018-01-17 9:32 GMT+01:00 Marián Kyral :
>
>> Wikidata jsou nějaká univerzální pračka na špinavá data? Aneb, jak se z
>> CC 4.0 stane CC-0?
>>
>
> Jednoduše tak, že autor dat uvolní nějaký konkrétní dataset pro WD, čímž
> jej otevře pod CC-0, pak se rozhodne zveřejnit na webu větší balík dat,
> zapomene na to, a přilepí tomu hromadně CC-BY. Aneb dotaz měl znít "jak se
> z CC-0 stane CC-BY".
>
> K tomu pro jistotu poznámka, že "CC 4.0" označuje verzi licence (liší se
> navzájem minimálně), zatímco "CC-0" označuje typ licence (liší se navzájem
> zásadně).
>
> H.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matej Lieskovský]

To se mi zase povedlo kopnout do něčeho fajného...

O metafyziku mi v tomto případě opravdu moc nejde -
když končí Vinohradská a začíná Černokostelecká,
tak končí Vinohradská a začíná Černokostelecká.
To mě vážně netrápí.

Taky mi nedělá problém přejmenovat celou ulici,
kdykoliv kdy se její název změní.
Když si všimnu, že to opravdu mám přepsat,
tak to díky systému pojede téměř samo.

alt_name a loc_name se zatím taky nehodlám ani dotknout.

O Římských číslicích můžeme debatovat,
ještě chvíli na ně asi nenarazím.
Možná bych se dokonce přikláněl k tomu,
že ty unicode věci jsou možná i dobře,
ale to je na délší debatu.

Teď ale naprosto reálně chci vědět,
zda se ta ulice má jmenovat "K Jezeru" nebo "K Jezeru",
protože naprosto odmítám možnost,
že to jsou dvě různé ulice.

Výhledově to asi chce na wiki napsat,
jak se máme v takovýchto situacích zachovat.
Pokud například zvládneme udržet správné názvy v relacích,
tak bych měl být schopen dohlížet na nbsp a podobné
minimálně pro celou Prahu.

Shodneme se tedy na tom,
že varianta 4 je bezpečná?
Systém bude jen polo-automatický,
takže pokud narazí na něco divného,
tak nejspíše zase napíšu sem.

@Matěj: Podle ČÚZK žádné díly neexistují a basta! :)

Matej

2018-01-17 18:29 GMT+01:00 Matěj Cepl :

> On 2018-01-17, 14:10 GMT, Jan Martinec wrote:
> > Jinak nejde jen o nbsp, někdo přidává Unicode ekvivalenty na
> > římské číslice v názvech. To je medle ok, ale je to kanonický
> > název, nebo ten má být spíše Ⅱ, nebo II?
>
> To už mi připadne jako kravina. Nezlomitelná mezera má svoje
> výhody, ale Ⅱ mi připadne jako čistý manýrismus.
>
> Matěj
> --
> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> Quod fuimus, estis; quod sumus, vos eritis.
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-GB] Asda petrol station data

[Rob Nickerson]

Hi all,

Thanks for participating in the Asda standalone petrol station data
validation. I have now pulled back the results of your work. Where a fixme
was added it related to existing OSM data (e.g. the name tag or an out of
date operator tag). The one exception was a comment questioning the
telephone number for the Asda Ilkeston store - it having a 01773 number yet
is surrounded on all sides with properties that have an 0115 number. Today
I rang the store and can confirm that the number Asda have in their dataset
is correct.

Given no issues found with Asda's data, I will now add this to OSM.

I have created a page on the wiki:
https://wiki.openstreetmap.org/wiki/Asda_UK_stores

Best regards,
Rob


*Rob*

On 26 December 2017 at 11:04, Rob Nickerson 
wrote:

> Thanks for the feedback. This is now ready for you to validate:
>
> http://audit.osmz.ru/project/Asda-petrol-stations
>
> And noted it is a very small dataset as it's primarily a learning exercise
> for me.
>
> Thanks and Merry Christmas
> Rob
>
> On 22 Dec 2017 11:05 p.m., "Rob Nickerson" 
> wrote:
>
>> Hi all,
>>
>> Following the shell petrol station data I wanted to learn more about the
>> tools that Ilya was using (the conflate script and the community validation
>> website). To do this I have downloaded the Asda petrol station data. This
>> was listed on the OSM United Kingdom wiki page as a source we have
>> permission to use and I have followed this up and checked the permission
>> details.
>>
>> It's only a small dataset but it should still be treated with care. As
>> such I will be using the community validation website but before uploading
>> the data I would like to check the following:
>>
>> 1. Each petrol station has a URL with the store details including opening
>> hours. How should we tag this? Should we use the "website" tag or the
>> "opening_hours:url" tag?
>>
>> 2. For opening hours 6am to 10pm every day of the week, what is the right
>> tag value? Is is "06:00-22:00" or "Mo-Su 06:00-22:00"?
>>
>> Thank you,
>> *Rob*
>>
>> p.s. The timing with the walmart import being discussed on the imports
>> mailing list is purely coincidental.
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Tobias Knerr]

On 17.01.2018 18:47, Rory McCann wrote:
> Users want to save/upload frequently (because computers), so we'll never
> stop them pressing the button often.

But we could give them more than one button.

There's "save", and then there's "upload/commit/publish". The two
actions are distinct, and part of the problem may be that online editors
tend to merge them into a single concept.

I'm also used to saving frequently, but because JOSM cleanly separates
save and upload, my habit doesn't get into the way of grouping my
changes into a cohesive changeset with a fitting description when I'm
finished.

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[Romain MEHUT]

Le 16 janvier 2018 à 12:17, jabali  a écrit :

> Mettre l'adressage sur le bâtiment permet l'identifier facilement  de visu
> sur la carte...
> ...à condition que les voies d'accés privées soient évidemment renseignées.
>
> Mais l'adressage sert aussi au routage et dans ce cas c'est un poil
> différent.
> Si les algos de routage ne "routent" pas sur le privé ça donne ça si la
> configuration du terrain n'est pas favorable.
> https://www.openstreetmap.org/directions?engine=osrm_car;
> route=42.98267%2C-0.09124%3B42.98279%2C-0.09464#map=18/42.98173/-0.09232
> https://www.openstreetmap.org/directions?engine=osrm_car;
> route=42.98931%2C-0.09974%3B42.98896%2C-0.10197#map=19/42.98883/-0.10063
>

Il faut accepter qu'une adresse et un bâtiment sont deux notions
différentes. Dans ton 1er exemple de routage, ce n'est pas le bâtiment
qu'il faut viser mais son point d'accès soit la barrière (qui devrait
porter l'adresse) qui matérialise la distinction entre les espaces publics
et privés.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Bacheche per rispettare la natura

[Martin Koppenhoefer]

sent from a phone

> On 17. Jan 2018, at 18:56, demon.box  wrote:
> 
> ma se il wiki dice che con board_type=notice tourism=information non ci và,
> mi adeguo... ;-)


fai come pensi tu, il wiki è per il caso generico. (d’altro canto, un turista 
che cerca informazioni turistiche e poi trova regole del tipo non lasciare il 
sentiero e portare i rifiuti in dietro, potrebbe rimanere deluso ;-) ).

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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[Romain MEHUT]

Bonsoir,

Je trouve au contraire que c'est le meilleur compromis quand il n'y a
effectivement pas de signalisation en place.

C'est aussi à mon sens plus compréhensible que d'associer par exemple
highway=footway + bicycle=yes.

Romain

Le 17 janvier 2018 à 15:19, Charles MILLET  a écrit :

> Bonjour,
>
> Je sais qu'il y a une discussion en cours concernant spécifiquement les
> pistes cyclables sur les trottoirs et je ne veux pas faire de doublon. Mais
> je voulais avoir votre avis sur une récente modification de la page
> FR:Bicycle avant de contacter le contributeur ou de discuter sur la page.
> Voici la page de modification pour référence : https://wiki.openstreetmap.
> org/w/index.php?title=FR:Bicycle=next=1547110
>
> La modification concerne cette phrase dans la partie Voies piétonnes
> partagées (https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.
> C3.A9tonnes_partag.C3.A9es) :
>
> "En l'absence d'indication de nature de la voie, utiliser l'attribut
> highway =path
>  qui autorise
> cyclistes et piétons à circuler ensemble"
>
> Même si cette approche est assez commode car elle permet d'éviter les
> débats pour savoir si un voie est un footway ou un cycleway, je la trouve
> assez catégorique et je ne sais pas elle fait consensus.
>
> --
> Charles milletcharlesmil...@free.fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Mark Wagner]

On Wed, 17 Jan 2018 14:51:38 +0100
Tobias Zwick  wrote:

> So, what is the optimal changeset size, and why?
> 

For a novice?  One building, or a short stretch of road, or a small
park.  They'll almost always make mistakes, and small changesets let
you suggest better ways of doing things without overwhelming them with
"Square your corners, every object needs a tag, not just a name,
don't use descriptions for unnamed things, 'motorway' means an
interstate, not 'any road you can drive on', schools should be tagged
on the school grounds, not the individual buildings, 'living street' is
almost exclusively a European construct, 'oneway=no' is redundant on
almost all road types, and locally, Bing is the lowest-quality image
option -- use this one instead."

-- 
Mark

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

[OSM-talk-fr] Première réunion du bureau de l'OSMF jeudi 18 janvier, 22h françaises

[Severin Menard]

Bonjour à tous,

Pour ceux qui ne sont pas abonnés à la liste de discussion de la Fondation
OSM (ce qui peut se faire ici :
https://lists.openstreetmap.org/listinfo/osmf-talk), la première réunion de
l'année de son bureau aura lieu demain en ligne à 21h à Londres, donc 22h
en France.

Plus d'infos sur le courriel d'annonce (en anglais) de la liste de
discussion de l'OSMF :
https://lists.openstreetmap.org/pipermail/osmf-talk/2018-January/004999.html

Le programme (riche) de la réunion est le suivant :
https://wiki.osmfoundation.org/wiki/Board/Minutes/2018-01-18#Directed_Editing_Policy
et sauf mention contraire les échanges audio peuvent être suivis
publiquement.

Les contributeurs des communautés OSM francophones sont jusqu'ici peu
actifs sur les discussions et les activités de l'OSMF et sous-représentés
parmi les membres adhérents (et donc votants) alors que ses actions peuvent
avoir des conséquences particulièrement importantes au sein de l'écosystème
(passage de la licence CC-BY SA à ODbL par exemple).

Ceux qui avaient suivi et participé aux échanges ici sur talk-fr suite au
compte-rendu fait par Christian Rogel sur les échanges de la liste de
discussion OSMF lors du temps de l'élection de sièges du bureau entre la
fin novembre et début décembre, j'avais tenu une position de type lanceur
d'alertes de par mon expérience passée au sein de l'ONG américaine HOT US
Inc. Suite à cela, après des années pendant lesquelles ma contribution aux
travaux de l'OSMF s'est bornée à voter ou vérifier (une fois) le résultat
des élections, je pense qu'il est important de consacrer un peu de mon
temps libre dans les groupes de travail de la fondation et/ou la traduction
des documents et du wiki de l'OSMF pour permettre aux peu ou non
anglophones de participer à sa gouvernance. J'encourage évidemment beaucoup
d'autres francophones à faire de même.

Concernant la réunion de demain, cela n'est pas précisé dans le courriel
d'annonce de l'OSMF, mais a priori l'instance de Mumble utilisée est celle
du serveur de l'ONG HOT US Inc. dont le paramétrage et l'utilisation est
expliquée dans le wiki OSM : https://wiki.openstreetmap.org/wiki/FR:Mumble.

Mumble utilise un client sur ordi ou smartphone pour lesquelles
l'application conseillée est
https://play.google.com/store/apps/details?id=com.morlunk.mumbleclient.free
(paramétrages et utilisation sont expliqués dans la version EN du wiki sur
Mumble https://wiki.openstreetmap.org/wiki/Mumble que je vais essayer de
traduire prochainement).

D'expérience, la première fois, mieux vaut ne pas s'y prendre à la dernière
minute pour installer et configurer Mumble/Plumble quand ils ne nous sont
pas encore familiers.

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

Re: [Talk-cl] Mejoras a la red de carreteras en Chile

[Danilo Lacoste]

eso sería genial.

- estoy completamente de acuerdo que los cambios no deben ejecutarse
automáticamente, si no, como propones, que sean supervisados siempre por
algún usuario.  Aunque sea solo autorizar cambios triviales.

- una buena idea sería diseñar alguna opción para revertir un cambio
masivo. ( por ejemplo si existe un error, revertirlo facilmente con un
boton )

Tengo algo de tiempo para ayudar, lo ideal sería dejar la herramienta desde
el portal web de osm chile. no?

saludos.

2018-01-17 10:40 GMT-03:00 Álvaro Monares G. :

> Que tal, la otra vez hice un bot para cambiar nombres bastante simple.
> Estaba pensando y tal vez inicialmente podría "sugerir" cambios, hacemos
> que se ejecute cada cierto tiempo e identifique ciertas situaciones (Se me
> ocurre)
> 1.- Cambio de abreviaciones.
> 2.- Cambio de nombre de calles sobre una misma línea.
> 3.- Revisión de ubicación de paraderos en base a otras fuentes.
> 4.- Revisión de nombre de las calles versus nodos cercanos.
> Entonces en la interfaz web, lo muestra y colaborativamente vamos
> aceptando los
> cambios, de esa forma hay un humano revisando la corrección. Todas esas
> correcciones,
> deberían generar un changeset asociado al usuario osm de quien lo hizo y
> con un tag
> que lo hizo el bot.
>
> Quedo atento a comentarios, saludos
> Álvaro Monares G.
>
>
> El 16/01/18 a las 22:54, Danilo Lacoste escribió:
>
> Exacto a eso me refiero.
>
> Puede que sea fácil, pero no se ha hecho. y es muy útil. ( me da la
> impresión)
>
> saludos.
>
>
> 2018-01-16 22:22 GMT-03:00 Julio Costa Zambelli <
> julio.co...@openstreetmap.cl>:
>
>> Hola Danilo,
>>
>> ¿Te refieres a "errores" recurrentes del tipo "Psje. X" en lugar de
>> "Pasaje" o "Av. X" en lugar de "Avenida X"?
>>
>> Entiendo que ya existen bots que pueden hacer esto (yo no los he usado),
>> y solo habría que ejecutarlos de acuerdo con ciertas convenciones.
>>
>> Saludos,
>>
>> Julio Costa Zambelli
>> Fundación OpenStreetMap Chile
>>
>> julio.co...@openstreetmap.cl
>>
>> https://www.openstreetmap.cl/
>> Cel: +56(9)89981083 <09%208998%201083>
>>
>> 2018-01-16 21:21 GMT-03:00 Danilo Lacoste :
>>
>>> Estimados,
>>>
>>> una buena herramienta que creo nos hace falta en Chile es un "boot
>>> chileno" que nos notifique de todas esas fallas en forma automática. y
>>> permita la edición masiva semanal de estandarización. (por ejemplo
>>> corrección de nombres, chequeo de calles, etc).
>>>
>>> entiendo que hay unos boot generales, pero este boot Chileno se
>>> centraría en los puntos especificos de Chile.
>>>
>>> saludos.
>>>
>>> 2018-01-16 20:11 GMT-03:00 Julio Costa Zambelli <
>>> julio.co...@openstreetmap.cl>:
>>>
 Hola Andrew,

 En general te diría que el mapa está bastante bien en buena parte del
 país, aunque obviamente hay muchos lugares donde nos falta numeración,
 edificios, restricciones de giro, etc. (lo que más toma tiempo en todas
 partes del mundo).

 ¿Han pensado en implementar herramientas para ayudar a los mapeadores
 locales? Por ejemplo, hace poco se estuvo hablando (no recuerdo si en
 listas locales o regionales) sobre formas de "limpiar" las trazas GPS que
 ya están en los servidores de OSM, y se llego a la conclusión de que la
 única forma es bajar todas tus trazas, "limpiarlas" localmente y volver a
 subirlas sin el "ruido". Lo que es bastante difícil actualmente, no hay
 herramientas para descargar todas tus trazas de una sola vez y la mayoría
 de los editores locales tienen problemas para manejar cientos o miles de
 trazas simultáneamente.

 Creo que una solicitud general (y seguramente también común) es que no
 hagan ediciones masivas (clasificación, alineación, etc.) sin consultar con
 las personas que mapean en esos sectores.

 Saludos,

 Julio Costa Zambelli
 Fundación OpenStreetMap Chile

 julio.co...@openstreetmap.cl

 https://www.openstreetmap.cl/
 Cel: +56(9)89981083 <09%208998%201083>

 2018-01-13 19:34 GMT-03:00 Andrew Wiseman :

> Hola,
>
> Mi nombre es Andrew Wiseman, trabajo para el equipo de Apple Maps.
> Estamos interesados en ayudando a mejorar la red de vías de circulación en
> Chile en OSM: cosas como añadiendo calles que faltan, asegurarse que vías
> estan conectadas y clasificaciones estén consistentes, mejorando 
> alineación
> con trazas de GPS, y otros problemas similares.
>
> Tenemos una página de Github para este proyecto:
> https://github.com/osmlab/appledata/issues/35
>
> ¿Tienen ustendes sugerencias de zonas que necesitan mejoras o tipos de
> problemas que son frecuentes?
>
> Muchas gracias,
>
> Andrew
>
> Apple, Inc.
>
>
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 <+1%20202-270-4464>
> | andrew_wise...@apple.com
>
>
> 

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-17, 14:10 GMT, Jan Martinec wrote:
> Jinak nejde jen o nbsp, někdo přidává Unicode ekvivalenty na 
> římské číslice v názvech. To je medle ok, ale je to kanonický 
> název, nebo ten má být spíše Ⅱ, nebo II?

To už mi připadne jako kravina. Nezlomitelná mezera má svoje 
výhody, ale Ⅱ mi připadne jako čistý manýrismus.

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Quod fuimus, estis; quod sumus, vos eritis.


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

Re: [Talk-it] Bacheche per rispettare la natura

[demon.box]

cascafico wrote
> Io sono per il
> information=board
> board_type=notice

certo, diciamo che in questo caso specifico la cosa curiosa è che forse
tourism=information ci potrebbe stare comunque visto che quegli
"avvertimenti" sono rivolti proprio ai turisti

ma se il wiki dice che con board_type=notice tourism=information non ci và,
mi adeguo... ;-)

--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] Automatically generated changeset discussion comments by OSMCha

[Rory McCann]

On 17/01/18 09:28, Marco wrote:
2) I've always been using the "changesets w/comments" line of the HDYC 
page to double check suspicious mappers.


Have you considered filtering out changesets with comments and
`review_requested=yes`? IMO if someone requests a review, they *want* a
comment, even if it's "Yes I looked over this and it looke fine". They
are asking for another opinion. Those changesets have a comment, but are
not problematic.

Looking for changesets with review_requested=yes and *no* comments is a
good way to find things that should be investigated.

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Rory McCann]

On 17/01/18 15:13, Michał Brzozowski wrote:

Certainly not:
- one changeset per building, repeated 20 times


Couldn't this be done with the "upload" vs "new changeset" feature of
the OSM API? A technical solution. Multiple uploads in a single changeset?

Users want to save/upload frequently (because computers), so we'll never
stop them pressing the button often. Maybe iD could keep a changeset
open and an upload rather than open a new changeset? There would have to
be an option to "close current changeset and open a new one" (& close
current changeset), and to word that in a more friendly way for people
who don't know the terminology.

I don't think linking to documentation will solve this issue. Too many
users don't read things like that, no matter how much we'd want them to.

Yes, I know I'm suggesting a software change without offering a patch.


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

Re: [OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

[marc marc]

Je pense que n'était pas spécifique aux vélo (et même quasi sans 
importance vu le faible nombre de vélo >20km/h), je pense que la limite 
de vitesse fait mieux d'être traité par un lien vers une page sur le 
sujet. sinon on finit par parler de tout partout.

Sur le fond, il y a des valeurs par défaut tant sur le wiki que dans osm 
mais à ma connaissance, aucun logiciel ne les utilise vu le manque de 
formalisme dans ces infos (il y a une discussion sur la ml tagging,
en ultra résumé, nombreux sont ceux qui trouverait cela utile mais 
personne ne travaille sur la proposition).
par conséquent, pas trop le choix pour le moment que de dupliquer le 
maxspeed ou espérer que le logiciel que tu utilises à une base (dont on 
ignore souvent tout) de correspondance à jour pour le pays.

Le 17. 01. 18 à 16:49, althio a écrit :
> Bonjour Charles,
> 
> Les valeurs par défaut sont explicites dans la relation suivante :
> https://www.openstreetmap.org/relation/934933
> 
> Cela est documenté dans la page
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France
> 
> Peut-être que cela répond partiellement à ta question.
> 
> 2018-01-17 14:54 GMT+01:00 Charles MILLET :
>> Un contributeur a précisé l'information suivante dans la page du Wiki
>> FR:Bicycle
>>
>> "Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 n'est pas
>> nécessaire car valeur par défaut en France"
>>
>> De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne pas
>> se basé sur les spécificités locales pour considérer des valeurs implicites
>> de cette importance. Mais je voulais avoir vos avis avant d'en parler dans
>> la partie discussion ou directement avec le contributeur. Bon je pense que
>> le sujet a déjà du être beaucoup débattu mais comme je n'ai pas trouvé de
>> référence claire, ça pourra faire l'objet d'un rappel :)
>>
>> --
>> Charles MILLET
>> charlesmil...@free.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
> 

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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[marc marc]

Bonsoir,

Le 17. 01. 18 à 15:19, Charles MILLET a écrit :
> éviter les débats pour savoir si un voie est un footway ou un cycleway 
ce serrait pourtant facile en se basant :
sur la largeur : trop étroit pour un véhicule -> path
sur les panneaux
footway
https://wiki.openstreetmap.org/wiki/File:Path-footdesignated.jpg
cycleway
https://wiki.openstreetmap.org/wiki/File:Path-bicycledesignated.jpg
et donc sans panneau ou vélo+piéton-> path

> je ne sais pas elle fait consensus.

Hélas non.
https://wiki.openstreetmap.org/wiki/FR:Path_controversy
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] How to teach novices about optimal changeset size?

[john whelan]

A lot of new mappers come through HOT and one problem I see is the same
building mapped twice.  The HOT tile system releases the lock after two
hours on the tile.  If mappers uploaded every fifteen minutes there would
be fewer double mappings.

An optimal change set size is difficult to define in simple terms.

Cheerio John

On 17 Jan 2018 10:17 am, "Michał Brzozowski"  wrote:

> Certainly I am not intending to change the community and require every
> mapper to comply. If you're an experienced mapper, you're fine.
>
> I mean new users, who are not yet integrated with the community. Their
> work should be checked thoroughly (in Achavi, osmcha...). All novices make
> mistakes, after all. Better to give them good habits. By extension, smaller
> number of changeset will lead to less recycling of same changeset comments.
>
> I made this thread because I found it difficult to convey what is best
> practice in short form in changeset comments.
>
> Maybe I should simplify things when explaining to them? No need to tell
> all the conventions, just what is a good start - but hoping it won't
> backfire ;)
>
> 17.01.2018 3:35 PM "Imre Samu"  napisał(a):
>
> >  one changeset per building, repeated 20 times
>
> my typical use case:   House numbering on the street:  push the numbers &
> forget & go to the next house( fast feedback loop vs. Delayed
> gratification  )
> - sometimes the mobil app is crashing, and I don't want to go back 100m to
> re-enter - the last 5-10 numbers
>
>
> > Obviously this makes them PITA to review quickly in Achavi or whatever
> tool you use.
>
> imho: it is easier to group the changeset on the reviewer side :  by
> user + by hour   ( group by user, hour )   than change the community.
>
> Imre
>
>
>
>
>
> 2018-01-17 15:13 GMT+01:00 Michał Brzozowski :
>
>> Certainly not:
>> - one changeset per building, repeated 20 times
>> - one changeset for 3 POIs that are 1000 km apart in different countries
>>
>> These are real world examples. In the latter Achavi can often refuse to
>> run.
>>
>> That's also why I asked ;-) It's not that easy to formulate the answer
>> what is reasonable to include in a changeset.
>>
>> Michał
>>
>> 17.01.2018 2:54 PM "Tobias Zwick"  napisał(a):
>>
>>> So, what is the optimal changeset size, and why?
>>>
>>> Tobias
>>>
>>> On 17/01/2018 14:26, Michał Brzozowski wrote:
>>> > Many new users have a habit of e.g. sending one or few objects per
>>> > changeset, resulting in a dozen or even more changesets per day.
>>> > Obviously this makes them PITA to review quickly in Achavi or whatever
>>> > tool you use.
>>> >
>>> > This habit is probably caused by non-knowledge of how auto-save works
>>> in
>>> > iD (which makes the work reasonably secure), as well as just not
>>> knowing
>>> > better thus forming their own judgement.
>>> >
>>> > How should we teach about optimal changeset size? This is quite tricky
>>> -
>>> > how we would define it?
>>> >
>>> > Can the iD nudge users towards better practice? (Linking to Good
>>> > changeset comments wiki page would be useful as well)
>>> >
>>> > Michał
>>> >
>>> >
>>> > ___
>>> > 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
>>
>>
>
>
> ___
> 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-it] Bacheche per rispettare la natura

[Cascafico Giovanni]

Io sono per il
informatio=board
board_type=notice
poi, per non perdere l'info specifica, puoi sempre mettere qualcosa in
description (che mi sempra sia proposta di default dal relativo preset JOSM)

2018-01-17 16:43 GMT+01:00 demon.box :

> quindi anche semplicemente
>
> information=board
> board_type=notice
>
> potrebbe andare?
>
> --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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Wiklund Johan]

I would think that similar map changes (for example, only buildings) in a 
contiguous geographical region would be an «optimal» mapping style for easy 
reviewing. It could be a “tip” in the iD tutorial.


From: Michał Brzozowski [mailto:www.ha...@gmail.com]
Sent: onsdag 17. januar 2018 16.14
To: Imre Samu ; talk@openstreetmap.org
Subject: Re: [OSM-talk] How to teach novices about optimal changeset size?

Certainly I am not intending to change the community and require every mapper 
to comply. If you're an experienced mapper, you're fine.

I mean new users, who are not yet integrated with the community. Their work 
should be checked thoroughly (in Achavi, osmcha...). All novices make mistakes, 
after all. Better to give them good habits. By extension, smaller number of 
changeset will lead to less recycling of same changeset comments.

I made this thread because I found it difficult to convey what is best practice 
in short form in changeset comments.

Maybe I should simplify things when explaining to them? No need to tell all the 
conventions, just what is a good start - but hoping it won't backfire ;)

17.01.2018 3:35 PM "Imre Samu" 
> napisał(a):
>  one changeset per building, repeated 20 times
my typical use case:   House numbering on the street:  push the numbers & 
forget & go to the next house( fast feedback loop vs. Delayed gratification 
 )
- sometimes the mobil app is crashing, and I don't want to go back 100m to 
re-enter - the last 5-10 numbers

> Obviously this makes them PITA to review quickly in Achavi or whatever tool 
> you use.

imho: it is easier to group the changeset on the reviewer side :  by user + by 
hour   ( group by user, hour )   than change the community.

Imre




2018-01-17 15:13 GMT+01:00 Michał Brzozowski 
>:
Certainly not:
- one changeset per building, repeated 20 times
- one changeset for 3 POIs that are 1000 km apart in different countries

These are real world examples. In the latter Achavi can often refuse to run.

That's also why I asked ;-) It's not that easy to formulate the answer what is 
reasonable to include in a changeset.

Michał

17.01.2018 2:54 PM "Tobias Zwick" 
> napisał(a):
So, what is the optimal changeset size, and why?

Tobias

On 17/01/2018 14:26, Michał Brzozowski wrote:
> Many new users have a habit of e.g. sending one or few objects per
> changeset, resulting in a dozen or even more changesets per day.
> Obviously this makes them PITA to review quickly in Achavi or whatever
> tool you use.
>
> This habit is probably caused by non-knowledge of how auto-save works in
> iD (which makes the work reasonably secure), as well as just not knowing
> better thus forming their own judgement.
>
> How should we teach about optimal changeset size? This is quite tricky -
> how we would define it?
>
> Can the iD nudge users towards better practice? (Linking to Good
> changeset comments wiki page would be useful as well)
>
> Michał
>
>
> ___
> 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


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

Re: [OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

[althio]

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET :
> Un contributeur a précisé l'information suivante dans la page du Wiki
> FR:Bicycle
>
> "Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 n'est pas
> nécessaire car valeur par défaut en France"
>
> De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne pas
> se basé sur les spécificités locales pour considérer des valeurs implicites
> de cette importance. Mais je voulais avoir vos avis avant d'en parler dans
> la partie discussion ou directement avec le contributeur. Bon je pense que
> le sujet a déjà du être beaucoup débattu mais comme je n'ai pas trouvé de
> référence claire, ça pourra faire l'objet d'un rappel :)
>
> --
> Charles MILLET
> charlesmil...@free.fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [Talk-it] Bacheche per rispettare la natura

[demon.box]

quindi anche semplicemente

information=board
board_type=notice

potrebbe andare?

--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] [OSM-talk-fr-bzh] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

[Philippe Verdy]

Le 16 janvier 2018 à 15:25, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> > Le 16 janv. 2018 à 11:47, Rpnpif  a écrit :
> >
> > Le 15 janvier 2018, Philippe Verdy a écrit :
> >> Le français est en fait une langue très récente créée de toute pièce
> (une
> >> des plus récentes en Europe, si on met de côté la création du
> >> "serbo-croate" chapeau sur le modèle du français, aujourd'hui enterré,
> ou
> >> la création encore plus récente du bosno-serbe, du monténégrin et du
> >> bosniaque). Ce qu'on appelle "moyen français" ou "ancien français" est
> un
> >> abus de langage, alors que c'est en fait différentes langues de France
> >> qu'on a ensuite tenté de ridiculiser et faire oublier leur histoire en
> en
> >> faisant des "dialectes" du français alors que le "français" n'est qu'un
> >> dialecte inventé pour s'imposer contre ces langues.
> >
> > Merci Philippe de cette précision rarement lue mais qui relativise
> > beaucoup de choses.
> I
> On a dit, souvent à tort, qu’une langue est un dialecte qui a réussi,
> parce qu’il a eu une armée, mais, ce qu’on appelle dialecte ou patois peut
> faire partie d’une langue (berrichon, bourguignon, lorrain,
> saintongeais...) selon l’Unesco.
> Le français, langue artificielle, n’est pas le dialecte d’IdeF, comme l’a
> montré Molière au début de son Don Juan : on y voit des paysannes parlant à
> la mode d’IdeF et parlant de “la iau” (l’eau).


Le "français" de l'Académie a aussi effacé le parler vernaculaire
d'Île-de-France (au départ plus rural et pas le même que celui de Paris à
l'époque et qui n'était pas non plus un des argots parisiens modernes). La
France à l'époque parlait différentes langues selon les classes et
corporations. Ceux qui parlaient ces langues adaptaient leur discours à
leurs interlocuteurs, et il y avait une nette différenciation entre le
parler écrit (celui des élites) et le parler oral (la majorité de la
population).

Aujourd'hui le français s'est beaucoup parisianisé (il était nettement plus
rural au début de l'Académie, et l'Académie ou la cour de France méprisait
le parler vernaculaire parisien pour lui préférer nettement les parlers de
la Loire, avant l'Académie, la seule langue de prestige était encore le
latin d'église, déjà éloigné du latin classique, mais Louis XIV a voulu
affirmer son autonomie vis-à-vis de l'église pour imposer une autre langua
à son adminsitration qu'il voulait effiace, d'abord pour protéger son
domaine royal de base, un peu en Île-de-France, un peu en Picardie, mais
surtout la long de la Loire).

Le "français" n'a réellement réussi à s'imposer que dans les armées et sur
les galères, puis par les colons (qui ont en fait emporté une forme plus
vernaculaire sans tenir compte ensuite de ce que pouvait imposer plus tard
l'Académie ou l'administration française (sauf dans le second empire
colonial français en Afrique où l'administration était puissante et a
apporté l'écriture, l'éducation, mais aussi forgé l'élite locale et divisé
les ethnies et retenu uniquement les langues des grandes religions écrites).

Molière ne parlait pas non plus réellement le français de l'Académie (comme
l'a fait Racine), il était plus populaire et incluait des parlers
vernaculaires. Il n'a pas beaucoup utilisé les parlers occitans car il les
maitrisait mal et n'en a saisi que des bribes. Alors que les parlers
occitans avaient bonne cote à la cour de France (et d'ailleurs le roi a
voulu et demandé à l'Académie d'incorporer dans le français les locutions
occitanes : il voulait l'unité du royaume; la langue française s'est aussi
modifiée avec la prise d'autres territoires dans les guerres contre les
royaumes espagnols divisés et les Pays-Bas espagnols, mais aussi en
incorporant l'arabe et le turc qui avaient du prestige à l'époque (ce que
Molière a voulu ridiculiser pour leur usage par certaines élites
parisiennes...).

L'orthographe française, son alphabet et sa grammaire ont été un processus
très long et compliqué: il n'est pas simple de contruire une langue-chapeau
qui sera comprise par assez de monde et assez flexible pour plus ou moins
calquer certains parlers tout en retenant certaines étymologies donnant du
sens et une légitimé aux mots (mais permettant aussi d'en former de
nouveaux qui seront compris selon le modèle inventé, plus régulier que le
latin malgré les manipulations par l'église).

D'ailleurs si on parle du latin classique, il n'était pas plus une langue
unique, même à Rome seulement: c'était déjà un empire et la politique
jouait beaucoup; toutefois le latin s'est imposé en prenant quelques
auteurs classiques puis en en faisant une langue d'administration, mais il
a été très mal véhiculé dans l'empire ou les armées romaines ont incorporé
des populations différentes mais dans des tas de légions qui se
mélangeaient peu, l'influence des royaumes soumis à Rome était encore
grande, de même que les influences religieuses de toutes sortes. C'est pour
ça qu'il y a malgré tout une grande variété de 

Re: [Talk-cz] opendata Agentura ochrany přírody a krajiny ČR

[Jan Macura]

2018-01-17 9:32 GMT+01:00 Marián Kyral :

> Wikidata jsou nějaká univerzální pračka na špinavá data? Aneb, jak se z CC
> 4.0 stane CC-0?
>

Jednoduše tak, že autor dat uvolní nějaký konkrétní dataset pro WD, čímž
jej otevře pod CC-0, pak se rozhodne zveřejnit na webu větší balík dat,
zapomene na to, a přilepí tomu hromadně CC-BY. Aneb dotaz měl znít "jak se
z CC-0 stane CC-BY".

K tomu pro jistotu poznámka, že "CC 4.0" označuje verzi licence (liší se
navzájem minimálně), zatímco "CC-0" označuje typ licence (liší se navzájem
zásadně).

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

Re: [Talk-pt] Apresentação de José Flor - OzFlor

[Marcos Oliveira]

Bem-vindo!

Em 17/01/2018 12:50, "Pedro Lima"  escreveu:

> Olá José,
>
> Muito bem vindo. Qualquer coisa avise.
>
> Abraço
>
>
> Em 17 de janeiro de 2018 12:31, Nelson A. de Oliveira 
> escreveu:
>
>> Oi, José.
>> Seja bem vindo.
>>
>> Para os outros integrantes da lista, eu estava conversando
>> anteriormente com o José e convidei-o a participar daqui, para tirar
>> dúvidas e aprender como colaborar da melhor maneira possível com o
>> OpenStreetMap.
>>
>> Obrigado e abraço!
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
>
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-it] Bacheche per rispettare la natura

[Martin Koppenhoefer]

2018-01-17 16:03 GMT+01:00 demon.box :

> ...nessuna idea?
>
> tourism=information
> information=board
> board_type=nature
>
> oppure
>
> man_made=advertising
> advertising=board
> message=tourism
>


per me da quello che hai descritto non è advertising. Non è un
board_type=nature per me, perché non descrive la natura (tipo di piante,
uccelli, animali, ecc.). Forse metterei "notice", oppure
board_type=code_of_conduct ?

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Michał Brzozowski]

Certainly I am not intending to change the community and require every
mapper to comply. If you're an experienced mapper, you're fine.

I mean new users, who are not yet integrated with the community. Their work
should be checked thoroughly (in Achavi, osmcha...). All novices make
mistakes, after all. Better to give them good habits. By extension, smaller
number of changeset will lead to less recycling of same changeset comments.

I made this thread because I found it difficult to convey what is best
practice in short form in changeset comments.

Maybe I should simplify things when explaining to them? No need to tell all
the conventions, just what is a good start - but hoping it won't backfire ;)

17.01.2018 3:35 PM "Imre Samu"  napisał(a):

>  one changeset per building, repeated 20 times

my typical use case:   House numbering on the street:  push the numbers &
forget & go to the next house( fast feedback loop vs. Delayed
gratification  )
- sometimes the mobil app is crashing, and I don't want to go back 100m to
re-enter - the last 5-10 numbers


> Obviously this makes them PITA to review quickly in Achavi or whatever
tool you use.

imho: it is easier to group the changeset on the reviewer side :  by user +
by hour   ( group by user, hour )   than change the community.

Imre





2018-01-17 15:13 GMT+01:00 Michał Brzozowski :

> Certainly not:
> - one changeset per building, repeated 20 times
> - one changeset for 3 POIs that are 1000 km apart in different countries
>
> These are real world examples. In the latter Achavi can often refuse to
> run.
>
> That's also why I asked ;-) It's not that easy to formulate the answer
> what is reasonable to include in a changeset.
>
> Michał
>
> 17.01.2018 2:54 PM "Tobias Zwick"  napisał(a):
>
>> So, what is the optimal changeset size, and why?
>>
>> Tobias
>>
>> On 17/01/2018 14:26, Michał Brzozowski wrote:
>> > Many new users have a habit of e.g. sending one or few objects per
>> > changeset, resulting in a dozen or even more changesets per day.
>> > Obviously this makes them PITA to review quickly in Achavi or whatever
>> > tool you use.
>> >
>> > This habit is probably caused by non-knowledge of how auto-save works in
>> > iD (which makes the work reasonably secure), as well as just not knowing
>> > better thus forming their own judgement.
>> >
>> > How should we teach about optimal changeset size? This is quite tricky -
>> > how we would define it?
>> >
>> > Can the iD nudge users towards better practice? (Linking to Good
>> > changeset comments wiki page would be useful as well)
>> >
>> > Michał
>> >
>> >
>> > ___
>> > 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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Bacheche per rispettare la natura

[demon.box]

...nessuna idea?

tourism=information
information=board
board_type=nature

oppure

man_made=advertising
advertising=board
message=tourism

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: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[JB]

Le 17/01/2018 à 15:19, Charles MILLET a écrit :

je ne sais pas elle fait consensus.
Je confirme, elle ne fait pas consensus. Elle ne fera probablement 
jamais consensus.
highway=path a été la mauvaise bonne idée d'utiliser un mot trop 
descriptif pour tagguer autre chose.

JB.

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Imre Samu]

>  one changeset per building, repeated 20 times

my typical use case:   House numbering on the street:  push the numbers &
forget & go to the next house( fast feedback loop vs. Delayed
gratification  )
- sometimes the mobil app is crashing, and I don't want to go back 100m to
re-enter - the last 5-10 numbers

> Obviously this makes them PITA to review quickly in Achavi or whatever
tool you use.

imho: it is easier to group the changeset on the reviewer side :  by user +
by hour   ( group by user, hour )   than change the community.

Imre





2018-01-17 15:13 GMT+01:00 Michał Brzozowski :

> Certainly not:
> - one changeset per building, repeated 20 times
> - one changeset for 3 POIs that are 1000 km apart in different countries
>
> These are real world examples. In the latter Achavi can often refuse to
> run.
>
> That's also why I asked ;-) It's not that easy to formulate the answer
> what is reasonable to include in a changeset.
>
> Michał
>
> 17.01.2018 2:54 PM "Tobias Zwick"  napisał(a):
>
>> So, what is the optimal changeset size, and why?
>>
>> Tobias
>>
>> On 17/01/2018 14:26, Michał Brzozowski wrote:
>> > Many new users have a habit of e.g. sending one or few objects per
>> > changeset, resulting in a dozen or even more changesets per day.
>> > Obviously this makes them PITA to review quickly in Achavi or whatever
>> > tool you use.
>> >
>> > This habit is probably caused by non-knowledge of how auto-save works in
>> > iD (which makes the work reasonably secure), as well as just not knowing
>> > better thus forming their own judgement.
>> >
>> > How should we teach about optimal changeset size? This is quite tricky -
>> > how we would define it?
>> >
>> > Can the iD nudge users towards better practice? (Linking to Good
>> > changeset comments wiki page would be useful as well)
>> >
>> > Michał
>> >
>> >
>> > ___
>> > 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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-ph] Mayon Volcano Eruption Jan 2018

[Ervin Malicdem]

The objective of the area I created was to include evacuation centers I
mapped before that were used by APDRRMO in 2014 [0] for the phreatic
eruption event plus covering the pyroclastic flow and lahar flow hazard
area released by PHIVOLCS [1]. Might be a good idea in the future to map it
for navigation to the evac centers and escape routes too.

[0] http://www.s1expeditions.com/2014/09/164-mayon-2014-zones.html
[1]
https://reliefweb.int/map/philippines/philippines-mayon-volcano-hazard-map-and-population-16-january-2018

Ervin M.
Schadow1 Expeditions

On Wed, Jan 17, 2018, 9:54 PM maning sambale, 
wrote:

> Ervin,
>
> Thanks, this is so much bigger than the EDZ [0].  I feel its too much
> too big AOI for mapping.
> If we can have detailed poly that identifies at risk areas, that's much
> better.
>
> [0]
> https://user-images.githubusercontent.com/353700/35045993-ab1fce48-fbbb-11e7-9a98-51930ebc17c0.png
>
> On Wed, Jan 17, 2018 at 6:52 PM, Ervin Malicdem 
> wrote:
> > Here it is, Maning
> >
> > https://owncloud.cxsmedia.com/index.php/s/xI7M2yqVI0Zrrs0
> >
> > Ervin M.
> > Schadow1 Expeditions - A Filipino must not be a stranger to his own
> > motherland.
> > http://www.s1expeditions.com
> >
> > On Wed, Jan 17, 2018 at 8:46 PM, maning sambale <
> emmanuel.samb...@gmail.com>
> > wrote:
> >>
> >> Ervin,
> >>
> >> > A poly file [0] was created to prioritize its southwest quadrant where
> >> > the
> >> > magma initially flowed and also to include evacuation centers we
> mapped
> >> > back
> >> > during its phreatic eruption in 2014. I suggest we can also make this
> as
> >> > the
> >> > bounds for the HOT task.
> >>
> >> I can't find my poly to geojson coverter right now, can you share
> >> geojson or shapefile?
> >>
> >> --
> >> cheers,
> >> maning
> >> --
> >> "Freedom is still the most radical idea of all" -N.Branden
> >> https://epsg4253.wordpress.com/
> >> http://twitter.com/maningsambale
> >> --
> >
> >
>
>
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> https://epsg4253.wordpress.com/
> http://twitter.com/maningsambale
> --
>
-- 

Ervin Malicdem
for Schadow1 Expeditions
A Filipino must not be a stranger to his own motherland.
http://www.s1expeditions.com
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-cz] Přejmenování některých katastrálních území

[majka]

Dávám do samostatného vlákna - na stránkách ČÚZK jsou oznámené změny názvů

některých katastrálních území - tedy boundary=administrative admin_level 10

V tom letošním souboru jsou všechny změny i za roky zpětně, nejnovější
změna platí od 01.02.2018

Převzetí z těch informací ČÚZK by snad nemělo představovat problém.

Kontroluje někdo tyhle změny?
Pokud ne, můžu to někdy večer projít a aktualizovat, jen netuším, jestli už
to nějak neběží.

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

[OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[Charles MILLET]

Bonjour,

Je sais qu'il y a une discussion en cours concernant spécifiquement les 
pistes cyclables sur les trottoirs et je ne veux pas faire de doublon. 
Mais je voulais avoir votre avis sur une récente modification de la page 
FR:Bicycle avant de contacter le contributeur ou de discuter sur la 
page. Voici la page de modification pour référence : 
https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1547110


La modification concerne cette phrase dans la partie Voies piétonnes 
partagées 
(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.C3.A9tonnes_partag.C3.A9es) 
:


"En l'absence d'indication de nature de la voie, utiliser l'attribut 
highway =path 
 qui autorise 
cyclistes et piétons à circuler ensemble"


Même si cette approche est assez commode car elle permet d'éviter les 
débats pour savoir si un voie est un footway ou un cycleway, je la 
trouve assez catégorique et je ne sais pas elle fait consensus.


--
Charles MILLET
charlesmil...@free.fr

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Michał Brzozowski]

Certainly not:
- one changeset per building, repeated 20 times
- one changeset for 3 POIs that are 1000 km apart in different countries

These are real world examples. In the latter Achavi can often refuse to run.

That's also why I asked ;-) It's not that easy to formulate the answer what
is reasonable to include in a changeset.

Michał

17.01.2018 2:54 PM "Tobias Zwick"  napisał(a):

> So, what is the optimal changeset size, and why?
>
> Tobias
>
> On 17/01/2018 14:26, Michał Brzozowski wrote:
> > Many new users have a habit of e.g. sending one or few objects per
> > changeset, resulting in a dozen or even more changesets per day.
> > Obviously this makes them PITA to review quickly in Achavi or whatever
> > tool you use.
> >
> > This habit is probably caused by non-knowledge of how auto-save works in
> > iD (which makes the work reasonably secure), as well as just not knowing
> > better thus forming their own judgement.
> >
> > How should we teach about optimal changeset size? This is quite tricky -
> > how we would define it?
> >
> > Can the iD nudge users towards better practice? (Linking to Good
> > changeset comments wiki page would be useful as well)
> >
> > Michał
> >
> >
> > ___
> > 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: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Martinec]

Na neoficiální názvy máme loc_name, ne (křižovatka U Bulhara byl taky kdysi
neofiko název podle tamního trafikanta)? Minimálně Nominatim podle toho
hledat umí.

Co se týče logických důvodů, ty celkem neexistují - jen historické
("Vinohradská končí u vozovny, protože to je poslední výspa civilizace v
malešických polích, dál už je jenom silnice." - no a pak se Praha rozrostla)

Jinak nejde jen o nbsp, někdo přidává Unicode ekvivalenty na římské číslice
v názvech. To je medle ok, ale je to kanonický název, nebo ten má být spíše Ⅱ,
nebo II?

Zdar,
Honza Piškvor Martinec

Dne 17. 1. 2018 14:50 napsal uživatel "majka" :



2018-01-17 13:49 GMT+01:00 Matej Lieskovský :

>
> 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
>

Trocha teorie - správně by to snad mělo být podle údajů ČÚZK


A teď praxe: vím o změně adresy (nejde o přestěhování ani přejmenování, jen
formálně ulice + správná adresa) v letech 2002, 2008 a 2015.
Celý ten rozdíl se točí kolem toho, jestli je správně uvedeno "Pražská",
"Pražská třída" nebo "Pražská tř." Momentálně je správně to poslední. Musím
to znovu zkontrolovat v datech, ale kdysi jsem tam přidávala alt_name,
protože s tím vyhledávače měly problémy.

A nejlepší jsou "zavedené" ulice v určitých městech, které vůbec
neexistovaly. Jako příklad je ulice U Panelárny  v
Jindřichově Hradci. Nemovitosti na ní se nacházející používající tuhle
adresu totiž (snad až na jedinou výjimku) do katastru Jindřichova Hradce
vůbec nepatří, a ten název se užíval co já pamatuji minimálně patnáct let,
než byl podle těch informací ČÚZK 11.09.2014 oficiálně zaveden.

Asi jsem Ti moc nepomohla, co říkáš?

Majka

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-17, 12:49 GMT, Matej Lieskovský wrote:
> 1) Odstraňuj nbsp z názvů ulic
> 2) Tam, kde se vyskytují obě varianty, preferuj tu bez nbsp
> 3) Tam, kde se vyskytují obě varianty, preferuj tu častější
> 4) Tam, kde se vyskytují obě varianty, preferuj tu s nbsp
> 5) Přidávej (ručně) nbsp do názvů ulic
> 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně

Já se potácím někde mezi 4 a 6. Na jednu stranu je koncept jména 
ulice velice nestálý pojem (je skutečně spořilovská Jihovýchodní 
IV. 2. díl jiná ulice nežli Jihovýchodní IV 1. díl? Hmm, tohle 
dělení jsme také zjevně vzdaly a ty díly vynecháváme), ale nic 
lepšího nemáme, a ono to asi souvisí s nejasným konceptem ulice.  
Ono není nikde žádná metafyzická odpověď na to, proč Vinohradská 
končí na té křižovatce se Starostrašnickou a je z ní najednou 
Černokostelecká.

Taky Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
It is the mark of an educated mind to be able to entertain
a thought without accepting it.
  -- Aristotle


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

[OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

[Charles MILLET]

Un contributeur a précisé l'information suivante dans la page du Wiki 
FR:Bicycle


"Utiliser l'attribut highway 
=living_street 
, 
l'attribut maxspeed 
=20 
 
*n'est pas nécessaire* car valeur par défaut en France"


De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne 
pas se basé sur les spécificités locales pour considérer des valeurs 
implicites de cette importance. Mais je voulais avoir vos avis avant 
d'en parler dans la partie discussion ou directement avec le 
contributeur. Bon je pense que le sujet a déjà du être beaucoup débattu 
mais comme je n'ai pas trouvé de référence claire, ça pourra faire 
l'objet d'un rappel :)


--
Charles MILLET
charlesmil...@free.fr

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

Re: [talk-ph] Mayon Volcano Eruption Jan 2018

[maning sambale]

Ervin,

Thanks, this is so much bigger than the EDZ [0].  I feel its too much
too big AOI for mapping.
If we can have detailed poly that identifies at risk areas, that's much better.

[0] 
https://user-images.githubusercontent.com/353700/35045993-ab1fce48-fbbb-11e7-9a98-51930ebc17c0.png

On Wed, Jan 17, 2018 at 6:52 PM, Ervin Malicdem  wrote:
> Here it is, Maning
>
> https://owncloud.cxsmedia.com/index.php/s/xI7M2yqVI0Zrrs0
>
> Ervin M.
> Schadow1 Expeditions - A Filipino must not be a stranger to his own
> motherland.
> http://www.s1expeditions.com
>
> On Wed, Jan 17, 2018 at 8:46 PM, maning sambale 
> wrote:
>>
>> Ervin,
>>
>> > A poly file [0] was created to prioritize its southwest quadrant where
>> > the
>> > magma initially flowed and also to include evacuation centers we mapped
>> > back
>> > during its phreatic eruption in 2014. I suggest we can also make this as
>> > the
>> > bounds for the HOT task.
>>
>> I can't find my poly to geojson coverter right now, can you share
>> geojson or shapefile?
>>
>> --
>> cheers,
>> maning
>> --
>> "Freedom is still the most radical idea of all" -N.Branden
>> https://epsg4253.wordpress.com/
>> http://twitter.com/maningsambale
>> --
>
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Tobias Zwick]

So, what is the optimal changeset size, and why?

Tobias

On 17/01/2018 14:26, Michał Brzozowski wrote:
> Many new users have a habit of e.g. sending one or few objects per
> changeset, resulting in a dozen or even more changesets per day.
> Obviously this makes them PITA to review quickly in Achavi or whatever
> tool you use.
> 
> This habit is probably caused by non-knowledge of how auto-save works in
> iD (which makes the work reasonably secure), as well as just not knowing
> better thus forming their own judgement.
> 
> How should we teach about optimal changeset size? This is quite tricky -
> how we would define it?
> 
> Can the iD nudge users towards better practice? (Linking to Good
> changeset comments wiki page would be useful as well)
> 
> Michał
> 
> 
> ___
> 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-cl] Mejoras a la red de carreteras en Chile

[Cristián Serpell]

Algo así sería maravilloso. También debería revisar, al igual que
geofabrik, nombres de calle en direcciones diferente a los nombres de
calles cercanas (por ejemplo, una calle está como Tarapacá, y en las
direcciones como Avenida Tarapacá).

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[majka]

2018-01-17 13:49 GMT+01:00 Matej Lieskovský :

>
> 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
>

Trocha teorie - správně by to snad mělo být podle údajů ČÚZK


A teď praxe: vím o změně adresy (nejde o přestěhování ani přejmenování, jen
formálně ulice + správná adresa) v letech 2002, 2008 a 2015.
Celý ten rozdíl se točí kolem toho, jestli je správně uvedeno "Pražská",
"Pražská třída" nebo "Pražská tř." Momentálně je správně to poslední. Musím
to znovu zkontrolovat v datech, ale kdysi jsem tam přidávala alt_name,
protože s tím vyhledávače měly problémy.

A nejlepší jsou "zavedené" ulice v určitých městech, které vůbec
neexistovaly. Jako příklad je ulice U Panelárny  v
Jindřichově Hradci. Nemovitosti na ní se nacházející používající tuhle
adresu totiž (snad až na jedinou výjimku) do katastru Jindřichova Hradce
vůbec nepatří, a ten název se užíval co já pamatuji minimálně patnáct let,
než byl podle těch informací ČÚZK 11.09.2014 oficiálně zaveden.

Asi jsem Ti moc nepomohla, co říkáš?

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

Re: [Talk-cl] Mejoras a la red de carreteras en Chile

[Álvaro Monares G.]

Que tal, la otra vez hice un bot para cambiar nombres bastante simple.
Estaba pensando y tal vez inicialmente podría "sugerir" cambios, hacemos
que se ejecute cada cierto tiempo e identifique ciertas situaciones (Se 
me ocurre)

1.- Cambio de abreviaciones.
2.- Cambio de nombre de calles sobre una misma línea.
3.- Revisión de ubicación de paraderos en base a otras fuentes.
4.- Revisión de nombre de las calles versus nodos cercanos.
Entonces en la interfaz web, lo muestra y colaborativamente vamos 
aceptando los
cambios, de esa forma hay un humano revisando la corrección. Todas esas 
correcciones,
deberían generar un changeset asociado al usuario osm de quien lo hizo y 
con un tag

que lo hizo el bot.

Quedo atento a comentarios, saludos
Álvaro Monares G.


El 16/01/18 a las 22:54, Danilo Lacoste escribió:

Exacto a eso me refiero.

Puede que sea fácil, pero no se ha hecho. y es muy útil. ( me da la 
impresión)


saludos.


2018-01-16 22:22 GMT-03:00 Julio Costa Zambelli 
>:


Hola Danilo,

¿Te refieres a "errores" recurrentes del tipo "Psje. X" en lugar
de "Pasaje" o "Av. X" en lugar de "Avenida X"?

Entiendo que ya existen bots que pueden hacer esto (yo no los he
usado), y solo habría que ejecutarlos de acuerdo con ciertas
convenciones.

Saludos,

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl 

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

2018-01-16 21:21 GMT-03:00 Danilo Lacoste >:

Estimados,

una buena herramienta que creo nos hace falta en Chile es un
"boot chileno" que nos notifique de todas esas fallas en forma
automática. y permita la edición masiva semanal de
estandarización. (por ejemplo corrección de nombres, chequeo
de calles, etc).

entiendo que hay unos boot generales, pero este boot Chileno
se centraría en los puntos especificos de Chile.

saludos.

2018-01-16 20:11 GMT-03:00 Julio Costa Zambelli
>:

Hola Andrew,

En general te diría que el mapa está bastante bien en
buena parte del país, aunque obviamente hay muchos lugares
donde nos falta numeración, edificios, restricciones de
giro, etc. (lo que más toma tiempo en todas partes del
mundo).

¿Han pensado en implementar herramientas para ayudar a los
mapeadores locales? Por ejemplo, hace poco se estuvo
hablando (no recuerdo si en listas locales o regionales)
sobre formas de "limpiar" las trazas GPS que ya están en
los servidores de OSM, y se llego a la conclusión de que
la única forma es bajar todas tus trazas, "limpiarlas"
localmente y volver a subirlas sin el "ruido". Lo que es
bastante difícil actualmente, no hay herramientas para
descargar todas tus trazas de una sola vez y la mayoría de
los editores locales tienen problemas para manejar cientos
o miles de trazas simultáneamente.

Creo que una solicitud general (y seguramente también
común) es que no hagan ediciones masivas (clasificación,
alineación, etc.) sin consultar con las personas que
mapean en esos sectores.

Saludos,

Julio Costa Zambelli
Fundación OpenStreetMap Chile

julio.co...@openstreetmap.cl


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

2018-01-13 19:34 GMT-03:00 Andrew Wiseman
>:

Hola,

Mi nombre es Andrew Wiseman, trabajo para el equipo de
Apple Maps. Estamos interesados en ayudando a mejorar
la red de vías de circulación en Chile en OSM: cosas
como añadiendo calles que faltan, asegurarse que vías
estan conectadas y clasificaciones estén consistentes,
mejorando alineación con trazas de GPS, y otros
problemas similares.

Tenemos una página de Github para este proyecto:
https://github.com/osmlab/appledata/issues/35


¿Tienen ustendes sugerencias de zonas que necesitan
mejoras o tipos de problemas que son frecuentes?

Muchas gracias,

Andrew

Apple, Inc.


Andrew Wiseman |Maps | iPhone: +1.202.270.4464
 | 

[OSM-talk] How to teach novices about optimal changeset size?

[Michał Brzozowski]

Many new users have a habit of e.g. sending one or few objects per
changeset, resulting in a dozen or even more changesets per day. Obviously
this makes them PITA to review quickly in Achavi or whatever tool you use.

This habit is probably caused by non-knowledge of how auto-save works in iD
(which makes the work reasonably secure), as well as just not knowing
better thus forming their own judgement.

How should we teach about optimal changeset size? This is quite tricky -
how we would define it?

Can the iD nudge users towards better practice? (Linking to Good changeset
comments wiki page would be useful as well)

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

Re: [talk-ph] Mayon Volcano Eruption Jan 2018

[Ervin Malicdem]

Here it is, Maning

https://owncloud.cxsmedia.com/index.php/s/xI7M2yqVI0Zrrs0

Ervin M.
*Schadow1 Expeditions* - A Filipino must not be a stranger to his own
motherland.
http://www.s1expeditions.com

On Wed, Jan 17, 2018 at 8:46 PM, maning sambale 
wrote:

> Ervin,
>
> > A poly file [0] was created to prioritize its southwest quadrant where
> the
> > magma initially flowed and also to include evacuation centers we mapped
> back
> > during its phreatic eruption in 2014. I suggest we can also make this as
> the
> > bounds for the HOT task.
>
> I can't find my poly to geojson coverter right now, can you share
> geojson or shapefile?
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> https://epsg4253.wordpress.com/
> http://twitter.com/maningsambale
> --
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-es] Calle Bolivar Madrid España el API devuelve mal el código postal

[alan_gr]

Acabo de descubrir este, parece que la calculación de códigos postales en
Nominatim sí ha cambiado últimamente, pero no he tenido tiempo para leer con
ciudado:

https://www.openstreetmap.org/user/lonvia/diary/43143



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-es] Cuenta de GitHub OSM-es

[David Marín Carreño]

Hola.

Por favor, añádeme. Soy davefx en github.

Quizá se podría añadir el proyecto
https://github.com/davefx/osm-callejero-importer
--
David Marín Carreño

El mié., 17 ene. 2018 a las 0:35, Javier Sánchez Portero (<
javiers...@gmail.com>) escribió:

> Enviadas invitaciones. Para que los usuarios puedan verse desde fuera,
> cada miembro debe configurar su visibilidad en el apartado "people".
>
>
> El 16 de enero de 2018, 22:11, Miguel Sevilla-Callejo <
> msevill...@gmail.com> escribió:
>
>> Hola,
>>
>> Genial idea, pendiente de haberse hecho hace tiempo, por cierto.
>>
>> Cuneta conmigo, también soy msevilla00 en GitHub
>>
>> ¿Vi que los participantes no están públicos, no sería conveniente que se
>> vieran?
>>
>> Por si sirve de algo os comento que en Zaragoza, el grupo de Mapeado
>> Colaborativo también tenemos una cuenta de GitHub con algunos materiales
>> con los que trabajamos: https://github.com/mapcolabora
>>
>> Ahora andamos con GitLab con HUGO para nuestra web pero se me ocurrió que
>> podríamos usar las páginas de GitHub/GitLab para recrear la página web de
>> OSM-es allí.
>>
>> Un saludo y gracias
>>
>> Miguel
>>
>> --
>> *Miguel Sevilla-Callejo*
>> Doctor en Geografía
>>
>> 2018-01-16 21:21 GMT+01:00 Javier Sánchez Portero :
>>
>>> Hola.
>>>
>>> Como comentaba en el hilo de la importación de Catastro, he creado una
>>> cuenta de GitHub con el nombre 'osm-es'. La idea es agrupar allí proyectos
>>> de interés para nuestra comunidad. Para usar la cuenta es necesario entrar
>>> a formar parte de la 'organización' (término que utiliza GitHub para
>>> referirse a este tipo de cuentas compartidas). Si alguien desea participar
>>> con sus proyectos no tiene más que decirlo para enviarle una invitación. Ya
>>> he enviado algunas por mi cuenta, ruego me perdonen si me olvido de
>>> alguien.
>>>
>>> Si alguien quiere agregar algún proyecto puede hacer un 'fork' para
>>> tener una copia en esta cuenta y que estén más localizables a través de
>>> algún enlace que pongamos en la Wiki. Se me ocurren por ejemplo
>>> josego85/curso_mapas, shiguera/osm2017, etc.
>>>
>>> Un saludo, Javier.
>>>
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-pt] Apresentação de José Flor - OzFlor

[Pedro Lima]

Olá José,

Muito bem vindo. Qualquer coisa avise.

Abraço


Em 17 de janeiro de 2018 12:31, Nelson A. de Oliveira 
escreveu:

> Oi, José.
> Seja bem vindo.
>
> Para os outros integrantes da lista, eu estava conversando
> anteriormente com o José e convidei-o a participar daqui, para tirar
> dúvidas e aprender como colaborar da melhor maneira possível com o
> OpenStreetMap.
>
> Obrigado e abraço!
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[Talk-cz] Nedělitelné mezery v názvech ulic

[Matej Lieskovský]

Ahoj!

Pomalu pracuju na tom již zmiňovaném systému na polo-automatickou údržbu
street relací a tak narážím na různé podivnosti v databázi, kterých bych si
jinak nevšiml. Třeba mě to upozorňuje na to, když jednotlivé segmenty té
samé ulice mají různé názvy, což chytá i takové prkotiny, jako je
nedělitelná mezera (nbsp).

Vím, že se tady před rokem vedl flame na téma nedělitelných mezer a k
žádnému konsenzu to (pokud vím) nevedlo.

Přijde mi rozumné, aby všechny segmenty ulice měly identické name tagy.
Část důvodu, proč celé tyhle street relace dělám je i snaha o automatickou
synchronizaci name: tagů napříč všemi segmenty. Když napíšu nbsp do
tagů relace, tak mi to asi náhodní editoři nerozbijou a jsem ochoten to pak
opravovat.

Co mám dělat?

1) Odstraňuj nbsp z názvů ulic
2) Tam, kde se vyskytují obě varianty, preferuj tu bez nbsp
3) Tam, kde se vyskytují obě varianty, preferuj tu častější
4) Tam, kde se vyskytují obě varianty, preferuj tu s nbsp
5) Přidávej (ručně) nbsp do názvů ulic
6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně

Ať se daří,
Matej
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [talk-ph] Mayon Volcano Eruption Jan 2018

[maning sambale]

Ervin,

> A poly file [0] was created to prioritize its southwest quadrant where the
> magma initially flowed and also to include evacuation centers we mapped back
> during its phreatic eruption in 2014. I suggest we can also make this as the
> bounds for the HOT task.

I can't find my poly to geojson coverter right now, can you share
geojson or shapefile?

-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [Talk-es] Calle Bolivar Madrid España el API devuelve mal el código postal

[alan_gr]

Según el FAQ de Nominatim [1] los códigos postales fueron importados o
calculados en 2012, no están actualizados, y están trabajando en algo mejor.
No sé si el FAQ está actualizado.

[1]https://wiki.openstreetmap.org/wiki/Nominatim/FAQ#My_postcode_is_missing.2Fwrong_but_I.27ve_fixed_it_in_the_OSM_data._What_is_wrong.3F



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [talk-ph] Mayon Volcano Eruption Jan 2018

[maning sambale]

Thanks everyone for finishing the task really quick!  We have 100%
mapped and 57% validated as of this time.
Also thanks to the mappers before us who already mapped a lot before this event.

We created a new task to include the expanded danger zone [0],
reference material [1].
Compared to the previous task, this needs more effort since these
areas are more populated than the permanent danger zone.

This continues to be a local response, but anyone is welcome to participate

[0] https://tasks.hotosm.org/project/4037
[1] http://www.ifrc.org/docs/appeals/rpts09/PHvol221209.pdf

On Tue, Jan 16, 2018 at 10:16 AM, Ervin Malicdem  wrote:
> Schadow1 Expeditions has initiated producing a humanitarian version of GPS
> navigation map for this area a few hours after its magmatic eruption in
> January 14.
> Let me know if the HOT activation needs a daily update for this one.
> A poly file [0] was created to prioritize its southwest quadrant where the
> magma initially flowed and also to include evacuation centers we mapped back
> during its phreatic eruption in 2014. I suggest we can also make this as the
> bounds for the HOT task.
>
> Map is available on site [1]
>
>
> [0] https://owncloud.cxsmedia.com/index.php/s/zEQ1ZAyM9AyTg0b
> [1]
> http://www.s1expeditions.com/p/the-gps-navigation-map-of-philippines.html
>
>
> Ervin M.
> Schadow1 Expeditions - A Filipino must not be a stranger to his own
> motherland.
> http://www.s1expeditions.com
>
> On Tue, Jan 16, 2018 at 11:55 AM, maning sambale
>  wrote:
>>
>> Mayon Volcano in the Philippines erupted this week.  Local community
>> is mapping from pre-event imagery.
>> This is not yet a full HOT Activation.  We are still assessing the
>> needs of responders, but if anyone has spare time,
>> we have a task [0] ready for the permanent danger zone.  This mapping
>> is focused on mapping infrastructure (roads and buildings) and
>> waterways.
>>
>> [0] https://tasks.hotosm.org/project/4027
>>
>> --
>> cheers,
>> maning
>> --
>> "Freedom is still the most radical idea of all" -N.Branden
>> https://epsg4253.wordpress.com/
>> http://twitter.com/maningsambale
>> --
>>
>> ___
>> talk-ph mailing list
>> talk-ph@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ph
>
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [OSM-talk-be] How to avoid that names are on all buildings

[Tim Couwelier]

Pitching in for a second, as it's my initial tag that got the ball rolling.

The name 'Clintonpark' indicates the combined area of the buildings and
their respective parkinglots, and is actually used as such.
It's not a 'street name', as the buildings have house numbers referencing
'Ter Reigerie', the street passing next to it.

At present, all the seperate buildings are tagged with the name
'Clintonpark', which is cluttered (and looks a bit messy), but isn't
entirely correct either.




2018-01-17 12:49 GMT+01:00 Marc Gemis :

> To answer how you have to map this, you first have to answer: what is
> "Clintonpark" ?
>
> - an area
> - a collection of buildings ?
> - a collection of identically named buildings ?
>
> m.
>
> On Wed, Jan 17, 2018 at 9:24 AM, Jakka  wrote:
> > Hi,
> >
> > Every building with a different house number is a office and named
> > "Clintonpark". Is this not to much same names on map.
> > I tried to put it in relations but validator do not liked it, building,
> > parking there are sharing same highways.
> > Is there a need solution.
> >
> > https://www.openstreetmap.org/note/1263904#map=17/50.95775/
> 3.10242=N
> >
> > thx
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-es] Calle Bolivar Madrid España el API devuelve mal el código postal

[Miguel de Dios Matias]

Perdón no se si ayuda que he probado la respuesta html y tiene mas detalles:

https://nominatim.openstreetmap.org/details.php?place_id=117151370

Y viene un campo llamado "Computed Postcode" que ahí sale el mal.

Y por ejemplo la "calle del laurel" que esa si funciona bien, sale bien
todo:

https://nominatim.openstreetmap.org/details.php?place_id=127865832

Pues eso...no se si da algo mas de información...sigo estudiando también yo
a ver si encuentro la solución.

Saludos.

El 17 de enero de 2018, 13:22, Miguel de Dios Matias 
escribió:

> Buenas.
>
> "Jugando" un poco con el API de openstreetmap he hecho el siguiente query:
>
> https://nominatim.openstreetmap.org/search?format=jsonv2=ES=Madrid=1=calle+bolivar%2C+11
>
> Y devuelve:
>
> Array
> (
> [0] => Array
> (
> [place_id] => 117151370
> [licence] => Data © OpenStreetMap contributors, ODbL 1.0. 
> http://www.openstreetmap.org/copyright
> [osm_type] => way
> [osm_id] => 200517358
> [boundingbox] => Array
> (
> [0] => 40.3928048
> [1] => 40.3931974
> [2] => -3.6900389
> [3] => -3.6888734
> )
>
> [lat] => 40.3928048
> [lon] => -3.6900389
> [display_name] => Calle Bolívar, Arganzuela, Madrid, Área 
> metropolitana de Madrid y Corredor del Henares, Comunidad de Madrid, 28019, 
> España
> [place_rank] => 26
> [category] => highway
> [type] => residential
> [importance] => 0.335
> [address] => Array
> (
> [road] => Calle Bolívar
> [suburb] => Arganzuela
> [city_district] => Arganzuela
> [city] => Madrid
> [county] => Área metropolitana de Madrid y Corredor del 
> Henares
> [state] => Comunidad de Madrid
> [postcode] => 28019
> [country] => España
> [country_code] => es
> )
>
> )
>
> )
>
> El código postal esta mal, es el 28045. He probado la posición que
> devuelve por si es que me daba otra calle, pero ha dado la calle exacta.
>
> Pero no se donde se cambia en el código postal...desde el editor de
> navegador.
>
> Saludos.
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-cz] Počet pater z RUIAN

[Vladimír Slávik]

Jsou chyby a chyby...

Matně si vzpomínám že v jakési dědině (Lysice? Drnovice?) jsem viděl
importované domy s počtem pater 1 a 0. Situace na místě byla že 0 pater fakt
nemáme :D Často taky stálo o patro víc než ta oficiální jednička... To bylo
před pár lety, třeba se aspoň ta nula zlepšila.

Taky jsem viděl dědinu kde byly typické domy štít na štítě reprezentované v
RUIAN copypastou obdélníčků v řádce s rozestupy, aby se nepřekrývaly. Tuším
Rychtářov? Taky pár let zpátky. Třeba je to taky spravené. Tam by ty patra
byly asi irelevantní :-/

Ale správně nesprávně, OSM má ten komplikovaný způsob určování pater na
nadzemní, podzemní a střešní, takže s RUIAN to číslo bude těžko sedět i tak.
Nezbývá než si dům prohlédnout na místě, čísla zadat ručně a doufat že to
vydrží další průchod ruianizace.

Povzdech +1...

V.

-- Původní e-mail --
Od: Marián Kyral 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 13:10:01
Předmět: Re: [Talk-cz] Počet pater z RUIAN
"
-- Původní e-mail --
Od: Vladimír Semotán 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 12:46:42
Předmět: [Talk-cz] Počet pater z RUIAN
"




Zdravím,


chci se zeptat: neřešil někdo z Vás nějaké procento chybovosti atributu
počtu pater importovaných z RÚIÁN? Mě osobně připadá, že je v tom tak moc
chyb (už ze zdroje), že je to prakticky nepoužitelná informace. Kdyby to
bylo +- 1 patro, ale narážím na extrémy 4 vs. 10 pater a podobně. Třeba
takové náměstí v Chrudimi. Tam nesedí snad ani jeden dům :-/.




"



Ahoj,

něco se už řešilo. Mám pocit, že se došlo k tomu, že v některých případech
se jedná o reálný počet pater vynásobený počtem vchodů. Ale pokud je jen
jeden vchod, tak to asi bude nějaká chybička. Nevím, jestli to jde v
současné době nějak reklamovat.





Marián



"





Ani nevím, jestli má můj příspěvek do diskuze nějakou pointu. Spíš je to
takový povzdech.

Díky za přečtení :-)


Vladimír

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

Re: [Talk-pt] Apresentação de José Flor - OzFlor

[Nelson A. de Oliveira]

Oi, José.
Seja bem vindo.

Para os outros integrantes da lista, eu estava conversando
anteriormente com o José e convidei-o a participar daqui, para tirar
dúvidas e aprender como colaborar da melhor maneira possível com o
OpenStreetMap.

Obrigado e abraço!

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

[Talk-es] Calle Bolivar Madrid España el API devuelve mal el código postal

[Miguel de Dios Matias]

Buenas.

"Jugando" un poco con el API de openstreetmap he hecho el siguiente query:

https://nominatim.openstreetmap.org/search?format=jsonv2=ES=Madrid=1=calle+bolivar%2C+11

Y devuelve:

Array
(
[0] => Array
(
[place_id] => 117151370
[licence] => Data © OpenStreetMap contributors, ODbL 1.0.
http://www.openstreetmap.org/copyright
[osm_type] => way
[osm_id] => 200517358
[boundingbox] => Array
(
[0] => 40.3928048
[1] => 40.3931974
[2] => -3.6900389
[3] => -3.6888734
)

[lat] => 40.3928048
[lon] => -3.6900389
[display_name] => Calle Bolívar, Arganzuela, Madrid, Área
metropolitana de Madrid y Corredor del Henares, Comunidad de Madrid,
28019, España
[place_rank] => 26
[category] => highway
[type] => residential
[importance] => 0.335
[address] => Array
(
[road] => Calle Bolívar
[suburb] => Arganzuela
[city_district] => Arganzuela
[city] => Madrid
[county] => Área metropolitana de Madrid y
Corredor del Henares
[state] => Comunidad de Madrid
[postcode] => 28019
[country] => España
[country_code] => es
)

)

)

El código postal esta mal, es el 28045. He probado la posición que devuelve
por si es que me daba otra calle, pero ha dado la calle exacta.

Pero no se donde se cambia en el código postal...desde el editor de
navegador.

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

[Talk-pt] Apresentação de José Flor - OzFlor

[José António Flor de Sousa]

Bom dia ao grupo,


Sou o José Flor, o nick na internet e por ai fora é OzFlor.

Comecei recentemente na here seguido de openstreetmap e mapillary.


Ainda sou novo por aqui e aos poucos vou entendendo como se faz. Irei ter 
duvidas que procurarei informar. Assim sempre que estiver editando peço ajuda 
quando o necessitar.


Iram verificar que vou editar em 5 países porque é por ai que eu tenho andado e 
conheço as áreas em volta.


Os meus interesses são diversos, parapente ciência com astronomia sem faltar, 
montanhas e natureza em geral. Electrónica já deixei de parte onde tinha muito 
material de aulas em fóruns que agora se perderam. Meu ultimo trabalho por 
conta própria era handyman. Agora estou parado e com muito tempo para viajar 
por ai.


Ainda não sei que tipo de contribuição posso dar para o openstreetmap, conforme 
for entrando no site vou vendo se algo necessita de editar. Por agora estou 
fazendo o mapillary e verifico que tem muitos erros de sinais de transito que 
gostaria de editar nas minhas ou noutras imagens que me aparecerem pela frente.


Grato por me aceitarem no grupo.


José Flor



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

Re: [Talk-cz] Počet pater z RUIAN

[Vladimír Semotán]

Ahoj,

ten počet vchodů je zajímavý "hint". Kouknu-li ale třeba sem:
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/18734715, vidím 10 pater a
žádné uvedené vchody (osm tu informaci odráží) :-/. Na mapy.cz má ta budova
jen 3-4 patra:
https://mapy.cz/zakladni?x=15.7955811=49.9512841=18=0=9jw-txX4kO=muni=2248=chrudim.
Leda by měla ještě 6 pater v podzemí, což se mi nějak nezdá. Ale to neni
ojedinělý případ. Zkoušel jsem generovat 3D model terénu, cca 50x50km
(Čáslav - Pardubice) a také Brno. Je tam těch chyb dost. Nenapadá mě ani
vhodný filtr, protože chyba se zdá být jak u nízkch tak i u vysokých budov
zastoupena dostatečně. Asi budu muset počet pater ignorovat a spolehnout se
na nějakou heuristiku :-/.

Vladimír.

Dne 17. ledna 2018 13:09 Marián Kyral  napsal(a):

>
> -- Původní e-mail --
> Od: Vladimír Semotán 
> Komu: OpenStreetMap Czech Republic 
> Datum: 17. 1. 2018 12:46:42
> Předmět: [Talk-cz] Počet pater z RUIAN
>
> Zdravím,
>
> chci se zeptat: neřešil někdo z Vás nějaké procento chybovosti atributu
> počtu pater importovaných z RÚIÁN? Mě osobně připadá, že je v tom tak moc
> chyb (už ze zdroje), že je to prakticky nepoužitelná informace. Kdyby to
> bylo +- 1 patro, ale narážím na extrémy 4 vs. 10 pater a podobně. Třeba
> takové náměstí v Chrudimi. Tam nesedí snad ani jeden dům :-/.
>
>
> Ahoj,
>
> něco se už řešilo. Mám pocit, že se došlo k tomu, že v některých případech
> se jedná o reálný počet pater vynásobený počtem vchodů. Ale pokud je jen
> jeden vchod, tak to asi bude nějaká chybička. Nevím, jestli to jde v
> současné době nějak reklamovat.
>
>
> Marián
>
>
>
> Ani nevím, jestli má můj příspěvek do diskuze nějakou pointu. Spíš je to
> takový povzdech.
> Díky za přečtení :-)
>
> Vladimír
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-at] Einladung zum Januar-Stammtisch in Graz am Montag, 22.1.

[Michael Maier]

Liebe OpenStreetMap-Interessierte in der Steiermark,

Der erste heurige Grazer Stammtisch findet nächsten Montag (22.1.2018)
um 18:00 im Brot & Spiele in Graz statt - Tischreservierung auf
„OpenStreetMap“, wir sitzen gleich links vom Eingang (Nichtraucherbereich).

Zwecks Agenda und sonstigem bitte die Wiki-Seite¹ konsultieren:

[1] https://wiki.openstreetmap.org/wiki/Graz/Stammtisch

lg,
Michael
-- 
Michael Maier, Student of Telematics @ Graz University of Technology
OpenStreetMap Graz http://osm.org/go/0Iz@paV
http://wiki.osm.org/Graz
http://wiki.osm.org/Graz/Stammtisch



signature.asc
Description: OpenPGP digital signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-cz] Počet pater z RUIAN

[Marián Kyral]

-- Původní e-mail --
Od: Vladimír Semotán 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 12:46:42
Předmět: [Talk-cz] Počet pater z RUIAN
"




Zdravím,


chci se zeptat: neřešil někdo z Vás nějaké procento chybovosti atributu
počtu pater importovaných z RÚIÁN? Mě osobně připadá, že je v tom tak moc
chyb (už ze zdroje), že je to prakticky nepoužitelná informace. Kdyby to
bylo +- 1 patro, ale narážím na extrémy 4 vs. 10 pater a podobně. Třeba
takové náměstí v Chrudimi. Tam nesedí snad ani jeden dům :-/.




"



Ahoj,

něco se už řešilo. Mám pocit, že se došlo k tomu, že v některých případech
se jedná o reálný počet pater vynásobený počtem vchodů. Ale pokud je jen
jeden vchod, tak to asi bude nějaká chybička. Nevím, jestli to jde v
současné době nějak reklamovat.





Marián



"





Ani nevím, jestli má můj příspěvek do diskuze nějakou pointu. Spíš je to
takový povzdech.

Díky za přečtení :-)


Vladimír

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

Re: [Talk-cz] Počet pater z RUIAN

[Janda Martin]

Dobry den, 

ve starsich datech RUAN bylo vetsinou jen jedno patro. V novejsich datech se 
nejaky pocet pater > 1 vyskytuje casteji. Pocet pater se nesmi brat jako 
smeroplatny. Dokonce i u jinych zdroju patra nesedi. Jedina moznost je mistni 
navsteva ale i tak byvaji problemy jak zapocitat patra pudnich vestaveb nebo 
domu ve svahu. 
Nejlepsi je pretrasovat budovu podle RUIAN pokud jeste neni a doplnit pocet 
pater dle znalosti. 

M 


From: "Vladimír Semotán"  
To: "OpenStreetMap Czech Republic"  
Sent: Wednesday, January 17, 2018 12:45:26 PM 
Subject: [Talk-cz] Počet pater z RUIAN 

Zdravím, 

chci se zeptat: neřešil někdo z Vás nějaké procento chybovosti atributu počtu 
pater importovaných z RÚIÁN? Mě osobně připadá, že je v tom tak moc chyb (už ze 
zdroje), že je to prakticky nepoužitelná informace. Kdyby to bylo +- 1 patro, 
ale narážím na extrémy 4 vs. 10 pater a podobně. Třeba takové náměstí v 
Chrudimi. Tam nesedí snad ani jeden dům :-/. 

Ani nevím, jestli má můj příspěvek do diskuze nějakou pointu. Spíš je to takový 
povzdech. 
Díky za přečtení :-) 

Vladimír 

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

Re: [OSM-talk-be] How to avoid that names are on all buildings

[Marc Gemis]

To answer how you have to map this, you first have to answer: what is
"Clintonpark" ?

- an area
- a collection of buildings ?
- a collection of identically named buildings ?

m.

On Wed, Jan 17, 2018 at 9:24 AM, Jakka  wrote:
> Hi,
>
> Every building with a different house number is a office and named
> "Clintonpark". Is this not to much same names on map.
> I tried to put it in relations but validator do not liked it, building,
> parking there are sharing same highways.
> Is there a need solution.
>
> https://www.openstreetmap.org/note/1263904#map=17/50.95775/3.10242=N
>
> thx
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[Talk-cz] Počet pater z RUIAN

[Vladimír Semotán]

Zdravím,

chci se zeptat: neřešil někdo z Vás nějaké procento chybovosti atributu
počtu pater importovaných z RÚIÁN? Mě osobně připadá, že je v tom tak moc
chyb (už ze zdroje), že je to prakticky nepoužitelná informace. Kdyby to
bylo +- 1 patro, ale narážím na extrémy 4 vs. 10 pater a podobně. Třeba
takové náměstí v Chrudimi. Tam nesedí snad ani jeden dům :-/.

Ani nevím, jestli má můj příspěvek do diskuze nějakou pointu. Spíš je to
takový povzdech.
Díky za přečtení :-)

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

Re: [talk-ph] intro to Kaart initiative in PH

[Glen Scott]

Nothing to offer by my own personal experiences

I'm a regular user of GPS for navigation at home (Australia) in urban and
country environments.  I've noted in OSM (Philippines - specifically N-W
Pangasinan) two things that are undefined in 99% of roads, but used by the
routing engine - road surface and speed limit. With 99% of roads undefined
for surface and speed limit the route chosen by the GPS will be a lottery
as far as driving experience goes.  I guess the most critical would be the
ability to chose to avoid unpaved roads?  I've had a number of Garmin GPSs
and they always assume 80 km/h where the map has no defined limit.  Maybe
10+ years ago I had some experiences where the GPS would attempt to take me
on "short-cuts" over long-unused dirt tracks (in preference to the
highway!).  I guess this is the potential result of not defining the
surface at the very least.  Hard to tell the speed limit from satellite
imagery!

In the urban environment the most common and frustrating errors (Garmin
maps) would be undefined one-way streets.

My one attempt to navigate in the Philippines on OSM (~2008-2009) led me
into a military camp and some interested military personnel who directed me
back out the way I came in!  Gates are important but no always so easy to
see from space

Cheers
Glen

On Wed, Jan 17, 2018 at 5:40 PM, Erwin Olario  wrote:

>
> Thank you for bringing this up, Maning. This is also a concern I've
> discussed with other mappers in the past, and this doesn't just apply to
> road navigation, but with other features, as well.
>
> The Mapbox data team is a pioneer in this road network initiatives in OSM,
> and we look up to your team for inspiration. 
>
> Our current (in the next few months) interest in PH road network
> improvement are low-hanging fruits (missing geometries, restrictions,
> turning lanes, etc), but in due time, we'd like to explore how to further
> improve road network data from OSM for naviation, etc. PH is only one of
> the many countries we're working in, so we need a more inclusive
> understanding of tagging nuances, too.
>
> I hope such a discussion can  attract more inputs from the wider
> community, especially those who've been lurking in the background, who
> follows the exchanges here, but for reasons known only to them, doesn't
> engage publicly.
>
> /Erwin
>
> On Mon, Jan 15, 2018 at 8:35 PM maning sambale 
> wrote:
>
>> Hi Erwin,
>>
>> Thanks for leading this work.  As many of you know, I work in Mapbox
>> and my primary focus is to make OSM navigable.
>> I wonder what would be the best approach in the context of driving in
>> the Philippines.
>> Would love to share notes and approaches.  One thing I have in mind (I
>> shared this during the meetup), while every country
>> has specific nuances tagging, there is a danger of making the tags too
>> specific as its difficult to create routing engines for each country.
>>
>>
>> On Thu, Jan 11, 2018 at 11:58 AM, Erwin Olario  wrote:
>> > Happy new year everyone.
>> >
>> > In case some of you are wondering about some of my recent changeset
>> comments
>> > with the phrase,  "Better PH data with #Kaart", I've recently linked up
>> with
>> > Kaart [0], and their initiative to improve OSM data in the Philippines.
>> >
>> > One of the things we'd like to tackle is road network improvement,
>> initially
>> > in Metro Manila, and later (maybe soon?), expanding to other regions.
>> >
>> > Improvements that are intended to be addressed include the following:
>> > * Adding missing roads
>> > * Improving road attributes (names, lanes, restrictions, etc.)
>> > * Correcting road connectivity issues
>> > * Improving road classification consistency according to OSM guidelines
>> and
>> > local convention
>> > * Correcting road alignment issues
>> > * Other one-off fixes
>> >
>> > Of course, we intend to work closely with the community, and other
>> > stakeholders, especially at the local level.
>> >
>> > We also hope to organize, or lead, activities for developing technical
>> > skills, and enhancing collaboration, and community mapa-thons.  Think of
>> > this as an extension of my earlier MapAmore [1] initiatives.
>> >
>> > The tasking for Metro Manila [2] is now up, and is hosted by HOT Tasking
>> > Manager instance, and open to all interested contributors.
>> >
>> > In tomorrow's meet-up, I'll take the opportunity to elaborate on this
>> > initiative tomorrow. I'm looking forward to hear your feedback, and to
>> > answer any questions here, or directly by email.
>> >
>> > I also hope for your usual helpful collaboration, and support.
>> >
>> > Kind regards,
>> > Erwin
>> >
>> >
>> > [0]: http://kaartgroup.com/
>> > [1]: https://github.com/mapamore
>> > [2]: https://tasks.hotosm.org/project/3997
>> >
>> >
>> > --
>> >
>> > /Erwin Olario
>> >
>> > e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
>> https://mstdn.io/@GOwin
>> >
>> >
>> > 

Re: [OSM-talk-fr] Hiérarchie des relations d’itinéraire cyclistes

[Axelos]

Coucou,


Le 16/01/2018 à 17:23, Charles MILLET a écrit :
> Je raccroche le sujet avec un peu de retard. C’est un super travail que
> tu as fais axelos. Les commentaires qui suivent ne vont malheureusement
> pas vraiment dans ton sens mais ils n’ont pas du tout pour objectif de
> simplement argumenter contre mais bien de faire un retour d’expérience
> de ma tentative très proche de la tienne mais que tu as bien mieux
> documentée :)
> 
> J’avais brièvement évoqué le sujet dans cet échange :
> 
> https://www.mail-archive.com/search?l=talk-fr@openstreetmap.org=subject:%22Re%5C%3A+%5C%5BOSM%5C-talk%5C-fr%5C%5D+Quelques+questions%22=newest=1
> 
> 
> 
> Mon retour d'expérience concernant la mise à jour des itinéraires
> cyclables des Pays de la Loire : J'avais dans un premier temps essayer
> d'avoir l'approche que tu propose qui est au final la bonne approche et
> celle conseillée dans la constitution de routes en général. Je pensais
> que c'était possible car certains itinéraire correspondaient bien à ce
> modèle comme par exemple l'EV1 qui a un beau découpage en étapes. Et
> très vite j'ai constaté que pour la plupart des autres itinéraires ce
> n'était pas vraiement possible à moins de tout découper (cf. données de
> l'ON3V des DRC présentées plus bas). En résumé, ça fonctionne dans le
> cas des grands itinéraires mais ça devient très complexe là où le réseau
> d'itinéraires cyclables est dense. Pour ma part j'en été arrivé à faire
> une relation par itinéraire "officiel" et à ne plus chercher à
> mutualiser des portions d'itinéraire... mais je veux bien revenir sur
> cette pratique si on s'entend pour dire qu'il faut vraiment mutualiser
> les portions d'itinéraire.
> 
> 
> Le problème principale est le fait que chaque échelon administratif est
> autonome pour décrire des itinéraires : international, national, et tous
> les échelons de collectivités locales (Région, département, ComCom,
> etc.) ce qui est bien pour la richesse des itinéraires mais implique une
> absence de hiérarchie dans leur tracé. Ainsi, même si il y a une
> mutualisation des aménagement et en partie des itinéraires, l'approche
> est en réalité très pragmatique.
> 
> 
> Les pièges autres : les différentes collectivités ne nomment pas et ne
> découpent les itinéraires de la même manière ce qui fait qu'on manque
> souvent d'une données de référence.
> 
> 
> Données de l'ON3V des DRC :
> 
> 
> Les Départements et Régions Cyclables (DRC) se sont frottés à la
> rationalisation des itinéraires et tente de maintenir à jour un
> référentiel des Véloroutes et Voies Vertes à travers l’Observatoire
> National des 3V (ON3V). Mais ils ont été obligés de traiter la données
> de manière très "géomatique" et de la décliner sous la forme de
> plusieurs bases de données. Leur travail est diffusé en "Open Data"
> (selon leurs termes) et on peut le télécharger dans différents formats
> depuis la page suivante :
> 
> 
> https://www.departements-regions-cyclables.org/observatoires/observatoire-national-des-veloroutes-et-voies-vertes/
> 
> 
> 
> Pour les utilisateur de SIG type QGIS, la couche la plus intéressante
> est N_3V_SEGMENT_L.shp. De cette couche on peut faire une analyse
> thématique sur le champ "ID_ITI" puisque chaque valeur unique de ce
> champ correspond à une "continuité" pour laquelle les way appartiennent
> au/aux même(s) itinéraire(s) cyclable(s). Le rendu avec des couleurs
> aléatoires peut être observé à l'aide des liens suivants :
> 
> 
> https://framapic.org/S7Uw3VeKvi0A/zqecqRI1Qrbd.jpg
> 
> https://framapic.org/S7Uw3VeKvi0A/zqecqRI1Qrbd?dl
> 
> 
> Chaque portion devrait correspondre aux éléments de base, c'est-à-dire
> les enfants pour constituer les itinéraires parents. Le problème est
> qu'ils ne représentent plus rien de concret et sont donc compliqués à
> maintenir. Sans oublier que les données de l'ON3V ne présentent pas tous
> les itinéraires cyclables et ignorent très probablement un grand nombre
> d'itinéraires locaux.


Concernant ces données en Open Data très utiles.
Je suis d'avis de créer une page sur le wiki qui décrit comment
exploiter le fichier, et donner la nomenclature des clés/valeurs
Il y a un fichier PDF qui peut aider
https://www.departements-regions-cyclables.org/wp-content/uploads/2016/07/2014-04-15_Notice-de-numrisation_DEFINITIF_Version-1.0.pdf

Petite anecdote, l'AF3V (Les Véloroutes et Voies Vertes de France) à un
accord avec l'IGN, j'ai appris cela il y a quelques jours. Dans la base
ON3V, il a des donnés issus de l'IGN. Donc j'imagine qu'indirectement on
va recevoir également les données générées par l'AF3V.


> Ma conclusion est qu’on peut découper les itinéraires pour mais on va
> créer énormément de petites relations pour lesquelles les tags restent
> encore affiner. Pour ma part j’aurais tendance à uniquement découper les
> grands itinéraires sur la base des étapes lorsqu’elles existent mais de
> créer une relation par itinéraire pour les plus petits itinéraires.


En effet, les étapes c'est une notion 

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Lester Caine]

On 17/01/18 09:46, Frederik Ramm wrote:

It's like clapping
your hands to the supermarket cashier every time he/she prints you the
receipt.

I had to smile at that one.


Reminds me off the developers lists where there is more traffic of the 
'I like that' than actual constructive contributions.



I think users should either be able to opt out of automatically
generated changeset comments, or perhaps such changeset comments should
only ever be generated to users who have actively opted in (the "review
requested" could be interpreted as an opt-in even though it doesn't
exactly mean that).


Requesting the review of an edit should always be optional, but for new 
editors it should be a part of the process anyway. TAGGING a changeset 
for review should not simply be a comment. OSMCha should perhaps be 
pushing feedback to the contributor and ONLY to the database when there 
is a problem. Can we keep that hand clapping to a separate channel to 
the live data in the database please?



2) I've always been using the "changesets w/comments" line of the HDYC
page to double check suspicious mappers. Usually a mapper with a ton of
commented changesets was to consider suspicious, from now on this osmcha
feature is going to add a crazy amount of positive/useless comments

Could auto-generated changeset comments be marked as such, so that HDYC
could ignore them or at least treat them as less relevant?


We live in a world where much of the traffic on social media is 
automatically generated by a bot of some sort. Adding that 'feature' to 
OSM to improve quality should be part of the edit process so it informs 
a contributor at the time, not generating feedback later. And certainly 
as with any contribution, it should be tagged in a way that you KNOW 
just how it was generated, and can filter the 'social media' 
contributions from the 'constructive' ones.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk-fr] Atelier de lutherie

[Julien Coupey]

Effectivement, le mieux semble au final être :

- shop + craft + repair pour les luthiers
- shop + repair pour les « simples » ateliers de réparation (souvent 
plutôt instruments à vent)


Dans les deux cas, musical_instrument comme clé pour préciser le type 
d'instruments.


Merci !
Julien

Le 16/01/2018 à 23:44, osm.sanspourr...@spamgourmet.com a écrit :

Si, la clé craft indique que c'est de la fabrication :

https://wiki.openstreetmap.org/wiki/Key:craft

A minima de l'artisanat.
Tu peux éventuellement ajouter qu'elle fait aussi de la réparation :
https://wiki.openstreetmap.org/wiki/Key:repair

Le 16/01/2018 à 21:11, Julien Coupey - o...@coupey.fr a écrit :

Bonsoir,

Merci pour vos réponses. Je suis parti sur la combinaison :

shop=musical_instrument
craft=musical_instrument
musical_instrument=strings (ou wind)

La seule chose qui n'est pas vraiment décrite est le fait de fabriquer 
en plus de faire de la réparation (le cas des luthiers des instruments 
du quatuor). J'ai précisé ça avec le tag description qui est 
finalement le seul où apparaît le mot luthier le cas échéant.


À+
Julien




___
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] Automatically generated changeset discussion comments by OSMCha

[Frederik Ramm]

Hi,

On 17.01.2018 09:28, Marco wrote:
> It's like clapping
> your hands to the supermarket cashier every time he/she prints you the
> receipt.

I had to smile at that one.

I think users should either be able to opt out of automatically
generated changeset comments, or perhaps such changeset comments should
only ever be generated to users who have actively opted in (the "review
requested" could be interpreted as an opt-in even though it doesn't
exactly mean that).

> 2) I've always been using the "changesets w/comments" line of the HDYC
> page to double check suspicious mappers. Usually a mapper with a ton of
> commented changesets was to consider suspicious, from now on this osmcha
> feature is going to add a crazy amount of positive/useless comments 

Could auto-generated changeset comments be marked as such, so that HDYC
could ignore them or at least treat them as less relevant?

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-cz] Izochrony

[Petr Kadlec]

2018-01-17 9:52 GMT+01:00 jzvc :

> Dne 17.1.2018 v 9:33 Václav Kubíček napsal(a):
>
>> https://www.openrouteservice.org/reach?n1=50.071647=14.50
>> 2623=10=50.06694,14.460249=0=0=30=15=en-US=km
>>
>
> Cus, nic proti, ale tohle je proste holy nesmysl. A zduvodnim ti i proc,
> tam kde sou dalnice bys ve skutecnosti mel tu zelenou zonu vyrazne
> vytazenou z praglu ven (a samozrejme v dousledku pak i tu cervenou).
>

Tam je jen nějaké rozbité GUI. Sice se to tváří, že je nastaveno přidávání
isochron, ale ve skutečnosti to přidává kružnice. Když ručně přepnu na
vzdálenost a pak zpět na čas, tak už to přidává reálně vypadající isochrony.

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

Re: [Talk-cz] Izochrony

[jozka]

I kdyz v tom odkazu nejde o cas, ale o vzdalenost?

>
>Cus, nic proti, ale tohle je proste holy nesmysl. A zduvodnim ti i proc, 
>tam kde sou dalnice bys ve skutecnosti mel tu zelenou zonu vyrazne 
>vytazenou z praglu ven (a samozrejme v dousledku pak i tu cervenou).
>
>A naopak, mel bys i ve vnitrni praze cerveny casti.
>
>Tohle mi prijde vycucany doslova z prstu a nemajici s realitou naprosto 
>nic spolecnyho.
>
>Nechces mi doufam tvrdit, ze Do Roztok pres vecne ucpanou Podbabskou 
>dojedu za stejnou dobu, jako na Zdibi po D8.
>
>Navic tomu cucani z prstu odpovida i zmena polohy toho bodu, kdyz ho 
>posunu na rekneme jizni spojku, tak se posune to +-kolecko tim smerem, 
>coz je zkratka naprosty blabol, protoze v ose ty silnice by se to melo 
>naprosto diametralne zmenit.
>
>>
>> Vašek

>

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

Re: [OSM-talk-fr] dépose-minute

[thevenon . julien]

- Mail original -
De: "Julien Noblet" 
À: "Discussions sur OSM en français" 
Envoyé: Mercredi 17 Janvier 2018 10:13:06
Objet: Re: [OSM-talk-fr] dépose-minute

> En même temps je me demande quelle est la vrai difference entre un 
> arrêt-minute et un dépose-minute. 

Sans parler texte de Loi, sur le terrain les arrets minutes que je connais sont 
une file unique, donc tu t arretes pour poser quelqu un ou prendre quelqu un et 
tu repars tout de suite parce que tu bloques tous ceux derriere toi dans la 
file.
Les depose minute que je connais sont des parkings normaux mais dont le temps 
de stationnement est tres limite,genre 20 minutes max, donc la tu peux arreter 
ta voiture aller sur le quai de gare etc

My 2 cents
Julien

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

Re: [OSM-talk-fr] dépose-minute

[Julien Noblet]

Bonjour,

J'ai récemment fait un arrêt-minute en bordure de voie,
J'ai préféré utiliser ceci:
highway=tertiary
parking:condition:left=no_parking
parking:lane:left=parallel

Pourquoi ne pas avoir parking:condition:*=kiss_and_ride ?

En même temps je me demande quelle est la vrai difference entre un
arrêt-minute et un dépose-minute.
Si quelqu'un connaît le texte de loi qui présente le dépose-minute en
France...
J'ai cherché dans les panneau officiels mais je n'ai rien trouvé (sûrement
mal cherché :) )


Librement,
Julien_N

Le mer. 17 janv. 2018 à 00:05,  a écrit :

> S'il y avait une durée maximale un maxstay ferait l'affaire. Et maxstay
> est une valeur (normalement) numérique.
>
> On est d'accord il y a au moins deux cas mais si possible autant trouver
> une méthode commune afin d'envisager une meilleure symbologie.
>
> Exemple de voie spécifique où les véhicules entrent dans la partie partie
> et il doit y a avoir 3-4 voitures maxi par zone (des délimitations
> empêchent d'entrer et sortir du parking partout) :
> https://www.openstreetmap.org/query?lat=48.44275=-4.41932.
> Exemple de parking multi-fonction : stationnement normal, tête de taxi et
> places dépose-minute :
> https://www.openstreetmap.org/query?lat=47.87105=-3.55320.
>
>
> Le 16/01/2018 à 00:42, marc marc - marc_marc_...@hotmail.com a écrit :
>
> il me semble qu'il y a 2 cas de vos exemples :
> - les places de parking que j'aurais tagé comme un parking classique,
> l'aspect "dépose minute" étant dans la durée du stationnement.
> elle-t-elle indiquée ? faut-il inventer une durée "drop off" ?
> - celle sous forme de bande oü service=drop_off parait adapté.
>
> Le 15. 01. 18 à 23:24, osm.sanspourr...@spamgourmet.com a écrit :
>
> Kiss and Ride n'est pas seulement mignon il est aussi utilisé sous cette
> forme ou sous K+R dans différents pays.
>
> Ta proposition va bien quand une voie est réservée à cela.
>
> Pas quand c'est un côté de la voirie qui sert à ça. Grosso-modo des
> places de parking avec un rôle de dépose-minute.
> service:lane:right=drop_off (à l'image des parking:lane:right) ?
>
> Un peu bizarre, non ?
>
> amenity=passenger_pick_up_drop_off sous forme de nœud à droite de la voie ?
>
> Le 14/01/2018 à 22:09, althio - althio.fo...@gmail.com a écrit :
>
> Il y a clairement un manque pour définir ces zones et voies de dépose-minute :
> En français, belle brochette de 
> name=*https://taginfo.openstreetmap.org/search?q=d%C3%A9pose+minute#values
>
> Côté anglais, kiss_and_ride est mignon, un terme moins romantique
> existe : drop off.
>
> On retrouve donc également des déclinaisons autour de "drop off" dans les 
> tags :
>
> un bon candidat :https://taginfo.openstreetmap.org/tags/service=drop_off
>
> et d'autres 
> :https://taginfo.openstreetmap.org/tags/amenity=passenger_pick_up_drop_offhttps://taginfo.openstreetmap.org/tags/?key=name=Passenger%20Pick-Up%2FDrop-Offhttps://taginfo.openstreetmap.org/tags/?key=name=Passenger%20pick-up%2Fdrop-offhttps://taginfo.openstreetmap.org/tags/?key=name=Passenger%20pick%20up%2Fdrop%20offhttps://taginfo.openstreetmap.org/tags/?key=name=Pick%20up%2FDrop%20offhttps://taginfo.openstreetmap.org/tags/?key=name=Drop%20Off%2FPick%20Uphttps://taginfo.openstreetmap.org/tags/?key=name=FWTC%20Drop%20Off%20%2F%20Pick%20Up%20Lanehttps://taginfo.openstreetmap.org/tags/note=no%20parking%20-%20only%20for%20drop-off%20and%20pick-up
>
> Rien n'est encore 
> documentéhttps://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice
> mais c'est mon candidat :
> highway=service + service=drop_off
> + fee... + maxstay...
>
> -- althio
>
>
> 2018-01-14 20:48 GMT+01:00 
> :
>
> dépose-minute se dit kiss and ride en anglais.
>
> Mot que l'on trouve :
>
> - sur le wiki... en espagnol pour no_parking. Mais c'est juste pour signaler
> une tolérance.
>
> - kiss_and_ride=yes (2 occurrences dans le monde).
>
> Ne devrait-on pas proposer la création de cette clé (et par analogie avec
> les autres clés de parking, capacity:kiss_and_ride) pour indiquer un endroit
> fait pour la dépose-minute ?
>
> Voir amenity=kiss_and_ride si on veut les distinguer des places de parking
> comme on le fait avec les places de taxi puisque ce n'est pas une vraie
> place de parking, il est fréquent que le conducteur doive rester à bord du
> véhicule.
>
> Je suis étonné de n'avoir rien trouvé car les dépose-minute sont fréquentes
> près des gares et des aéroports.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Izochrony

[jzvc]

Dne 17.1.2018 v 9:33 Václav Kubíček napsal(a):

Jako mapu dojezdových časů / vzdáleností.

Například jako zde:

https://www.openrouteservice.org/reach?n1=50.071647=14.502623=10=50.06694,14.460249=0=0=30=15=en-US=km


Cus, nic proti, ale tohle je proste holy nesmysl. A zduvodnim ti i proc, 
tam kde sou dalnice bys ve skutecnosti mel tu zelenou zonu vyrazne 
vytazenou z praglu ven (a samozrejme v dousledku pak i tu cervenou).


A naopak, mel bys i ve vnitrni praze cerveny casti.

Tohle mi prijde vycucany doslova z prstu a nemajici s realitou naprosto 
nic spolecnyho.


Nechces mi doufam tvrdit, ze Do Roztok pres vecne ucpanou Podbabskou 
dojedu za stejnou dobu, jako na Zdibi po D8.


Navic tomu cucani z prstu odpovida i zmena polohy toho bodu, kdyz ho 
posunu na rekneme jizni spojku, tak se posune to +-kolecko tim smerem, 
coz je zkratka naprosty blabol, protoze v ose ty silnice by se to melo 
naprosto diametralne zmenit.




Vašek

__
 > Od: Marián Kyral 
 > Komu: "OpenStreetMap Czech Republic" 
 > Datum: 17.01.2018 08:53
 > Předmět: Re: [Talk-cz] Izochrony
 >


-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 7:37:32
Předmět: [Talk-cz] Izochrony

Ahoj,

neplánuje se přidat použití izochron i do openstreetmap.cz?

Já určitě ne. Abych se přiznal, moc netuším, k čemu je to dobré :-)

Jak by sis to představoval? Ale klidně na to udělej na Githubu issue.

Marián

Vašek

__
 > Od: Tom Ka 
 > Komu: OpenStreetMap Czech Republic ,
 > Datum: 14.01.2018 08:25
 > Předmět: [Talk-cz] WeeklyOSM CZ 389
 >

Ahoj, je dostupné vydání 389 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/9835

* Archiv talk-cz na osmap.cz.
* Nahrávání rozcestníků.
* Kontrola routování přestupů.
* Umístění tagu s adresou.
* 10 let mapperem.
* Mapa majáků v Evropě.
* Bitcoiny pro Nadaci OSM.
* Konec Mapzenu.
* Hranice Belgie-Holandsko.
* Open source satelit.

Pěkné počtení ...

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



--

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


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




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

Re: [Talk-cz] Izochrony

[Petr Slavíček , Bc .]

Odkud, kam?
-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 9:51:07
Předmět: Re: [Talk-cz] Izochrony
"
Nemyslel jsem zrovna hromadnou dopravu, na kterou jsou jízdní řády potřeba,
ale jen např. dojezdovou vzdálenost autem, na kole případně pěšky.

V.

__
> Od: Mikoláš Štrajt 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 17.01.2018 09:40
> Předmět: Re: [Talk-cz] Izochrony
>
K tomu jsou potřeba data jízdních řádů. A ty v OSM nejsou a ani tam nepatří.
Takže je to trochu offtopic.

Nicméně ta data existují a už je možné je importovat do vlastních aplikací.
Např. já takhle pokusně provozuju http://jizdnirady.svita.cz/pid

Viz http://opendata.praha.eu/dataset/dpp-jizdni-rady pro zdroj dat.

--
Severák

-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 9:34:45
Předmět: Re: [Talk-cz] Izochrony
"
Jako mapu dojezdových časů / vzdáleností.

Například jako zde:

https://www.openrouteservice.org/reach?n1=50.071647=14.502623=10=
50.06694,14.460249=0=0=30=15=en-US=km

 

Vašek

 

__
> Od: Marián Kyral 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 17.01.2018 08:53
> Předmět: Re: [Talk-cz] Izochrony
>

-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 7:37:32
Předmět: [Talk-cz] Izochrony
"
Ahoj,

neplánuje se přidat použití izochron i do openstreetmap.cz?

 
 "
 

Já určitě ne. Abych se přiznal, moc netuším, k čemu je to dobré :-)

Jak by sis to představoval? Ale klidně na to udělej na Githubu issue.

 

Marián

 
 "
 

Vašek

__
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic ,
> Datum: 14.01.2018 08:25
> Předmět: [Talk-cz] WeeklyOSM CZ 389
>
Ahoj, je dostupné vydání 389 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/9835
(http://www.weeklyosm.eu/cz/archives/9835)

* Archiv talk-cz na osmap.cz.
* Nahrávání rozcestníků.
* Kontrola routování přestupů.
* Umístění tagu s adresou.
* 10 let mapperem.
* Mapa majáků v Evropě.
* Bitcoiny pro Nadaci OSM.
* Konec Mapzenu.
* Hranice Belgie-Holandsko.
* Open source satelit.

Pěkné počtení ...

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

--

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

--

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

Re: [Talk-cz] Izochrony

[Václav Kubíček]

Nemyslel jsem zrovna hromadnou dopravu, na kterou jsou jízdní řády potřeba, ale 
jen např. dojezdovou vzdálenost autem, na kole případně pěšky.
V.
__

Od: Mikoláš Štrajt 
Komu: "OpenStreetMap Czech Republic" 
Datum: 17.01.2018 09:40
Předmět: Re: [Talk-cz] Izochrony


K tomu jsou potřeba data jízdních řádů. A ty v OSM nejsou a ani tam nepatří. 
Takže je to trochu offtopic.

Nicméně ta data existují a už je možné je importovat do vlastních aplikací. 
Např. já takhle pokusně provozuju http://jizdnirady.svita.cz/pid

Viz http://opendata.praha.eu/dataset/dpp-jizdni-rady pro zdroj dat.

--
Severák

-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 9:34:45
Předmět: Re: [Talk-cz] Izochrony 
Jako mapu dojezdových časů / vzdáleností.

Například jako zde:
https://www.openrouteservice.org/reach?n1=50.071647=14.502623=10=50.06694,14.460249=0=0=30=15=en-US=km
 
Vašek
 
__
> Od: Marián Kyral 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 17.01.2018 08:53
> Předmět: Re: [Talk-cz] Izochrony
>

-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 7:37:32
Předmět: [Talk-cz] Izochrony 
Ahoj,

neplánuje se přidat použití izochron i do openstreetmap.cz?
 
 
Já určitě ne. Abych se přiznal, moc netuším, k čemu je to dobré :-)
Jak by sis to představoval? Ale klidně na to udělej na Githubu issue.
 
Marián
 
 
Vašek
__
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic ,
> Datum: 14.01.2018 08:25
> Předmět: [Talk-cz] WeeklyOSM CZ 389
>
Ahoj, je dostupné vydání 389 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/9835 


* Archiv talk-cz na osmap.cz.
* Nahrávání rozcestníků.
* Kontrola routování přestupů.
* Umístění tagu s adresou.
* 10 let mapperem.
* Mapa majáků v Evropě.
* Bitcoiny pro Nadaci OSM.
* Konec Mapzenu.
* Hranice Belgie-Holandsko.
* Open source satelit.

Pěkné počtení ...

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

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

--

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

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

--

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


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

Re: [Talk-cz] Izochrony

[Mikoláš Štrajt]

K tomu jsou potřeba data jízdních řádů. A ty v OSM nejsou a ani tam nepatří.
Takže je to trochu offtopic.

Nicméně ta data existují a už je možné je importovat do vlastních aplikací.
Např. já takhle pokusně provozuju http://jizdnirady.svita.cz/pid

Viz http://opendata.praha.eu/dataset/dpp-jizdni-rady pro zdroj dat.

--
Severák

-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 9:34:45
Předmět: Re: [Talk-cz] Izochrony
"
Jako mapu dojezdových časů / vzdáleností.

Například jako zde:

https://www.openrouteservice.org/reach?n1=50.071647=14.502623=10=
50.06694,14.460249=0=0=30=15=en-US=km

 

Vašek

 

__
> Od: Marián Kyral 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 17.01.2018 08:53
> Předmět: Re: [Talk-cz] Izochrony
>

-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 7:37:32
Předmět: [Talk-cz] Izochrony
"
Ahoj,

neplánuje se přidat použití izochron i do openstreetmap.cz?

 
 "
 

Já určitě ne. Abych se přiznal, moc netuším, k čemu je to dobré :-)

Jak by sis to představoval? Ale klidně na to udělej na Githubu issue.

 

Marián

 
 "
 

Vašek

__
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic ,
> Datum: 14.01.2018 08:25
> Předmět: [Talk-cz] WeeklyOSM CZ 389
>
Ahoj, je dostupné vydání 389 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/9835
(http://www.weeklyosm.eu/cz/archives/9835)

* Archiv talk-cz na osmap.cz.
* Nahrávání rozcestníků.
* Kontrola routování přestupů.
* Umístění tagu s adresou.
* 10 let mapperem.
* Mapa majáků v Evropě.
* Bitcoiny pro Nadaci OSM.
* Konec Mapzenu.
* Hranice Belgie-Holandsko.
* Open source satelit.

Pěkné počtení ...

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

--

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

Re: [Talk-cz] opendata Agentura ochrany přírody a krajiny ČR

[Marián Kyral]

-- Původní e-mail --
Od: Jan Macura 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 1. 2018 18:34:27
Předmět: Re: [Talk-cz] opendata Agentura ochrany přírody a krajiny ČR
"




2018-01-16 17:08 GMT+01:00 Matej Lieskovský :
"
"#tooLate"


Nechápu proč by mělo být moc pozdě.
Ano, vypustili data pod licencí CC-BY 4.0.

Ne, pro použití v OSM to nestačí.

Ano, nejspíše si umíme vyjednat povolení.

Nevidím, jak nám může vadit to, že ta data už jsou na Wikidata.




Uniká mi něco?

"



Uniká ti ta souvislost, že nám to právě vůbec nevadí a už nemáme co
vyjednávat. Wikidata jsou CC-0, tj. kdokoli může začít importovat památné
stromy do OSM (už víc jak rok).





"



Wikidata jsou nějaká univerzální pračka na špinavá data? Aneb, jak se z CC
4.0 stane CC-0?




Marián



"






H.




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

Re: [Talk-cz] Izochrony

[Václav Kubíček]

Jako mapu dojezdových časů / vzdáleností.
Například jako zde:
https://www.openrouteservice.org/reach?n1=50.071647=14.502623=10=50.06694,14.460249=0=0=30=15=en-US=km
 
Vašek
 
__

Od: Marián Kyral 
Komu: "OpenStreetMap Czech Republic" 
Datum: 17.01.2018 08:53
Předmět: Re: [Talk-cz] Izochrony



-- Původní e-mail --
Od: Václav Kubíček 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 1. 2018 7:37:32
Předmět: [Talk-cz] Izochrony 
Ahoj,

neplánuje se přidat použití izochron i do openstreetmap.cz?
 
 
Já určitě ne. Abych se přiznal, moc netuším, k čemu je to dobré :-)
Jak by sis to představoval? Ale klidně na to udělej na Githubu issue.
 
Marián
 
 
Vašek
__
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic ,
> Datum: 14.01.2018 08:25
> Předmět: [Talk-cz] WeeklyOSM CZ 389
>
Ahoj, je dostupné vydání 389 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/9835 


* Archiv talk-cz na osmap.cz.
* Nahrávání rozcestníků.
* Kontrola routování přestupů.
* Umístění tagu s adresou.
* 10 let mapperem.
* Mapa majáků v Evropě.
* Bitcoiny pro Nadaci OSM.
* Konec Mapzenu.
* Hranice Belgie-Holandsko.
* Open source satelit.

Pěkné počtení ...

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

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

--

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


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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Marco]

Agree with you, I don't really like this feature, mainly for two reasons:

1) I see myself as a quite experienced mapper and I guess pretty much 
99% of my edits improved the map, I think it's nice to see that someone 
double checks some of my edits using osmcha or achavi, but I also think 
there's actually no need to add a comment saying that my edit "looks 
great". I reckon it might be useful when dealing with new mappers as 
adding a comment saying "you're doing a great job, keep it up" might 
improve the new mapper's motivation, but shelling my email address with 
emails from osm, saying that someone added a comment (automatic and 
useless) to one of my changeset does only annoy me. It's like clapping 
your hands to the supermarket cashier every time he/she prints you the 
receipt.


2) I've always been using the "changesets w/comments" line of the HDYC 
page to double check suspicious mappers. Usually a mapper with a ton of 
commented changesets was to consider suspicious, from now on this osmcha 
feature is going to add a crazy amount of positive/useless comments and 
then looking at the number of changesets with comments of a mapper is 
not going to be useful anymore. It also makes things more complex when 
trying to double check a mapper which already saved hundreds of changesets.


Cheers

Marco


Il 12/01/2018 15:07, Michael Reichert ha scritto:

Hi,

OSMCha started posting comments to changesets a few days ago when a user
marks a changeset as good or bad.
https://www.openstreetmap.org/user/wille/diary/43101
I would like to ask the author(s) of OSMCha to disable this feature.

We expect to read all mappers incoming message (personal messages and
changeset comments). If third-party tools start to post comments to lots
of changesets automatically, this is some kind of spamming. If OSM sends
to much emails to a user, the user will probably ignore them or treat
them as spam.

I think that OSMCha should not post a comment automatically except if
the user has explicitly asked for feedback or there are quality issues
regarding the edit (mistakes, vandalism, guideline violations or
anything else which makes it necessary to talk to the user).

I post this email to this mailing list instead of filing a bug report a
Github [1] because I want to bring this problem to the wider audience
and initiate a general discussion on the acceptable usage of the
changeset comments API.

What are your thoughts and opinions on this issue?

Best regards

Michael


[1] Btw, which Github repository would be the correct one the file the
bug report at?
https://duckduckgo.com/?q=osmcha+github=ffsb=web




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


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