Re: [OSM-talk-fr] SPAM, Re: Chemins publics / privés / ouverts / fermés

[Arnaud Champollion]

Le 04/01/2020 à 23:49, Brice a écrit :
Sur mon ancienne commune, j'avais exploré tous les chemins indiqués 
sur la carte IGN 25OOOème et j'ai fait le choix de conserver une 
information de l'existence de ces anciens chemins vus sur le terrain 
comme des haies (deux à trois fois plus larges que la "normale") et 
existants sur le cadastre, exemples :

https://www.openstreetmap.org/way/288052468
https://www.openstreetmap.org/way/223022137



Du coup d'un point de vue données, c'est une ligne sans attribut ?








J'ai considéré que cela pourrait éviter que ces ex-chemins soit 
abusivement cartographiés sur base d'une source autre que le terrain 
et que l'information restait intéressante pour les aménageurs du 
territoire, par exemple si la commune envisageait de ré-ouvrir des 
chemins pour création d'un circuit de randonnée. 




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

Re: [talk-au] Bush Fire Neighbourhood Safer Places

[adam steer]

Thanks David - seems all the eastern states speak the same language. So
Andrew’s suggestion here:

https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Bushfire_Places_of_last_resort

...looks good.

Victoria CFA's wikidata entry is https://www.wikidata.org/wiki/Q13632973

Cheers, and thanks

Adam







On Sat, 4 Jan 2020 at 18:57, David Wales  wrote:

> According to the NSW RFS:
>
> "Neighbourhood Safer Places are a place of last resort during a bush fire
> emergency.
>
> They are to be used when all other options in your bush fire survival plan
> can't be put into action safely."
>
> https://www.rfs.nsw.gov.au/plan-and-prepare/neighbourhood-safer-places
>
> On 4 January 2020 6:11:15 pm AEDT, Graeme Fitzpatrick <
> graemefi...@gmail.com> wrote:
>>
>>
>>
>>
>> On Sat, 4 Jan 2020 at 12:21, adam steer  wrote:
>>
>>>
>>> In Vic these are only used as a last resort. Not sure if 'assembly
>>> point' translates to 'only come here if there are absolutely no other
>>> options, and this place might not be safe anyway'.
>>>
>>>
>>> It seems that 'neighbourhood safer places' means something different
>>> across borders. Can anyone in emergency services comment?
>>>
>>
>> The Qld version is similar
>> https://www.ruralfire.qld.gov.au/BushFire_Safety/Neighbourhood-Safer-Places/Pages/default.aspx
>>
>> "An NSP is a local open space or building where people may gather, as a
>> last resort, to seek shelter from a bushfire."
>>
>>   Thanks
>>
>> Graeme
>>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>


-- 
Dr. Adam Steer
http://spatialised.net
https://www.researchgate.net/profile/Adam_Steer
http://au.linkedin.com/in/adamsteer
http://orcid.org/-0003-0046-7236
+61 427 091 712 ::  @adamdsteer

Suits are bad for business: http://www.spatialised.net/business-penguins/
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-es] Urgent translation request

[European Water Project]

Hola, Buenos dias,

The person who agreed to translate the wiki instructions from English to
Spain for adding fountains in OpenStreetMap and fountains of photos to
wikimedia commons is not responding.  Can someone or some people please
help out with this?

We will be making a 8 minute presentation of our 100% open data and
collaborative project to 860 students from 48 countries at the United
Nations on Wednesday, 8th of January.  Here is a link to our project
https://europeanwaterproject.org

We currently have instructions in English, French, Italian and Dutch.

Here is the link to Spanish wiki instruction page.  From experience with
the other languages, the page translation should take about 3-4 hours.
Translation is done directly inline on the wiki.
https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/es


Thank you for your consideration.

Happy new year to all,

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

Re: [talk-au] Fire Station Operators

[Andrew Harvey]

Yes, this is
https://wiki.openstreetmap.org/wiki/Good_practice#One_feature.2C_one_OSM_element,
there should only be one amenity=fire_station for a single fire station.

Where possible I prefer to trace the site boundary as this can be useful
information and put all the tags on that, and then just have a way inside
it with building=yes an none of the fire station tags.

But I think it's also fine to just have a node, or to just have the
building without the site as interim solutions or for fire stations where
the extent is just the building which don't have a yard.

On Sun, 5 Jan 2020 at 15:27, David Wales  wrote:

> Somewhat related to this.
>
> Camden West Rural Fire Service has both a traced building, *and* a traced
> site border.
> Both are currently tagged with amenity=fire_station.
>
> The building has the rest of the identifying tags.
>
> I feel that it makes sense to only have one feature tagged with
> amenity=fire_station, and the rest of the tags. Should this be the
> building, or the site border?
>
> See link below:
>
> https://www.openstreetmap.org/edit?editor=id=724460466#map=20/-34.05818/150.67674
>
> Regards,
> David Wales
>
> On 4/1/20 2:39 pm, Andrew Harvey wrote:
>
> On Sat, 4 Jan 2020 at 14:14, Sebastian Spiess  wrote:
>
>> Andrew,
>> I've done one. Just clarifying regarding the branch.
>>
>> branch  =   Narrabeen Fire Station
>> name   =  Fire and Rescue NSW Station 068 Narrabeen
>>
>
> I can't see clearly from Mapillary what the singe looks like, but branch
> should be just "Narrabeen", without the "Fire Station" words. Then you
> could still have name=Narrabeen Fire Station.
>
>
>> Is this how you suggested? Before the branch tag was the name.
>>
>> I've also added
>> building =fire_station
>>
>> https://www.openstreetmap.org/changeset/79179815
>>
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

[David Wales]

Somewhat related to this.

Camden West Rural Fire Service has both a traced building, *and* a
traced site border.
Both are currently tagged with amenity=fire_station.

The building has the rest of the identifying tags.

I feel that it makes sense to only have one feature tagged with
amenity=fire_station, and the rest of the tags. Should this be the
building, or the site border?

See link below:
https://www.openstreetmap.org/edit?editor=id=724460466#map=20/-34.05818/150.67674

Regards,
David Wales

On 4/1/20 2:39 pm, Andrew Harvey wrote:
> On Sat, 4 Jan 2020 at 14:14, Sebastian Spiess  > wrote:
>
> Andrew,
> I've done one. Just clarifying regarding the branch.
>
> branch  =   Narrabeen Fire Station
> name   =  Fire and Rescue NSW Station 068 Narrabeen
>
>
> I can't see clearly from Mapillary what the singe looks like, but
> branch should be just "Narrabeen", without the "Fire Station" words.
> Then you could still have name=Narrabeen Fire Station.
>  
>
> Is this how you suggested? Before the branch tag was the name.
>
> I've also added
> building =    fire_station
>
> https://www.openstreetmap.org/changeset/79179815
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au



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

[talk-au] Calling all geogeeks in the Sydney region!

[Andrew Harvey]

For those in in Sydney, quoting from John Bryant's announcement at
https://t.co/r80D9yNw0h?amp=1 ...

With Andrew Harvey & Stella Blake-Kelly, we're pulling together an
informal, hands-on, geospatial social hacking/training/meetup session,
around the general theme of bushfires and maps.

A couple of ideas for activities (but also, bring your own ideas):
- OSM mapathon (mapping & tagging isolated buildings, bushland, and other
relevant points of interest)
- desktop mapping and coding with various sources of bushfire spatial data

It's about learning, sharing what you know, and making friends in the
geospatial community. All welcome. Bring a laptop!

When: Thursday 9th January, 6pm
Where: Vibewire, 525 Harris St, Ultimo

Huge thanks to Vibewire for providing the space, and OSGeo Oceania for
providing pizza.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] presenting #NorthernBeachesSolar pet project

[Graeme Fitzpatrick]

Been following with interest - after all, don't we all need something *else*
to map ‽ :-)

Please have a look at
https://www.openstreetmap.org/edit?way=631189377#map=19/-33.81607/150.99852 ,
which I spotted while fixing phone numbers.

So would you draw individual boxes around each of those 15 sets of panels &
tag each one as a separate node?

Thanks

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

Re: [talk-au] RapID roads now available for Australia

[Andy Townsend]

On 05/01/2020 00:39, Dion Moult wrote:

I came across some feedback on the quality of RapID in Australia:

https://en.osm.town/@rory/103419495240060182


"detecting walls as roads" was pretty much the original problem with 
Facebook AI additions to OSM (in Egypt), and that had to be completely 
reverted.  That situation is different to this though - with their 
current version they're using humans to sanity check the suggested 
additions and press the button, so _hopefully_ we won't see the same 
issues as then.


That said, in other circumstances ("suggested tag edits" by iD and some 
of the ropier MapRoulette challenges) we do see some pretty iffy 
human-validated edits going through, so it does make sense to keep an 
eye on these.



On Sun, Jan 05, 2020 at 11:34:04AM +1100, Sebastian Spiess wrote:

HI,

it is now, however it seems they did not use the NSW LPI images but
their own...

Australia 2019-12-30 Facebook's Map With AI - Maxar Imagery


That's also an issue on the other side of the world in the UK.  I had a 
look at an army base up the road from me that had lots of unmapped 
service roads on it.  RapiD did detect some of the missing roads (and to 
be fair I didn't see many false positives), but what it did detect was 
significantly offset from "known good" imagery.  Again, I guess an 
experienced mapper could correct that, but it might need a bit of 
education first.


Best Regards,

Andy



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

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Jérôme Amagat]

Le sam. 4 janv. 2020 à 22:27, Vincent de Château-Thierry 
a écrit :

>
> Le 04/01/2020 à 15:03, Georges Dutreix via Talk-fr a écrit :
> > Le 04/01/2020 à 13:06, Sébastien Dinot a écrit :
> >> Christian Quest a écrit :
>
> > J'en ai découvert un récemment que je trouve très utile.
> >
> > *Maj-U / Unselect nodes*
> > Si on veut déplacer une grosse poignée de maisons pour les repositionner
> > sur BD Ortho IGN par exemple, une sélection rectangulaire attrape des
> > noeuds d'autres bâtiments, de rues, ou des POIs. Maj-U ne conserve que
> > des "ways".
> >
> > il nécessite utilsplugin2 :
> > https://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2
>
> Merci je ne connaissais pas. Pour un besoin identique (sélectionner des
> bâtiments) j'apprécie Maj-E qui sélectionne les ways adjacents à la
> sélection. Quand on pense avoir sélectionné tous les buildings
> partageant des nœuds afin de les déplacer en cohérence, un coup de Maj-E
> permet de garantir que *tous* bougeront ensemble.
>
> Je profite du fil et de l'illustration partagée par Vincent (merci :) )
> pour évoquer que je n'ai jamais réussi à faire fonctionner les
> raccourcis qui sont des chiffres (Zoom sur le calque, la sélection, zoom
> précédent, etc) sous Ubuntu, alors que je m'en sers sous Windows. Je ne
> sais pas si c'est juste moi (mais même constat sur plusieurs postes), ou
> si c'est connu ? (je n'ai pas regardé dans le trac de josm avant de poster)
>
> J'ai le même problème, sous ubuntu aussi, j'ai modifié les raccourcis en
mettant pour le 3 "Zoom la sélection" (celui que j'utilise le plus) :
"guillemets". pour le 1 "Zoom sur donnée" c'est "esperluette" pour le reste
je sais pas et je les utilises pas...

sinon ceux que j’utilises :
"F" et "alt + X " je les utilises beaucoup
maj + R : ajouter les tags de la sélection precedente
maj + J : fusionner 2 surfaces, utile par exemple quand on ajoute le bati
avec le cadastre et qu'il faut fusionner des bâtiments
ctr + alt + V : coller un ou plusieurs objets (node way ou relation) dans
un calque que l'on a copié (ctr + c) dans un autre calque (pareil bien
utile pour ajouter des bâtiments avec le cadastre charger dans un autre
calque)
ctr + maj + V : coller les tags de l'objet que l'on a copier avant (ctr + c)
ctr + maj + G : remplacer la géométrie
+ et - : pour zoomer et de-zoomer :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Stop area groups

[Kevin Kofler]

liberalerhuman...@wikipedia.at wrote:
> Wie ist bei dem komischen Konstrukt die Zusammengehörigkeit der einzelnen
> Stop areas ersichtlich?

Durch die Metarelation vom Typ stop_area_group.

> Wird diese von den für das ÖPNV-Schema nie so zahlreichen Nutzern
> erkannt?

Wahrscheinlich nicht von allen.

Kevin Kofler


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

Re: [OSM-talk] JOSM: Display time of a gpx track

[tshrub]

Am 04.01.20 um 19:45 schrieb Martin Koppenhoefer:



sent from a phone


On 4. Jan 2020, at 12:37, tshrub  wrote:

I wanted to add the coordinates in certain photos (exiftool) ...



are you aware that Josm has functionality to add coordinates from a gpx track 
to list of photos (and write it back to the jpg exif tags)?


ah - I remember! ...
thx

that works fine. great!


best, t.





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





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

Re: [Talk-at] Stop area groups

[Kevin Kofler]

andreas wecer wrote:

> Am Sa., 4. Jan. 2020 um 12:34 Uhr schrieb Robin Däneke <
> robin.daen...@live.at>:
> 
>> Man könnte den User der das macht aber auch mal fragen, warum. Und ob er
>> es nicht vielleicht zumindest etwas geographischer angehen könnte.
>>
>> Falls es sich dabei um den User Diego Sanguinetti handelt, der scheint
>> für diese MAPS.me subway Gruppe zu mappen. Die haben ja leider auch eine
>> eigene Vorstellung wie die Daten aussehen sollen...
>>
> 
> Ja, es handelt sich in beiden Fällen um diesen User und Kevin hat das
> schon getan: https://www.openstreetmap.org/changeset/78848893

Derselbe User hat übrigens auch versucht, die Straßenbahnhaltestellen, die 
von der WLB mitbenützt werden, zu Eisenbahnhaltestellen oder stellenweise 
sogar Bahnhöfen "upzugraden", was ich bereits rückgängig gemacht habe (weil 
etwa die Haltestelle Mayerhofgasse nun wirklich kein Bahnhof ist), siehe:
https://www.openstreetmap.org/changeset/78833648 (auch die Diskussion)
https://www.openstreetmap.org/changeset/78994155 (meine Reparatur)

Kevin Kofler


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

Re: [Talk-at] Stop area groups

[Kevin Kofler]

PS:

Kevin Kofler wrote:
> Die neuesten Änderungen dieser Art in Wien stammen von Daniel Sanguinetti,

Sorry, Diego Sanguinetti, nicht Daniel.

> einem Peruaner, der (laut History) weltweit editiert. Z.B.:
> https://www.openstreetmap.org/changeset/78848893
> 
> Aber er ist nicht der einzige, der dieses Splitting in Wien betrieben hat.

Kevin Kofler


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

Re: [Talk-at] Stop area groups

[Kevin Kofler]

Stefan Tauner via Talk-at wrote:
> exakt deiner Meinung. Allerdings wäre es wünschenswert die Motivation
> der/des Ändernden zu erfahren.

Die neuesten Änderungen dieser Art in Wien stammen von Daniel Sanguinetti, 
einem Peruaner, der (laut History) weltweit editiert. Z.B.:
https://www.openstreetmap.org/changeset/78848893

Aber er ist nicht der einzige, der dieses Splitting in Wien betrieben hat.

Kevin Kofler


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

Re: [talk-au] RapID roads now available for Australia

[Dion Moult]

I came across some feedback on the quality of RapID in Australia:

https://en.osm.town/@rory/103419495240060182

On Sun, Jan 05, 2020 at 11:34:04AM +1100, Sebastian Spiess wrote:
>HI,
> 
>it is now, however it seems they did not use the NSW LPI images but
>their own...
> 
>Australia 2019-12-30 Facebook's Map With AI - Maxar Imagery
> 
>On 31/12/19 12:10 pm, Andrew Davidson wrote:
> 
>On Tue, Dec 31, 2019 at 10:40 AM Phil Wyatt <[1]p...@wyatt-family.com>
>wrote:
> 
>RapID roads now available for Australia
> 
> 
>But not in the list of downloads:
>[2]https://github.com/facebookmicrosites/Open-Mapping-At-Facebook/wiki/
>Available-Countries
> 
> ___
> Talk-au mailing list
> [3]Talk-au@openstreetmap.org
> [4]https://lists.openstreetmap.org/listinfo/talk-au
> 
> References
> 
>1. mailto:p...@wyatt-family.com
>2. 
> https://github.com/facebookmicrosites/Open-Mapping-At-Facebook/wiki/Available-Countries
>3. mailto:Talk-au@openstreetmap.org
>4. https://lists.openstreetmap.org/listinfo/talk-au

-- 
Dion Moult


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

Re: [talk-au] RapID roads now available for Australia

[Sebastian Spiess]

HI,
it is now, however it seems they did not use the NSW LPI images but
their own...

Australia   2019-12-30  Facebook's Map With AI - Maxar Imagery



On 31/12/19 12:10 pm, Andrew Davidson wrote:
> On Tue, Dec 31, 2019 at 10:40 AM Phil Wyatt  > wrote:
>
> RapID roads now available for Australia
>
>  
>
> But not in the list of downloads:
> https://github.com/facebookmicrosites/Open-Mapping-At-Facebook/wiki/Available-Countries
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


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

Re: [talk-au] presenting #NorthernBeachesSolar pet project

[Sebastian Spiess]

I had a look the Tasking Manager.
Do I understand it correct that I would need to set-up a (local) tasking
manager instance for myself?
The wiki does not list any Tasking Manager in AU. Does anyone have one
up an running or is there one that is good to use for this?


On 4/1/20 9:20 am, Andrew Harvey wrote:
> Nice work, would love to see more roof top solar panels mapped.
>
> The Tasking
> Manager https://wiki.openstreetmap.org/wiki/Tasking_Manager might suit
> this better than MapRoulette, since Tasking Manager breaks an area up
> into tiles and you go in, choose a tile, complete it, then upload. It
> helps track progress, avoid conflicts and ensures a whole area is done
> without gaps in coverage.
>
> MapRoulette works differently, it's based on identifying features
> already which need some work.
>
> > start_date=* - set to the date of the LPI NSW Imagery - or should
> this be rather source:date=*??
>
> start_date is when the feature started, so when the solar panel was
> installed, you can just do  if you only know the year or -MM
> if you only know the month, but if you don't know you can omit it.
> source:date is better for the imagery date.
>
> On Thu, 2 Jan 2020 at 08:50, Sebastian S.  > wrote:
>
> So far I have not worked out a good grid method.
> I go by suburb in my area and keep the file local until I've
> completed the suburb. Only then I upload.
> While offline I use a temporary area tagged as wood. I expand this
> box over the area I've worked through. This is just because I
> don't know any better solution. 
>
> If you want to see a map showing the modules you can use open
> infrastructure map, link is at the bottom of the wiki.
>
> I thought about making this a mapping challenge on
> https://wiki.openstreetmap.org/wiki/MapRoulette but so far I've
> not looked into it. I've got no experience with this but am happy
> to receive guidance.
>
>
> On 2 January 2020 7:11:07 am AEDT, Dion Moult  > wrote:
>
> On Wed, Jan 01, 2020 at 11:29:13PM +1100, Sebastian Spiess wrote:
>
> I'd like to present my latest pet project:
> 
> https://wiki.openstreetmap.org/wiki/User:ConsEbt/NorthernBeachesSolar
> I wanted to share this and collect some feedback or comments. 
>
>
> I love it! I might do a bit of solar mapping too! How easy is it to 
> set a grid
> to know which areas have been mapped?
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [OSM-talk-fr] Chemins publics / privés / ouverts / fermés

[Brice]

Le 03/01/2020 à 17:37, Arnaud Champollion a écrit :
(...)
Du point de vue du terrain, ces chemins n'existent pas, dans le sens où ils sont quasi-invisibles et impraticables. 
C'est presque un "cas numéro 5",  je dirais qu'ils devraient pas être du tout sur OSM.


C'est un cas fréquent dans le cas de chemins ruraux qui ne sont plus utilisés pour accéder à des parcelles donc pas 
empruntés par les agriculteurs donc embroussaillés, ou intégrés dans un champ.


Sur mon ancienne commune, j'avais exploré tous les chemins indiqués sur la carte IGN 25OOOème et j'ai fait le choix de 
conserver une information de l'existence de ces anciens chemins vus sur le terrain comme des haies (deux à trois fois 
plus larges que la "normale") et existants sur le cadastre, exemples :

https://www.openstreetmap.org/way/288052468
https://www.openstreetmap.org/way/223022137

J'ai considéré que cela pourrait éviter que ces ex-chemins soit abusivement cartographiés sur base d'une source autre 
que le terrain et que l'information restait intéressante pour les aménageurs du territoire, par exemple si la commune 
envisageait de ré-ouvrir des chemins pour création d'un circuit de randonnée.


--
Brice

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

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Daniel addressed this if you reread his email and proposal.  Basically we
look for local mappers first.  If we don't find any we increase the
distance for local.

At the moment we are discussing the stats can sourced data.

My feeling is let's get this import moving once more and to do that let's
aim at those areas with good data, a local mapper or two and we can tackle
the more complex ones later.

Those areas with no local mappers are also areas where we probably need to
use Microsoft or another source of data.  Each separate source will need a
separate overall import plan together with "subplans" which is what I'll
call Daniel's idea of tackling the stat can data an area at a time.

Cheerio John

On Sat, Jan 4, 2020, 4:07 PM Matthew Darwin,  wrote:

> Hello all,
>
> Happy to see progress here.
>
> My ongoing question is how to define that a "local" group has determined
> that an import can proceed.   And more specifically what is "local"? There
> are rural and remote parts of Canada which have in the order of zero active
> mappers or sense of a local community.  How do we consensus around imports
> there? Can we get agreement by (part-of) province/territory where there is
> not some other group that puts their hand up?  (maybe use admin level 5
> boundaries, with holes for big cities)
>
> I just want to make sure we don't stop at doing imports only for big
> cities. Buildings are important for the whole country.
> On 2020-01-04 10:09 a.m., Nate Wessel wrote:
>
> Hi Daniel,
>
> Thank you for all the work you've put into this. I'd like to offer a
> couple suggestions and/or clarifications for your proposed import process,
> overview though it is.
>
> First, I think it is very important that a tasking manager is set up on a
> city/by city basis only, and that only AFTER consensus is achieved that the
> import should proceed in that area. I would really like to avoid seeing the
> massive nationwide tasking that was set up the first time around. We should
> be making it hard for people to go rogue in regions where consensus for an
> import doesn't (yet) exist.
>
> Related to this, though important enough to be a second point in it's own
> right, the tasking squares need to be small enough that a single user can
> manage them and inspect every single building in a task. The first round of
> import used task squares that were massive, and which couldn't be divided
> any further past a certain point. Even in rural areas, it is likely
> inappropriate to import areas larger than 1km^2. In central Toronto it
> would be (and was) idiotic. An import that doesn't take local scale into
> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
> big to import in my opinion and is not a good enough benchmark for import
> batch sizing.
>
> That is, each import needs to be local, and not just in a superficial
> sense.
>
> I'll also add that the issue of conflation doesn't seem to have been
> worked out yet except to note that it is an issue. What will we do with the
> millions of buildings which will substantially overlap/duplicate existing
> buildings or imports? This needs to be worked out in detail before anything
> starts up again.
>
> And what needs to be done about already existing low quality imports? It's
> good to acknowledge their existence, but what will be done about them?
> We've set up a task to clean up some of the mess in Toronto (
> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
> iceberg.
>
> Again, I thank everyone for their time and effort on this - we can get
> this done if we go slow and do it right :-)
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. 

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Vincent de Château-Thierry]

Le 04/01/2020 à 15:03, Georges Dutreix via Talk-fr a écrit :

Le 04/01/2020 à 13:06, Sébastien Dinot a écrit :

Christian Quest a écrit :



J'en ai découvert un récemment que je trouve très utile.

*Maj-U / Unselect nodes*
Si on veut déplacer une grosse poignée de maisons pour les repositionner 
sur BD Ortho IGN par exemple, une sélection rectangulaire attrape des 
noeuds d'autres bâtiments, de rues, ou des POIs. Maj-U ne conserve que 
des "ways".


il nécessite utilsplugin2 : 
https://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2


Merci je ne connaissais pas. Pour un besoin identique (sélectionner des 
bâtiments) j'apprécie Maj-E qui sélectionne les ways adjacents à la 
sélection. Quand on pense avoir sélectionné tous les buildings 
partageant des nœuds afin de les déplacer en cohérence, un coup de Maj-E 
permet de garantir que *tous* bougeront ensemble.


Je profite du fil et de l'illustration partagée par Vincent (merci :) ) 
pour évoquer que je n'ai jamais réussi à faire fonctionner les 
raccourcis qui sont des chiffres (Zoom sur le calque, la sélection, zoom 
précédent, etc) sous Ubuntu, alors que je m'en sers sous Windows. Je ne 
sais pas si c'est juste moi (mais même constat sur plusieurs postes), ou 
si c'est connu ? (je n'ai pas regardé dans le trac de josm avant de poster)


vincent

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

Re: [talk-au] presenting #NorthernBeachesSolar pet project

[Andrew Harvey]

Older images aren't published as far as I know. I think source:date is good
enough, since as you say you don't know the installation date of the solar,
it could have been this year, last year, the year before, etc. If you know
the exact year I think it's worth adding, but otherwise it's too uncertain
to know.

On Sat, 4 Jan 2020 at 22:54, Sebastian S.  wrote:

> Thanks for the tasking manager tip. Will have a look.
>
> Regarding start date I thought since I don't know the exact date I chose
> the one from the images.
> Once images are updated the source date could be updated while the start
> date stays.
>
> Can we go back in time with LPI images?
>
> On 4 January 2020 9:20:15 am AEDT, Andrew Harvey 
> wrote:
>>
>> Nice work, would love to see more roof top solar panels mapped.
>>
>> The Tasking Manager https://wiki.openstreetmap.org/wiki/Tasking_Manager might
>> suit this better than MapRoulette, since Tasking Manager breaks an area up
>> into tiles and you go in, choose a tile, complete it, then upload. It helps
>> track progress, avoid conflicts and ensures a whole area is done without
>> gaps in coverage.
>>
>> MapRoulette works differently, it's based on identifying features already
>> which need some work.
>>
>> > start_date=* - set to the date of the LPI NSW Imagery - or should this
>> be rather source:date=*??
>>
>> start_date is when the feature started, so when the solar panel was
>> installed, you can just do  if you only know the year or -MM if you
>> only know the month, but if you don't know you can omit it. source:date is
>> better for the imagery date.
>>
>> On Thu, 2 Jan 2020 at 08:50, Sebastian S.  wrote:
>>
>>> So far I have not worked out a good grid method.
>>> I go by suburb in my area and keep the file local until I've completed
>>> the suburb. Only then I upload.
>>> While offline I use a temporary area tagged as wood. I expand this box
>>> over the area I've worked through. This is just because I don't know any
>>> better solution. 
>>>
>>> If you want to see a map showing the modules you can use open
>>> infrastructure map, link is at the bottom of the wiki.
>>>
>>> I thought about making this a mapping challenge on
>>> https://wiki.openstreetmap.org/wiki/MapRoulette but so far I've not
>>> looked into it. I've got no experience with this but am happy to receive
>>> guidance.
>>>
>>>
>>> On 2 January 2020 7:11:07 am AEDT, Dion Moult 
>>> wrote:

 On Wed, Jan 01, 2020 at 11:29:13PM +1100, Sebastian Spiess wrote:

> I'd like to present my latest pet project:
> https://wiki.openstreetmap.org/wiki/User:ConsEbt/NorthernBeachesSolar
> I wanted to share this and collect some feedback or comments.
>

 I love it! I might do a bit of solar mapping too! How easy is it to set a 
 grid
 to know which areas have been mapped?

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

Re: [Talk-ca] Importing buildings in Canada

[Matthew Darwin]

Hello all,

Happy to see progress here.

My ongoing question is how to define that a "local" group has 
determined that an import can proceed.   And more specifically what is 
"local"? There are rural and remote parts of Canada which have in the 
order of zero active mappers or sense of a local community.  How do we 
consensus around imports there? Can we get agreement by (part-of) 
province/territory where there is not some other group that puts their 
hand up?  (maybe use admin level 5 boundaries, with holes for big cities)


I just want to make sure we don't stop at doing imports only for big 
cities. Buildings are important for the whole country.


On 2020-01-04 10:09 a.m., Nate Wessel wrote:


Hi Daniel,

Thank you for all the work you've put into this. I'd like to offer a 
couple suggestions and/or clarifications for your proposed import 
process, overview though it is.


First, I think it is very important that a tasking manager is set up 
on a city/by city basis only, and that only AFTER consensus is 
achieved that the import should proceed in that area. I would really 
like to avoid seeing the massive nationwide tasking that was set up 
the first time around. We should be making it hard for people to go 
rogue in regions where consensus for an import doesn't (yet) exist.


Related to this, though important enough to be a second point in 
it's own right, the tasking squares need to be small enough that a 
single user can manage them and inspect every single building in a 
task. The first round of import used task squares that were massive, 
and which couldn't be divided any further past a certain point. Even 
in rural areas, it is likely inappropriate to import areas larger 
than 1km^2. In central Toronto it would be (and was) idiotic. An 
import that doesn't take local scale into account shouldn't proceed. 
"Too big to load into JOSM" is about 100x too big to import in my 
opinion and is not a good enough benchmark for import batch sizing.


That is, each import needs to be local, and not just in a 
superficial sense.


I'll also add that the issue of conflation doesn't seem to have been 
worked out yet except to note that it is an issue. What will we do 
with the millions of buildings which will substantially 
overlap/duplicate existing buildings or imports? This needs to be 
worked out in detail before anything starts up again.


And what needs to be done about already existing low quality 
imports? It's good to acknowledge their existence, but what will be 
done about them? We've set up a task to clean up some of the mess in 
Toronto ( http://tasks.osmcanada.ca/project/168 ) but this is only 
the tip of the iceberg.


Again, I thank everyone for their time and effort on this - we can 
get this done if we go slow and do it right :-)


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:


Bonjour groupe, mes excuses pour ce très long courriel !-)

I have reviewed everything that has been written on the ODB import 
(aka Canada Building Import) in Talk-ca and the wiki. I proposed 
changes to some wiki pages (via talk tabs) to ease the discussions 
about this import and the following. Now, in order to restart the 
import, here are some thoughts and a proposal on how to proceed to 
complete the task.


*1. Issues with the ODB Data Import*

Many concerns were raised about the import. One major concern was 
to obtain local communities’ buy-in in the Canadian context. 
Another concern was to improve the quality of the data prior the 
import. The following paragraphs intend to clear most of these 
concerns.


*1.1. Which data import project?*

According to the import guidelines (steps 3 & 4), a data import 
explicitly refers to a single data source (ODB in our case). 
Discussions about the availability and quality of Microsoft or ESRI 
data, while interesting, are not relevant as they should be dealt 
with as other import projects.


*1.2. What has been imported so far?*

According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content’s 
history, at least for the samples checked, but many problems were 
found. In some case, the imports brought swimming pools in OSM 
because they were included in the dataset (e.g. Moncton). In other 
cases, importing buildings with accurate locations (XY) over 
content mapped from less accurate imagery resulted in buildings 
that now overlap the street network (e.g. Squamish). It means that 
all these 21 imports need to be carefully re-examined and corrected 
as required.


For 12 other municipalities, the import is partial, either 
suspended as requested, or because previous imports had already 
provided most of the buildings (often from the same municipal 
provider). That said the import will definitely improve OSM 
accuracy and completeness if done properly.


*2. How should ODB Data be imported?*

I will 

Re: [OSM-talk-be] Donation with tax certificate

[OSMDoudou via Talk-be]

Hello,

Do you know where we can read more about the procedure and conditions to 
receive approval by the KBF ?

Thx.



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

Re: [talk-cz] Bukovina [Was: Re: [začátečníci] wikipedie k place=*]

[Marián Kyral]

Ahoj,

stačí se mrknout na nějakou adresu: https://www.openstreetmap.org/way/
232437759

Dle všeho to je jen nějaká osada, která je součástí obce Levín




Můžeš si to ověřit v RUIANu (číslo  na konci nahradíš číslem z ref:ruian:
addr(https://wiki.openstreetmap.org/wiki/Cs:Key:ref:ruian:addr?uselang=cs))




https://vdp.cuzk.cz/vdp/ruian/adresnimista/25389025









-- Původní e-mail --
Od: MatějCepl 
Komu: talk-cz@openstreetmap.org
Datum: 4. 1. 2020 18:55:09
Předmět: Re: [talk-cz] Bukovina [Was: Re: [začátečníci] wikipedie k place=*]

"On 2020-01-04, 17:35 GMT, Matěj Cepl wrote:
> Kde se najde rozhodné určení, co je vesnice a co není?

Je to skutečně Katastr? Rozhodným měřítkem by pak byl

https://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/2-Poskytovani-udaju-RUIAN-
ISUI-VDP/Ciselniky-ISUI/Nizsi-uzemni-prvky-a-uzemne-evidencni-jednotky.aspx#
UI_OBEC

Je to tak? (Kdosi poukázal na tuto stránku na #wikipedia-cs)

Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

If the Good Lord had wanted us to enjoy ourselves, he wouldn’t
have granted us His precious gift of relentless misery.
-- Jean Calvin in "Calvin and the Chipmunks" comic strip
https://mcepl.fedorapeople.org/tmp/calvin_and_the_chipmunks.jpg


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

Re: [OSM-talk-fr] Proposition de correction : cantons sans chef-lieu

[deuzeffe]

Le 04/01/2020 à 17:10, Vincent de Château-Thierry a écrit :

Bonjour,


Pareil mais soir,


En mixant le contenu OSM et le COG j'ai établi cette page :
https://dev.cadastre.openstreetmap.fr/fantoir/cantons_sans_admin_centre.html 


Merci de l'avoir listée dans le sommaire ici : 
https://dev.cadastre.openstreetmap.fr/fantoir/liens.html ^^


qui se propose de lister les cantons concernés, et de permettre en peu 
de clics de corriger la situation.


Suit l'explication superbien faite pour les nunuches (et neuneux !) 
comme moi :)


Il y a 241 relations dans ce cas à l'instant. Merci à celles et ceux qui 
iront jeter un œil voire corriger quelques lignes. J'ai essayé de 
minimiser le clicodrome afin qu'on arrive rapidement au bout du sujet :)


C'est le moins qu'on puisse dire. C'est fait pour le 87.
Tu sais comment faire bosser les gens, toi :P


merci


Merci à toi.

--
deuzeffe

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

Re: [Talk-es] Unificar vías con carriles separados

[Alejandro S.]

Hola,

Perdonad la tardanza en responder.
De momento lo dejaré como está. Si acaso lo que comentaban unos cuantos 
correos atrás; antes de ponerme a unir vías, intentaré completar o 
arreglar lo que vea que está claramente mal. No vaya a ser que sea peor 
el remedio que la enfermedad xD


Muchas gracias por vuestros puntos de vista :)

Un saludo,
Yonseca

El 02/01/2020 a las 7:39, David Marín Carreño escribió:

Hola.

Hay problemas que no se pueden solucionar si se unen.

Por ejemplo, https://www.openstreetmap.org/#map=18/40.39254/-3.69499

En ese tramo del Paseo de las Delicias hay un carril bus en sentido 
contrario a la marcha. Desconozco si en la actualidad hay una 
separación física de dicho carril o no. Sé que en su día no la había.


Mapear esto sin independizar una vía para este carril bus, aunque no 
haya separación física, es un auténtico caos. Y algo que es 
completamente claro en la actualidad para cualquiera que vea el mapa o 
la base de datos se convierte en un maremagnum de etiquetas 
difícilmente legibles e interpretables para generadores de mapas, 
ruteadores, etc.


En otros casos, unirlo puede ser correcto. Pero ojo con perder 
información o añadir información de giros incorrecta. Quien haga esta 
unificación ha de ser muy meticuloso con todo esto.


Yo, sinceramente, abogo por dejarlo como está. No sé si podría crearse 
una relación entre ambas vías, incluyendo las aceras si existen como 
vías separadas.


--
David Marín Carreño mailto:dav...@gmail.com>>



El mié., 1 ene. 2020 a las 11:29, Héctor Ochoa (>) escribió:


Buenas,
yo sí que estoy de acuerdo en la unificación, ya que no hay
separación física. Si hubiese aunque sea unos míseros bolardos en
la mediana, separado. Dicho eso, tampoco cambia mucho ponerlo de
una manera o de otra pero creo que en este caso queda más correcto
unirlas.

Saludos

El mié., 1 ene. 2020 a las 11:23, Miguel Sevilla-Callejo
(mailto:msevill...@gmail.com>>) escribió:

Hola,

Yo NO soy partidario de unificar vías en calles que ya se han
editado por separado y en el que ya hay relaciones y otros
datos incluidos. Esto puede llevar a una simplificación y
problemas con los ruteadores, entre otros.

Estoy de acuerdo respecto a que si no hay una separación
física no se separe, pero si tienes una calle con doble
mediana y más de cuatro carriles me parece recomendable la
separación. Y si no es así se puede seguir realizando con vías
separadas y uniones en lugares en los que se pueda atravesar
la otra calzada.

Efectivamente todo se puede resolver con un buen etiquetado
pero conforme nos acercamos al detalle y subimos de escala es
recomendable la separación de vías.

Sucede similar con las calles con aceras. Tras mucho pensar
cómo realizar las ediciones, cuando llegas al detalle es
recomendable la separación de la vía peatonal de la vehicular.
Para trabajar en rutas, caracterización particular y añadir
elementos extras se hace más práctico la separación.

Se que no es exactamente lo mismo que lo que se plantea, pero
antes de entrar en cambiar cosas que ya están editadas, yo
sugiriría entrar en añadir más detalles y elementos. Perder
vías será perder nodos y finalmente información.

Un saludo y feliz 2020

Miguel


On Tue, 31 Dec 2019, 10:08 Roberto geb, mailto:roberto...@gmail.com>> wrote:

Alejandro,

separar los sentidos de la marcha cuando hay una doble
línea pintada en el suelo puede simplificar la gestión de
los cruces con las otras calles evitando añadir relaciones
de giro obligatorio, etc.
Hay que tener mucho cuidado con lo que propones ya que
puede acabar como  con la Gran Vía de Madrid, donde hay
varias vías superpuestas con las rutas de autobuses
circulando en una u otra según su sentido pero compartidas
para el resto de vehículos. Esto genera "ruido" a los
ruteadores.
A priori, no veo beneficios en fusionar ambos sentidos de
circulación. De hecho, han habido épocas en que el
Ayuntamiento ha creado esas medianas entre los sentidos y
las ha llenado de árboles, por lo que además puede ser un
trabajo contraproducente.
Creo que antes de acometer ese trabajo sería prudente
preguntar a los que han trabajado la vía los motivos por
los que están separados los sentidos. En JOSM, pulsando
CRTL-H puedes ver la historia de la vía y sus autores y,
pulsando sobre ellos, mandarles un correo.

Feliz Año a todos los mapeadores.

Saludos,.
Roberto

El sáb., 28 dic. 2019 a las 14:31, yo paseopor

Re: [OSM-talk] JOSM: Display time of a gpx track

[Martin Koppenhoefer]

sent from a phone

> On 4. Jan 2020, at 12:37, tshrub  wrote:
> 
> I wanted to add the coordinates in certain photos (exiftool) ...


are you aware that Josm has functionality to add coordinates from a gpx track 
to list of photos (and write it back to the jpg exif tags)?

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

Re: [Talk-ca] Importing buildings in Canada

[James]

Tell me when and where and the tasking manager project for xyz location
will be setup and hosted

On Sat., Jan. 4, 2020, 12:42 p.m. Daniel @jfd553, 
wrote:

> Bonjour groupe
>
>
>
> Looks like we're going in the same direction so far :-)
>
> I agree with Nate regarding the implementation of the task manager. In my
> experience, a size of a few blocks would be better in urban areas, but
> boring in rural areas. Is it something that can be adjusted?
>
>
>
> Daniel
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Saturday, January 04, 2020 10:09
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Hi Daniel,
>
> Thank you for all the work you've put into this. I'd like to offer a
> couple suggestions and/or clarifications for your proposed import process,
> overview though it is.
>
> First, I think it is very important that a tasking manager is set up on a
> city/by city basis only, and that only AFTER consensus is achieved that the
> import should proceed in that area. I would really like to avoid seeing the
> massive nationwide tasking that was set up the first time around. We should
> be making it hard for people to go rogue in regions where consensus for an
> import doesn't (yet) exist.
>
> Related to this, though important enough to be a second point in it's own
> right, the tasking squares need to be small enough that a single user can
> manage them and inspect every single building in a task. The first round of
> import used task squares that were massive, and which couldn't be divided
> any further past a certain point. Even in rural areas, it is likely
> inappropriate to import areas larger than 1km^2. In central Toronto it
> would be (and was) idiotic. An import that doesn't take local scale into
> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
> big to import in my opinion and is not a good enough benchmark for import
> batch sizing.
>
> That is, each import needs to be local, and not just in a superficial
> sense.
>
> I'll also add that the issue of conflation doesn't seem to have been
> worked out yet except to note that it is an issue. What will we do with the
> millions of buildings which will substantially overlap/duplicate existing
> buildings or imports? This needs to be worked out in detail before anything
> starts up again.
>
> And what needs to be done about already existing low quality imports? It's
> good to acknowledge their existence, but what will be done about them?
> We've set up a task to clean up some of the mess in Toronto (
> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
> iceberg.
>
> Again, I thank everyone for their time and effort on this - we can get
> this done if we go slow and do it right :-)
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done 

Re: [talk-cz] Bukovina [Was: Re: [začátečníci] wikipedie k place=*]

[Matěj Cepl]

On 2020-01-04, 17:35 GMT, Matěj Cepl wrote:
> Kde se najde rozhodné určení, co je vesnice a co není?

Je to skutečně Katastr? Rozhodným měřítkem by pak byl

https://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/2-Poskytovani-udaju-RUIAN-ISUI-VDP/Ciselniky-ISUI/Nizsi-uzemni-prvky-a-uzemne-evidencni-jednotky.aspx#UI_OBEC

Je to tak? (Kdosi poukázal na tuto stránku na #wikipedia-cs)

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
If the Good Lord had wanted us to enjoy ourselves, he wouldn’t
have granted us His precious gift of relentless misery.
  -- Jean Calvin in "Calvin and the Chipmunks" comic strip
 https://mcepl.fedorapeople.org/tmp/calvin_and_the_chipmunks.jpg


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

Re: [Talk-ca] Importing buildings in Canada

[Daniel @jfd553]

Bonjour groupe

Looks like we're going in the same direction so far :-)
I agree with Nate regarding the implementation of the task manager. In my 
experience, a size of a few blocks would be better in urban areas, but boring 
in rural areas. Is it something that can be adjusted?

Daniel

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Saturday, January 04, 2020 10:09
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada


Hi Daniel,

Thank you for all the work you've put into this. I'd like to offer a couple 
suggestions and/or clarifications for your proposed import process, overview 
though it is.

First, I think it is very important that a tasking manager is set up on a 
city/by city basis only, and that only AFTER consensus is achieved that the 
import should proceed in that area. I would really like to avoid seeing the 
massive nationwide tasking that was set up the first time around. We should be 
making it hard for people to go rogue in regions where consensus for an import 
doesn't (yet) exist.

Related to this, though important enough to be a second point in it's own 
right, the tasking squares need to be small enough that a single user can 
manage them and inspect every single building in a task. The first round of 
import used task squares that were massive, and which couldn't be divided any 
further past a certain point. Even in rural areas, it is likely inappropriate 
to import areas larger than 1km^2. In central Toronto it would be (and was) 
idiotic. An import that doesn't take local scale into account shouldn't 
proceed. "Too big to load into JOSM" is about 100x too big to import in my 
opinion and is not a good enough benchmark for import batch sizing.

That is, each import needs to be local, and not just in a superficial sense.

I'll also add that the issue of conflation doesn't seem to have been worked out 
yet except to note that it is an issue. What will we do with the millions of 
buildings which will substantially overlap/duplicate existing buildings or 
imports? This needs to be worked out in detail before anything starts up again.

And what needs to be done about already existing low quality imports? It's good 
to acknowledge their existence, but what will be done about them? We've set up 
a task to clean up some of the mess in Toronto ( 
http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the iceberg.

Again, I thank everyone for their time and effort on this - we can get this 
done if we go slow and do it right :-)

Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com
On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
Bonjour groupe, mes excuses pour ce très long courriel !-)
I have reviewed everything that has been written on the ODB import (aka Canada 
Building Import) in Talk-ca and the wiki. I proposed changes to some wiki pages 
(via talk tabs) to ease the discussions about this import and the following. 
Now, in order to restart the import, here are some thoughts and a proposal on 
how to proceed to complete the task.

1. Issues with the ODB Data Import
Many concerns were raised about the import. One major concern was to obtain 
local communities' buy-in in the Canadian context. Another concern was to 
improve the quality of the data prior the import. The following paragraphs 
intend to clear most of these concerns.
1.1. Which data import project?
According to the import guidelines (steps 3 & 4), a data import explicitly 
refers to a single data source (ODB in our case). Discussions about the 
availability and quality of Microsoft or ESRI data, while interesting, are not 
relevant as they should be dealt with as other import projects.
1.2. What has been imported so far?
According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content's history, at least 
for the samples checked, but many problems were found. In some case, the 
imports brought swimming pools in OSM because they were included in the dataset 
(e.g. Moncton). In other cases, importing buildings with accurate locations 
(XY) over content mapped from less accurate imagery resulted in buildings that 
now overlap the street network (e.g. Squamish). It means that all these 21 
imports need to be carefully re-examined and corrected as required.
For 12 other municipalities, the import is partial, either suspended as 
requested, or because previous imports had already provided most of the 
buildings (often from the same municipal provider). That said the import will 
definitely improve OSM accuracy and completeness if done properly.
2. How should ODB Data be imported?
I will copy the following paragraphs in the "Canada Building Import" wiki page 
[3] for a detailed discussion...
Since the data (ODB, OSM and imagery) differ from one municipality to another, 
there can be no imports at the national or provincial level. We have to work on 
a municipal basis and make 

[Talk-gb-westmidlands] Mark Renn, sculptor

[Andy Mabbett]

Happy New Year to you all.

Those of you who appreciate public art might be interested in a
Wikipedia article I've just written, on Birmingham sculptor Mark Renn,
who sadly died last month:

   https://en.wikipedia.org/wiki/Mark_Renn

Some of his works don't seem to be mapped, and some of those in the
table on the article need coordinates and/ or photos.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

[talk-cz] Bukovina [Was: Re: [začátečníci] wikipedie k place=*]

[Matěj Cepl]

On 2020-01-01, 21:58 GMT, Miroslav Suchý wrote:
> Najděte si oblast, která vás zajímá. A klikněte na Spustit.
> Tento dotaz nalezne všechny vesnice, které nemají atribitut wikipedie.

Tak jsem se podíval na oblast kolem Úštěku a našel jsem obec 
Bukovina (https://www.openstreetmap.org/node/477447719), která 
skutečně není zaznamenána ve Wikipedii. Když jsem se ale do toho 
začal nořit, tak jsem zjistil, že nevím, jestli Bukovina 
skutečně existuje (https://www.openstreetmap.org/note/2046382). 
Kde se najde rozhodné určení, co je vesnice a co není?

Hezký den,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
As long as we are thinking of natural values we must say that the
sun looks down on nothing half so good as a household laughing
together over a meal, or two friends talking over a pint of beer,
or a man alone reading a book that interests him; and that all
economies, politics, laws, armies, and institutions, save insofar
as they prolong and multiply such scenes, are a mere ploughing
the sand and sowing the ocean, a meaningless vanity and vexation
of the spirit. Collective activities are, of course, necessary,
but this is the end to which they are necessary.
  -- C.S. Lewis, “Membership” in “The Weight of Glory”


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

Re: [OSM-talk-fr] pb sur un cset lié aux langues locales

[Christian Rogel]

> Le 4 janv. 2020 à 13:02, Vincent Bergeot  a écrit :
> 
> Le 04/01/2020 à 12:26, Christian Quest a écrit :
>> Le sam. 4 janv. 2020 à 11:12, Vincent Bergeot > > a écrit :
>> Ok, mais c'est "anecdotique" par rapport à tout le reste. Que dans ce cas 
>> cela soit une erreur de manip, ok mais dans les autres cas, au vu de la 
>> fréquence et des volumes traités c'est peut-être des mauvaises manips mais 
>> systématiques.
> 
> Si c'est perçu comme de l'énervement, je m'en excuse, ce n'est pas le but 
> (j'adore en plus l'idée d'une carte occitane !).
> C'est surtout de l'incompréhension. Ok, ce n'est pas du vandalisme par 
> intention je n'ai aucun doute la dessus, mais les modifications me semblent 
> bien trop importantes  pour que cela cela apporte une confirmation de la 
> validité du name car cela concerne quelques milliers de noms (mais je suis 
> prêt à changer d'avis et surtout à comprendre comment c'est réalisé !). Le 
> coté automatique y compris les ajouts quand il n'y a pas de name (ce que tu 
> as corrigé Christian, si j'ai compris), les traductions des arrêts de bus 
> (ok, ils sont tous traduits à Toulouse
> Et ensuite c'est l'absence de réponse, faire des dizaines de milliers de 
> modifications à un rythme très soutenu, ne pas avoir de réponse sur la licence


Je ne suis pas compétent pour la toponymie occitane, mais, pour couper court à 
des interprétations rapides, je résume ce que je sais :
Après la création du rendu des NL en breton (avril 17), j’ai envoyé une 
circulaire à tous les organismes s’occupant de langues locales en France 
(offices publics, directions nationale et régionales, associations). J’ai eu 
une réponse immédiate de Peire Brechet, président de l’Institut d’études 
occitanes (IEO) qui a, d’emblée, cherché à apprendre les méthodes et 
technlogies d’OSM et mis en place des initiations pour ses membres. Il est venu 
aux SotM FR de Bordeaux et de Montpellier
Pour ce qui concerne l’import intempestif de « name » trop normalisés », il 
m’indique que cela a été fait il y a deux ans. L’absence de réponse s’explique, 
peut-être, par le fait que le compte utilisé n’a servi principalement qu’à 
cette seule opération
L’erreur vient d’un phénomène courant : le zèle des néophytes et une compétence 
technique au dessus de la moyenne pour se lancer dans l’mport sans avertir la 
communauté.
J’ai prévenu P. Brechet du blocage quand Vincent Bergeot l’a annoncé, mais, 
sans réaction de sa part
Je vais lui demander d’indiquer sur le site de l’IEO que bd Topoc est libre

Selon moi, il serait bien que ceux qui corrigent dans les règles prennent le 
soin de l’indiquer courtoisement à l’adresse que j’ai indiquée 
(direcc...@ieo-oc.org ) ou mieux à la section de 
l’IEO la plus proche de chez eux.
C’est en relation avec une stratégie locale que l’IEO pratique une certaine 
discrétion sur son action concernant l’insertion de la toponymie dans OSM en 
privilégiant les « name:oc » pour les communes.
Ce qu’il puisse arriver de mieux, c’est que les mappeurs, sans forcèment être 
des militants, prennent contact avec la section de l’IEO  la plus proche, en 
tant, que d’une part, de référence incontournable pour les name:oc et, bien 
sûr, en tant que groupe de mappeurs potentiels, qui ne se limiteront pas à 
renseigner des POI, mais, enrichiront la carte elle-même.


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

[OSM-talk] is OSM a fake map.

[Mario Frasca]

Hi.  I'm trying to understand what are you talking about, and I have two
options:

1- that there are mistakes in the map.  that's a good thing, that you
are able to spot them, because you can correct them.  I suggest you do
so, and share the good news when you have something to celebrate!

2- you hope that someone helps you correcting them.  in that case it
would be helpful if you would share a link to the area you can't correct
yourself.

I can assure you, in my experience, the big G map is much, much, much
faker than OSM, at least in marginal areas.  like Jardín, Antioquia in
2015, or Las Minas, Los Santos right now.  it shows roads that do not exist.

but yes, also OSM has trolls mapping non existent stuff, very true. 
stay alert and remove mistakes, or ask the community for help, providing
the relevant links to the suspicious edits.

ciao, happy mapping, Mario

On 01/01/2020 10:00, 80hnhtv4agou--- via talk wrote:
> i am seeing different images on different maps, bing is very old in my
> area,
>  
> trails that were once there are over grown and impassable.
>  
> roads do not change,
>  
> but shopping malls are torn down, and rivers are diverted,
>  
> landfills that look flat with stuff on top are miss labeled
>  
> over flow ponds look like flat grass land
>  
> retention dry ponds, look like holes in the ground with water on the
> satellite pass,
>  
> all this by the tracer not a person on the ground.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cat] Importació arbres de Barcelona

[Joan Quintana]

Hola Carlos,
aquesta tardor passada vaig estar fent algunes importacions que considerava
fàcils, en el marc de familiaritzar-me amb la llibreria de Osmapi amb
Python.
Vaig començar pels arbres monumentals de Catalunya, després els arbres
singulars de Barcelona, i també vaig fer els arbres monumentals de Mallorca.

*
https://wiki.openstreetmap.org/wiki/Ca:Importaci%C3%B3_Ajuntament_de_Barcelona
*
http://wiki.joanillo.org/index.php/Arbres_Monumentals_de_Catalunya_(programaci%C3%B3_OSM)

Aprofitant, també vaig fer unes altres importacions de Opendata Barcelona,
amb la idea de continuar, però vaig haver d'aturar-me per atendre altres
prioritats.

He fet servir la importació dels arbres singulars de Barcelona per fer una
proposta didàctica que crec interessant, si algú ho vol donar un cop d'ull:
"Traveling Salesman problem i arbres singulars de Barcelona":

*
http://wiki.joanillo.org/index.php/Traveling_Salesman_problem_i_arbres_singulars_de_Barcelona

Ho tinc tot ben documentat, però ara veig que encara no tinc penjat al
GitHub el codi que he desenvolupat, miraré de fer-ho aquest vespre mateix.
Mentrestant, també miraré el teu codi Python.

Att,
Joan Quintana

Missatge de Carlos Cámara via Talk-cat  del dia
dc., 1 de gen. 2020 a les 12:50:

> Bon dia i bon any,
>
> Estic començant a aprendre python i per a fer-ho, he pensat que, enlloc de
> fer exercicis random, volia provar amb preparar importacions per a OSM. He
> començat amb una cosa petita (però escalable), fent un script d'importació
> d'arbres de BCN (em sembla que hi havia algú interessat per aquí fa temps),
> i he publicat un repo aquí:
> https://github.com/mapcolabora/osm_imports_preparations/.
>
> Ara mateix l'script és funcional i el que fa és el següent:
>
>1. descarregar les darreres dades del portal d'OpenData de
>l'Ajuntament de Barcelona
>2. mapejar els atributs originals a etiquetes d'OSM segons el que
>descric aquí: https://osmimports.mapcolabora.org/bcn_trees (en
>general, veureu que està tot documentat, tant les funcions com el
>procediment, que podeu consultar a la carpeta docs o a
>https://osmimports.mapcolabora.org/)
>3. combinar els dos datasets (n'hi ha un per a arbres en vies i un
>altre per a arbres en zones) i desar-los com a un sol fitxer csv, que seria
>el que fariem servir per a la importació.
>
> Ara bé, no tinc molt clar com seguir a partir d'aquí. Entenc que cal
> avisar la llista (per això escric i us animo a que reviseu el parsing de
> camps) i entenc també que caldria configurar un projecte al gestor de
> tasques. Aquí ja em perdo més, perquè no tinc clar com es determinen les
> zones. No sé si em descuido alguna cosa més.
>
> Per altra banda, veient el dataset original, he vist que hi ha informació
> dels escocells, i crec que podria ser una informació interessant a tenir de
> cara a accessibilitat, però no he vist cap etiqueta al respecte (he buscat
> com tree pit i res). Si ningú coneix cap etiquetatge per a això, enviaré
> una consulta a les llistes d'accessibilitat i de tagging.
>
> Salut,
>
>
> Carlos Cámara
> http://carloscamara.es
>
>
> ___
> Talk-cat mailing list
> Talk-cat@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cat
>
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

[OSM-talk-fr] Proposition de correction : cantons sans chef-lieu

[Vincent de Château-Thierry]

Bonjour,
Au cours d'une analyse de données pour BANO j'ai constaté qu'on avait un 
bon paquet de cantons (relations boundary=political + 
political_division=canton) dépourvues de chef-lieu : ce sont des 
relations sans noeud ayant un rôle admin_centre.


En mixant le contenu OSM et le COG j'ai établi cette page :
https://dev.cadastre.openstreetmap.fr/fantoir/cantons_sans_admin_centre.html
qui se propose de lister les cantons concernés, et de permettre en peu 
de clics de corriger la situation.
Pour chaque ligne, un clic sur le lien 'JOSM' ouvre un calque avec la 
relation et le node place=* de son chef-lieu supposé. Il reste à éditer 
la relation pour ajouter le noeud, lui ajouter un rôle admin_centre, 
valider et envoyer.
Il y a 241 relations dans ce cas à l'instant. Merci à celles et ceux qui 
iront jeter un oeil voire corriger quelques lignes. J'ai essayé de 
minimiser le clicodrome afin qu'on arrive rapidement au bout du sujet :)


merci
vincent

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

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Philippe Verdy]

Que vient faire les logo et le copyright de Telenav sur cette image
supposée libre selon l'auteur ?

Même si elle a été initialement créée et partagée sur son compte Dropbox
avant l'import sur Commons, elle n'est pas valide avec ce logo, si cela ne
vient pas directement de Telenav (c'est bien le logo commercial avec la
forme caractéristique de certaines lettres et (R) en exposant, et non une
simple mention, inutile ici, à moins que Telenav lui ait demandé et payé de
faire ce fichier, et dans ce cas le copyright de l'auteur est
invalide/abusif).

Je pense qu'il faudrait demander à l'auteur de supprimer ce logo qui n'a
rien à faire là, surtout sur Commons, sans permission explicite de Telenav
(ensuite la source sur le partage original Dropbox doit obéir aux règles de
Dropbox). La source indiquée sur Commons est fausse, l'image ne vient PAS
du site journal d'OSM (où le logo a seulement été lié indirectement mais ne
s'affiche pas car externe), mais bien du site externe de partage personnel
de l'utilisateur hébergé chez Dropbox.

Je n'ai pas de raison de douter que l'auteur indiqué est correct (c'est lui
qui a importé le même fichier sur Commons après l'avoir importé sur Dropbox
puis lié à son journal OSM), mais on voit bien que certains utilisateurs
OSM ne comprennent rien aux licences et au droit d'auteur et la façon de
mentionner les sources et l'intégration de logos propriétaires dans leurs
créations, pas légale sans autorisation (et le droit "fair use" américain
ne s'applique pas: sans objet ici, pas applicable hors des USA et l'auteur
n'est pas résident américain, et de toute façon interdit aussi sur Commons).

Pourtant quelqu'un sur Commons (Rodrigolopes) a "validé" l'autorisation en
indiquant une URL incorrecte pour la source originale (l'image n'a JAMAIS
été sur un serveur d'OSM qui se retrouve donc lié tout aussi incorrectement
à cet usage interdit, ce relecteur ne sait pas lire non plus et cela met en
doute ce qu'il "valide" comme autorisé sur Commons)




Le sam. 4 janv. 2020 à 13:14, Vincent Privat  a
écrit :

> Cadeau:
> https://commons.wikimedia.org/wiki/File:JOSM_Keyboard_Shortcuts.png
>
> Le sam. 4 janv. 2020 à 13:07, Sébastien Dinot  a
> écrit :
>
>> Christian Quest a écrit :
>> > *W / "Way Improve"*
>> > [...]
>> >
>> > *F / "Follow Line"*
>> > [...]
>>
>> Ma productivité prendrais en effet une claque si je n'utilisais pas ces
>> 2 raccourcis.
>>
>> En autre très utile à connaitre lorsqu'on décide d'affiner la couverture
>> du sol dans une zone de polygones grossiers :
>>
>> *Alt-X*
>>
>> Cette commande coupe en deux polygones le polygone sélectionné.
>>
>> Mode opératoire :
>>
>> 1. Sélectionner le polygone à découper.
>>
>> 2. Sélectionner les 2 points constituant les sommets de la coupe.
>>
>> 3. Appuyer sur Alt-X
>>
>> NB : L'étape 1 est inutile s'il n'y a pas d'ambiguité sur le polygone
>>  considéré (i.e.e si les sommets sélectionnés à l'étape
>>  2 n'appartiennent pas à plusieurs polygones.
>>
>> Grâce à cette commande, je n'ai eu aucun mal à découper ce monstre :
>>
>> https://www.palabritudes.net/~zebulon/polygone-geant-1.png
>>
>> Pour en faire cela :
>>
>> https://www.palabritudes.net/~zebulon/polygone-geant-2.png
>>
>> Ce qui m'a permis, sur la zone en rouge ci-dessous :
>>
>> https://www.palabritudes.net/~zebulon/polygone-geant-3.png
>>
>> De passer de ça :
>>
>>
>> https://www.palabritudes.net/~zebulon/polygone-geant-zone-traitee-20180926.png
>>
>> à ça :
>>
>>
>> https://www.palabritudes.net/~zebulon/polygone-geant-zone-traitee-20181017.png
>>
>> Et au cours d'un tel travail, les raccourcis W et F sont eux aussi
>> précieux.
>>
>> A++, 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
>>
> ___
> 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] SPAM, Re: Chemins publics / privés / ouverts / fermés

[Florimond Berthoux]

Je garderais le chemin, il est toujours visible, bien que mal entretenu.

Le sam. 4 janv. 2020 à 08:44, Arnaud Champollion
 a écrit :
>
> Le 04/01/2020 à 08:18, Arnaud Champollion a écrit :
> > Oui, justement dans l'exemple cité, je suis allé voir sur le terrain
> > et il y a bien : portail d'un côté, clôture de l'autre, et reste
> > d'ancien chemin non entretenu entre les deux.
> >
> > --> Dans ce cas je serais pour la suppression du chemin.
>
>
> https://www.openstreetmap.org/way/569947953
>
> Photos
> https://framapic.org/gallery#rlnndlRYOCXY/A0oIv6fCiIp8.jpg,vvZ2L3Pf3CZO/XT6je77NDrVP.jpg
>
>
> Pour l'autre https://www.openstreetmap.org/way/569944546
>
> je n'ai pas pris de photo mais c'est pire, une forêt de broussailles
> entre les bâtiments.
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Florimond Berthoux

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

Re: [Talk-ca] Importing buildings in Canada

[Nate Wessel]

Hi Daniel,

Thank you for all the work you've put into this. I'd like to offer a 
couple suggestions and/or clarifications for your proposed import 
process, overview though it is.


First, I think it is very important that a tasking manager is set up on 
a city/by city basis only, and that only AFTER consensus is achieved 
that the import should proceed in that area. I would really like to 
avoid seeing the massive nationwide tasking that was set up the first 
time around. We should be making it hard for people to go rogue in 
regions where consensus for an import doesn't (yet) exist.


Related to this, though important enough to be a second point in it's 
own right, the tasking squares need to be small enough that a single 
user can manage them and inspect every single building in a task. The 
first round of import used task squares that were massive, and which 
couldn't be divided any further past a certain point. Even in rural 
areas, it is likely inappropriate to import areas larger than 1km^2. In 
central Toronto it would be (and was) idiotic. An import that doesn't 
take local scale into account shouldn't proceed. "Too big to load into 
JOSM" is about 100x too big to import in my opinion and is not a good 
enough benchmark for import batch sizing.


That is, each import needs to be local, and not just in a superficial 
sense.


I'll also add that the issue of conflation doesn't seem to have been 
worked out yet except to note that it is an issue. What will we do with 
the millions of buildings which will substantially overlap/duplicate 
existing buildings or imports? This needs to be worked out in detail 
before anything starts up again.


And what needs to be done about already existing low quality imports? 
It's good to acknowledge their existence, but what will be done about 
them? We've set up a task to clean up some of the mess in Toronto ( 
http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the 
iceberg.


Again, I thank everyone for their time and effort on this - we can get 
this done if we go slow and do it right :-)


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:


Bonjour groupe, mes excuses pour ce très long courriel !-)

I have reviewed everything that has been written on the ODB import 
(aka Canada Building Import) in Talk-ca and the wiki. I proposed 
changes to some wiki pages (via talk tabs) to ease the discussions 
about this import and the following. Now, in order to restart the 
import, here are some thoughts and a proposal on how to proceed to 
complete the task.


*1. Issues with the ODB Data Import*

Many concerns were raised about the import. One major concern was to 
obtain local communities’ buy-in in the Canadian context. Another 
concern was to improve the quality of the data prior the import. The 
following paragraphs intend to clear most of these concerns.


*1.1. Which data import project?*

According to the import guidelines (steps 3 & 4), a data import 
explicitly refers to a single data source (ODB in our case). 
Discussions about the availability and quality of Microsoft or ESRI 
data, while interesting, are not relevant as they should be dealt with 
as other import projects.


*1.2. What has been imported so far?*

According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content’s history, 
at least for the samples checked, but many problems were found. In 
some case, the imports brought swimming pools in OSM because they were 
included in the dataset (e.g. Moncton). In other cases, importing 
buildings with accurate locations (XY) over content mapped from less 
accurate imagery resulted in buildings that now overlap the street 
network (e.g. Squamish). It means that all these 21 imports need to be 
carefully re-examined and corrected as required.


For 12 other municipalities, the import is partial, either suspended 
as requested, or because previous imports had already provided most of 
the buildings (often from the same municipal provider). That said the 
import will definitely improve OSM accuracy and completeness if done 
properly.


*2. How should ODB Data be imported?*

I will copy the following paragraphs in the “Canada Building Import” 
wiki page [3] for a detailed discussion…


Since the data (ODB, OSM and imagery) differ from one municipality to 
another, there can be no imports at the national or provincial level. 
We have to work on a municipal basis and make sure to identify all the 
problems and the corrective measures to apply when dealing with issues 
like those I identified [1].


*2.1 Importing Locally*

According to the import guidelines (step 2), we must not import the 
data without local buy-in. However, and contrarily to some European 
country, there is usually no such thing as a local OSM community in 
each municipality. However, we may find a few local 

Re: [Talk-at] Stop area groups

[andreas wecer]

Am Sa., 4. Jan. 2020 um 12:34 Uhr schrieb Robin Däneke <
robin.daen...@live.at>:

> Man könnte den User der das macht aber auch mal fragen, warum. Und ob er
> es nicht vielleicht zumindest etwas geographischer angehen könnte.
>
> Falls es sich dabei um den User Diego Sanguinetti handelt, der scheint für
> diese MAPS.me subway Gruppe zu mappen. Die haben ja leider auch eine eigene
> Vorstellung wie die Daten aussehen sollen...
>

Ja, es handelt sich in beiden Fällen um diesen User und Kevin hat das schon
getan: https://www.openstreetmap.org/changeset/78848893
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] SPAM, Chemins publics / privés / ouverts / fermés

[Arnaud Champollion]

Bonjour,

De retour de balade matinale en forêt, j'ai commencé à nettoyer et 
corriger la zone.

Voilà le genre de contributions un peu spéciales sur les accès des chemins.
J'ai répondu avec le compte Linux Alpes :

https://www.openstreetmap.org/changeset/65565363







Le 03/01/2020 à 17:37, Arnaud Champollion a écrit :

Bonjour,

Les chemins passent parfois sur des parcelles privées (cadastrées) ou 
zones communales (pas de numéro au cadastre). Il arrive que ces 
chemins soient fermés au public.


On a donc, en simplifiant, quatre cas :

1) le cas du chemin situé sur parcelle privée, et d'accès privé.

2) le cas du chemin situé sur parcelle privée, mais passage autorisé 
(c'est le cas concrètement de beaucoup de sentiers de randonnée)


3) le cas du chemin situé sur parcelle publique, et d'accès autorisé

4) le cas du chemin situé sur parcelle publique, mais "accaparé" par 
le propriétaire mitoyen


Je me pose plusieurs questions sur la façon de bien cartographier.

--> Cas numéro 1 : ce genre de chemin doit-il figurer sur la carte ? 
Au même titre que des allés situées à l'intérieur de pripriétés ? Avec 
le tag access=private ?


--> Cas numéro 4 : du point de vue du terrain concret, ce serait 
access=private , du point de vue légal ce serait access=yes donc on 
privilégie quoi ?



Cas d'école, dont il a déjà été question il y a un peu plus d'un an  : 
https://lists.openstreetmap.org/pipermail/talk-fr/2018-October/090681.html


Dans le bassin dignois, il y a deux contributeurs qui ont pris 
l'habitude d'utiliser l'attribut "name" pour qualifier d' "accaparé" 
les chemins fermés par des propriétaires. Qu'ils soient légalement 
privés ou communaux, d'ailleurs.


A priori, c'est une mauvaise utilisation de l'attribut "name". Cela a 
déjà été signifié au contributeur, en lui demandant notamment ce qu'il 
voulait signifier ainsi, mais les commentaires restent pour le moment 
sans réponse.


Je me suis dit qu'on pourrait, pour faire propre et conserver les 
informations apportés maladroitement :


- déplacer en masse tous ces attributs name=accaparé vers 
description=accaparé


- qualifier correctement ces chemins avec la clé access

C'est pour cette deuxième tâche que je vous pose les questions des cas 
1 et 4.



Comme il y a deux "accaparés" près de chez moi je suis allé voir 
concrètement ce que c'était :


https://www.openstreetmap.org/#map=19/44.08683/6.22991

En effet, il y a un portail de chaque côté et on devine avec quelques 
efforts que ça a été, à une époque, des chemins piétons. C'est 
désormais envahi de broussailles, et comme c'est étroit et coincé 
entre des bâtiments, si on ne sait pas on passe à côté sans les voir.


J'ai regardé ce que ça donnait au cadastre :

https://www.geoportail.gouv.fr/carte?c=6.229741167994319,44.08693104665727=19=OPEN_STREET_MAP::GEOPORTAIL:OGC:WMTS(1)=CADASTRALPARCELS.PARCELS::GEOPORTAIL:OGC:WMTS(1)=yes 



Le chemin à l'ouest est sur une parcelle numérotée 148, donc a priori 
il est privé.


Le chemin à l'est n'a pas de numéro, donc a priori il est communal, et 
c'est un accaparement par le propriétaire mitoyen.


Du point de vue du terrain, ces chemins n'existent pas, dans le sens 
où ils sont quasi-invisibles et impraticables. C'est presque un "cas 
numéro 5",  je dirais qu'ils devraient pas être du tout sur OSM.


Qu'en pensez-vous ?





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

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Georges Dutreix via Talk-fr]

Bonne année à tous,



Le 04/01/2020 à 13:06, Sébastien Dinot a écrit :

Christian Quest a écrit :

*W / "Way Improve"*
[...]

*F / "Follow Line"*
[...]

Ma productivité prendrais en effet une claque si je n'utilisais pas ces
2 raccourcis.

En autre très utile à connaitre lorsqu'on décide d'affiner la couverture
du sol dans une zone de polygones grossiers :

*Alt-X*


J'en ai découvert un récemment que je trouve très utile.

*Maj-U / Unselect nodes*
Si on veut déplacer une grosse poignée de maisons pour les repositionner 
sur BD Ortho IGN par exemple, une sélection rectangulaire attrape des 
noeuds d'autres bâtiments, de rues, ou des POIs. Maj-U ne conserve que 
des "ways".


il nécessite utilsplugin2 : 
https://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2


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

Re: [OSM-talk-fr] pb sur un cset lié aux langues locales

[Christian Quest]

Le sam. 4 janv. 2020 à 13:07, Vincent Bergeot  a
écrit :

> Le 04/01/2020 à 12:26, Christian Quest a écrit :
>
> Le sam. 4 janv. 2020 à 11:12, Vincent Bergeot  a
> écrit :
>
>> Ok, mais c'est "anecdotique" par rapport à tout le reste. Que dans ce cas
>> cela soit une erreur de manip, ok mais dans les autres cas, au vu de la
>> fréquence et des volumes traités c'est peut-être des mauvaises manips mais
>> systématiques.
>>
>> Pour l'instant l'utilisateur est bloqué, merci à ceux qui ont commencé à
>> nettoyer les différentes modifications (par exemple retrait de la source
>> quand pas de name :) )
>>
>> Que pensez vous de ce type d'ajout :
>> https://www.openstreetmap.org/node/6444915153/history
>>
>> Pour moi, cela pose 2 questions principales :
>>
>>- pourquoi ajouter une source à une traduction qui existe depuis 8
>>mois (voire dans le cas de Bordeaux le name:oc=Bordèu a été ajouté il y a 
>> 5
>>ans, la source hier )
>>- est-ce que cette source est libre de la bd topo ?
>>http://bdtopoc.org/ je ne trouve pas de traces ni de la licence ni de
>>la base de donnée (bon je n'ai pas passé des heures non plus !)
>>
>> à plus
>>
>
> L'ajout de source:name:oc me semble permettre de confirmer que c'est bien
> le bon nom en occitan d'après un référentiel officiel.
>
> Pour la licence, je n'ai plus l'historique, mais nous avons eu des
> contacts très positifs passés et il me semble qu'il n'y a aucun problème.
>
> Je ne comprends pas trop ce que je perçois comme un énervement, on est
> loin du vandalisme quand même !
>
>
> Si c'est perçu comme de l'énervement, je m'en excuse, ce n'est pas le but
> (j'adore en plus l'idée d'une carte occitane !).
>
> C'est surtout de l'incompréhension. Ok, ce n'est pas du vandalisme par
> intention je n'ai aucun doute la dessus, mais les modifications me semblent
> bien trop importantes  pour que cela cela apporte une confirmation de la
> validité du name car cela concerne quelques milliers de noms (mais je suis
> prêt à changer d'avis et surtout à comprendre comment c'est réalisé !). Le
> coté automatique y compris les ajouts quand il n'y a pas de name (ce que tu
> as corrigé Christian, si j'ai compris), les traductions des arrêts de bus
> (ok, ils sont tous traduits à Toulouse
>
> Et ensuite c'est l'absence de réponse, faire des dizaines de milliers de
> modifications à un rythme très soutenu, ne pas avoir de réponse sur la
> licence
>
> à plus
>
> --
> Vincent Bergeot
>
> ___
>
>
Il y a clairement de l'automatisation dans ces contributions. Ceci devrait
donc être documenté quelque part, et ça ne semble pas l'être sur le wiki.
C'est un premier problème et le second c'est l'absence de réponse aux
commentaires sur les changesets.

Je pense qu'on touche ici un autre sujet: la multiplication des canaux de
communications qui fait qu'on ne sait plus quels sont les canaux
principaux, prioritaires.

irc, talk-fr, forum, twitter, telegram, facebook... et on oublie le mail de
base :(


J'ai pour l'instant juste supprimé les source:name:oc quand il n'y avait
pas de name:oc sur l'objet.

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

[OSM-talk-be] Donation with tax certificate

[rodeo .be]

Hello all,

besides Openstreetmap I'm active within the Wikipedia community. The
Belgian chapter recently partnered with the King Baudouin Foundation (KBF)
to collect donations with tax certificate
.

It is a reasonably simple procedure. You need to collect 1000 euro start
capital, and get approval by the KBF. The so called "Friends of Wikimedia
Belgium Fund" has been successful, they has seen a 4x increase in donations.

Maybe something to consider for the OSM chapter?

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

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Vincent Privat]

Cadeau: https://commons.wikimedia.org/wiki/File:JOSM_Keyboard_Shortcuts.png

Le sam. 4 janv. 2020 à 13:07, Sébastien Dinot  a
écrit :

> Christian Quest a écrit :
> > *W / "Way Improve"*
> > [...]
> >
> > *F / "Follow Line"*
> > [...]
>
> Ma productivité prendrais en effet une claque si je n'utilisais pas ces
> 2 raccourcis.
>
> En autre très utile à connaitre lorsqu'on décide d'affiner la couverture
> du sol dans une zone de polygones grossiers :
>
> *Alt-X*
>
> Cette commande coupe en deux polygones le polygone sélectionné.
>
> Mode opératoire :
>
> 1. Sélectionner le polygone à découper.
>
> 2. Sélectionner les 2 points constituant les sommets de la coupe.
>
> 3. Appuyer sur Alt-X
>
> NB : L'étape 1 est inutile s'il n'y a pas d'ambiguité sur le polygone
>  considéré (i.e.e si les sommets sélectionnés à l'étape
>  2 n'appartiennent pas à plusieurs polygones.
>
> Grâce à cette commande, je n'ai eu aucun mal à découper ce monstre :
>
> https://www.palabritudes.net/~zebulon/polygone-geant-1.png
>
> Pour en faire cela :
>
> https://www.palabritudes.net/~zebulon/polygone-geant-2.png
>
> Ce qui m'a permis, sur la zone en rouge ci-dessous :
>
> https://www.palabritudes.net/~zebulon/polygone-geant-3.png
>
> De passer de ça :
>
>
> https://www.palabritudes.net/~zebulon/polygone-geant-zone-traitee-20180926.png
>
> à ça :
>
>
> https://www.palabritudes.net/~zebulon/polygone-geant-zone-traitee-20181017.png
>
> Et au cours d'un tel travail, les raccourcis W et F sont eux aussi
> précieux.
>
> A++, 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Sébastien Dinot]

Christian Quest a écrit :
> *W / "Way Improve"*
> [...]
> 
> *F / "Follow Line"*
> [...]

Ma productivité prendrais en effet une claque si je n'utilisais pas ces
2 raccourcis.

En autre très utile à connaitre lorsqu'on décide d'affiner la couverture
du sol dans une zone de polygones grossiers :

*Alt-X*

Cette commande coupe en deux polygones le polygone sélectionné.

Mode opératoire :

1. Sélectionner le polygone à découper.

2. Sélectionner les 2 points constituant les sommets de la coupe.

3. Appuyer sur Alt-X

NB : L'étape 1 est inutile s'il n'y a pas d'ambiguité sur le polygone
 considéré (i.e.e si les sommets sélectionnés à l'étape
 2 n'appartiennent pas à plusieurs polygones.

Grâce à cette commande, je n'ai eu aucun mal à découper ce monstre :

https://www.palabritudes.net/~zebulon/polygone-geant-1.png

Pour en faire cela :

https://www.palabritudes.net/~zebulon/polygone-geant-2.png

Ce qui m'a permis, sur la zone en rouge ci-dessous :

https://www.palabritudes.net/~zebulon/polygone-geant-3.png

De passer de ça :

https://www.palabritudes.net/~zebulon/polygone-geant-zone-traitee-20180926.png

à ça :

https://www.palabritudes.net/~zebulon/polygone-geant-zone-traitee-20181017.png

Et au cours d'un tel travail, les raccourcis W et F sont eux aussi
précieux.

A++, 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-fr] pb sur un cset lié aux langues locales

[Vincent Bergeot]

Le 04/01/2020 à 12:26, Christian Quest a écrit :
Le sam. 4 janv. 2020 à 11:12, Vincent Bergeot > a écrit :


Ok, mais c'est "anecdotique" par rapport à tout le reste. Que dans
ce cas cela soit une erreur de manip, ok mais dans les autres cas,
au vu de la fréquence et des volumes traités c'est peut-être des
mauvaises manips mais systématiques.

Pour l'instant l'utilisateur est bloqué, merci à ceux qui ont
commencé à nettoyer les différentes modifications (par exemple
retrait de la source quand pas de name :) )

Que pensez vous de ce type d'ajout :
https://www.openstreetmap.org/node/6444915153/history

Pour moi, cela pose 2 questions principales :

  * pourquoi ajouter une source à une traduction qui existe depuis
8 mois (voire dans le cas de Bordeaux le name:oc=Bordèu a été
ajouté il y a 5 ans, la source hier )
  * est-ce que cette source est libre de la bd topo ?
http://bdtopoc.org/ je ne trouve pas de traces ni de la
licence ni de la base de donnée (bon je n'ai pas passé des
heures non plus !)

à plus

L'ajout de source:name:oc me semble permettre de confirmer que c'est 
bien le bon nom en occitan d'après un référentiel officiel.


Pour la licence, je n'ai plus l'historique, mais nous avons eu des 
contacts très positifs passés et il me semble qu'il n'y a aucun problème.


Je ne comprends pas trop ce que je perçois comme un énervement, on est 
loin du vandalisme quand même !



Si c'est perçu comme de l'énervement, je m'en excuse, ce n'est pas le 
but (j'adore en plus l'idée d'une carte occitane !).


C'est surtout de l'incompréhension. Ok, ce n'est pas du vandalisme par 
intention je n'ai aucun doute la dessus, mais les modifications me 
semblent bien trop importantes  pour que cela cela apporte une 
confirmation de la validité du name car cela concerne quelques milliers 
de noms (mais je suis prêt à changer d'avis et surtout à comprendre 
comment c'est réalisé !). Le coté automatique y compris les ajouts quand 
il n'y a pas de name (ce que tu as corrigé Christian, si j'ai compris), 
les traductions des arrêts de bus (ok, ils sont tous traduits à Toulouse


Et ensuite c'est l'absence de réponse, faire des dizaines de milliers de 
modifications à un rythme très soutenu, ne pas avoir de réponse sur la 
licence


à plus

--
Vincent Bergeot

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

Re: [talk-au] presenting #NorthernBeachesSolar pet project

[Sebastian S.]

Thanks for the tasking manager tip. Will have a look.

Regarding start date I thought since I don't know the exact date I chose the 
one from the images.
Once images are updated the source date could be updated while the start date 
stays.

Can we go back in time with LPI images?

On 4 January 2020 9:20:15 am AEDT, Andrew Harvey  
wrote:
>Nice work, would love to see more roof top solar panels mapped.
>
>The Tasking Manager https://wiki.openstreetmap.org/wiki/Tasking_Manager
>might
>suit this better than MapRoulette, since Tasking Manager breaks an area
>up
>into tiles and you go in, choose a tile, complete it, then upload. It
>helps
>track progress, avoid conflicts and ensures a whole area is done
>without
>gaps in coverage.
>
>MapRoulette works differently, it's based on identifying features
>already
>which need some work.
>
>> start_date=* - set to the date of the LPI NSW Imagery - or should
>this be
>rather source:date=*??
>
>start_date is when the feature started, so when the solar panel was
>installed, you can just do  if you only know the year or -MM if
>you
>only know the month, but if you don't know you can omit it. source:date
>is
>better for the imagery date.
>
>On Thu, 2 Jan 2020 at 08:50, Sebastian S.  wrote:
>
>> So far I have not worked out a good grid method.
>> I go by suburb in my area and keep the file local until I've
>completed the
>> suburb. Only then I upload.
>> While offline I use a temporary area tagged as wood. I expand this
>box
>> over the area I've worked through. This is just because I don't know
>any
>> better solution. 
>>
>> If you want to see a map showing the modules you can use open
>> infrastructure map, link is at the bottom of the wiki.
>>
>> I thought about making this a mapping challenge on
>> https://wiki.openstreetmap.org/wiki/MapRoulette but so far I've not
>> looked into it. I've got no experience with this but am happy to
>receive
>> guidance.
>>
>>
>> On 2 January 2020 7:11:07 am AEDT, Dion Moult 
>wrote:
>>>
>>> On Wed, Jan 01, 2020 at 11:29:13PM +1100, Sebastian Spiess wrote:
>>>
 I'd like to present my latest pet project:

>https://wiki.openstreetmap.org/wiki/User:ConsEbt/NorthernBeachesSolar
 I wanted to share this and collect some feedback or comments.

>>>
>>> I love it! I might do a bit of solar mapping too! How easy is it to
>set a grid
>>> to know which areas have been mapped?
>>>
>>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk-fr] Ces raccourcis JOSM que l'on découvre "trop tard"

[Christian Quest]

J'ouvre ce fil de discussion pour partager des fonctions de JOSM, qu'on
découvre souvent "trop tard", du genre si j'avais su que ça existait,
j'aurai gagné tellement de temps (de clics).

J'en partage deux pour commencer:

*W / "Way Improve"*
Il permet d'affiner le tracé d'un way en déplaçant les existants à chaque
fois d'un simple clic, en ajoutant des noeuds (ctrl-clic) voir pour
supprimer des noeuds (alt-clic)
Idéal pour améliorer le tracé d'une route ou d'un landuse.
Doc ici: https://josm.openstreetmap.de/wiki/Help/Action/ImproveWayAccuracy

*F / "Follow Line"*
Même plus besoin de cliquer... lorsqu'on veut suivre un way existant (par
exemple pour le tracé des landuse), dès que deux noeuds consécutifs ont été
tracé sur ce way, un F ajoute le suivant, etc...
^ celui là je viens de le découvrir après 10 ans d'utilisation de JOSM...
je ne sais pas depuis quand il existe.
Doc: https://josm.openstreetmap.de/wiki/Help/Action/FollowLine


N'hésitez pas à compléter, par des trucs simples pour commencer ;)
KISS

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

Re: [Talk-at] Stop area groups

[Robin Däneke]

Hallo,

Bei einfachen Stationen finde ich es echt sinnlos, da mehrere Stop areas zu 
machen, da ich den Sinn der Stop area so verstehe, dass man damit eben 
verschiedene Haltepunkte, die zur selben Station gehören zusammenfasst. Die 
Stop area-group macht für mich nur Sinn, wenn es entweder zwei verschiedene 
Stationen mit ihren eigenen Stop-areas sind, die sehr nahe zusammen liegen (so 
könnte man Stationskomplex-Teile mit verschiedenen Namen zusammenfassen), oder, 
wenn es, wie etwa beim Hauptbahnhof verschiedene Berehe gibt, zwischen denen 
ein Umstieg einer Pilgerreise ähnelt (U1-Zug Bhst 3ff / 
Fernbusse-Straßenbahn...)
Aber so in Öffitypen aufgesplittet ergibt es für mich in Sachen GeoDB keinen 
Sinn. Wenn das so in einer Datenbank für etwa ein RBL erfasst wäre, ok, aber 
nicht in der OSM. Vor allem, was macht der gute User, wenn Bus- und 
Tram-Station Dekungsgleich sind?

Man könnte den User der das macht aber auch mal fragen, warum. Und ob er es 
nicht vielleicht zumindest etwas geographischer angehen könnte.

Falls es sich dabei um den User Diego Sanguinetti handelt, der scheint für 
diese MAPS.me subway Gruppe zu mappen. Die haben ja leider auch eine eigene 
Vorstellung wie die Daten aussehen sollen...

Mit freundlichen Grüßen
RobinD (emergency99)


Von: andreas wecer 
Gesendet: Samstag, 4. Jänner 2020 08:50
An: OpenStreetMap AT 
Betreff: Re: [Talk-at] Stop area groups

Ich habe mich auch gerade über die Verschachtelung bei diesem Node hier 
gewundert:
https://www.openstreetmap.org/node/5959356915

Der bus_stop "Baden Landesklinikum" ist Teil der stop_area Relation "Baden 
Landesklinikum (bus)", die nur aus diesem Node besteht und wiederum wie die 
direkt nebenan liegende Relation "Baden Landesklinikum (WLB)" zur 
stop_area_group "Baden Landesklinikum" gehört.
Die Suffixe tauchen nur in den stop_area Relationen und nicht in den konkreten 
Stop-Nodes auf, also ist die Struktur an sich schon nachvollziehbar, aber ohne 
mich näher mit dem public_transport Thema beschäftigt zu haben, würde ich 
erwarten, dass stop_area_group komplexe Stationen übersichtlicher machen und 
nicht einfache komplexer machen sollte.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] JOSM: Display time of a gpx track

[tshrub]

Am 03.01.20 um 23:02 schrieb Tom Pfeifer:

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/InfoMode
is your friend:

   *  Displaying GPX trackpoint info - timestamp, velocity, height, 
track name and length.

   *  Hiding individual tracks and tracks older than selected.

tom


Great! Thanks, it works. :-)
xubuntu 19.19, josm 15628

... so far:

first: I cannot see the coordinate values and unfortunately(!) you 
cannot copy the point values, only delete them. I wanted to add the 
coordinates in certain photos (exiftool) ...


the two small display errors of the plugin:
the popup runs out of the right edge of the screen, because the fourth 
line does not convert html markups () and
it remains absolutely in the foreground, no matter what other 
application windows are in front of JOSM.

I have created a "ticket" ...







On 03.01.2020 19:36, tshrub wrote:

hi,
if I load gpx data as layer, how can I see the points & time from those?
With an extension I can see heights, that's fine.
Is there anything similar for the time - maybe popup-like when moving 
the mouse over it?

regards


___
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] pb sur un cset lié aux langues locales

[Christian Quest]

Le sam. 4 janv. 2020 à 11:12, Vincent Bergeot  a
écrit :

> Ok, mais c'est "anecdotique" par rapport à tout le reste. Que dans ce cas
> cela soit une erreur de manip, ok mais dans les autres cas, au vu de la
> fréquence et des volumes traités c'est peut-être des mauvaises manips mais
> systématiques.
>
> Pour l'instant l'utilisateur est bloqué, merci à ceux qui ont commencé à
> nettoyer les différentes modifications (par exemple retrait de la source
> quand pas de name :) )
>
> Que pensez vous de ce type d'ajout :
> https://www.openstreetmap.org/node/6444915153/history
>
> Pour moi, cela pose 2 questions principales :
>
>- pourquoi ajouter une source à une traduction qui existe depuis 8
>mois (voire dans le cas de Bordeaux le name:oc=Bordèu a été ajouté il y a 5
>ans, la source hier )
>- est-ce que cette source est libre de la bd topo ? http://bdtopoc.org/
>je ne trouve pas de traces ni de la licence ni de la base de donnée (bon je
>n'ai pas passé des heures non plus !)
>
> à plus
>

L'ajout de source:name:oc me semble permettre de confirmer que c'est bien
le bon nom en occitan d'après un référentiel officiel.

Pour la licence, je n'ai plus l'historique, mais nous avons eu des contacts
très positifs passés et il me semble qu'il n'y a aucun problème.

Je ne comprends pas trop ce que je perçois comme un énervement, on est loin
du vandalisme quand même !

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

Re: [OSM-talk] SotM 2020: Scholarship review team

[Joseph Eisenberg]

Deadline is 3 days from now? If the goal is to to include a wider variety
of people from many countries, a longer deadline and messages in many
languages would be a good idea.

-Joseph Eisenberg

On Sat, Jan 4, 2020 at 7:40 PM Christine Karch 
wrote:

> Hi all,
>
> SotM WG is looking for help and for support by the community!
>
> SotM 2020 will provide a scholarship program - as we did all the years
> before. In past year for SotM 2019 the review team was mainly formed by
> the scholars of SotM 2018 and of volunteers of the local team and the
> SotM working group. We want to change this (step by step) and be more
> open to a wider community. So we ask for your help:
>
>
> https://framaforms.org/join-the-state-of-the-map-2020-scholarships-review-team-1577509125
>
> Deadline is January 7, 2020.
>
> Please spread this to all your local mailinglists and OSM friends. I
> would appreciate a larger involvement!
>
> Kind regards,
>
> Christine
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] SotM 2020: votre soutien et implication

[Christine Karch]

Bonjour,

SotM WG recherche de l'aide et du soutien de la communauté!

SotM 2020 offrira un programme de "scholarship" - comme nous l'avons
fait toutes les années avant. Pour SotM 2019, l'équipe était
principalement composée des scholars de SotM 2018 et des bénévoles de
l'équipe locale et du SotM WG. Nous voulons changer cela (étape par
étape) et être plus ouvert à une communauté plus large. Nous vous
demandons donc votre aide:

https://framaforms.org/join-the-state-of-the-map-2020-scholarships-review-team-1577509125

Deadline est le 7 janvier 2020.

Christine

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

[OSM-talk] SotM 2020: Scholarship review team

[Christine Karch]

Hi all,

SotM WG is looking for help and for support by the community!

SotM 2020 will provide a scholarship program - as we did all the years
before. In past year for SotM 2019 the review team was mainly formed by
the scholars of SotM 2018 and of volunteers of the local team and the
SotM working group. We want to change this (step by step) and be more
open to a wider community. So we ask for your help:

https://framaforms.org/join-the-state-of-the-map-2020-scholarships-review-team-1577509125

Deadline is January 7, 2020.

Please spread this to all your local mailinglists and OSM friends. I
would appreciate a larger involvement!

Kind regards,

Christine

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

Re: [OSM-talk-fr] Requête OverpassTurbo

[Vincent Bergeot]

Le 04/01/2020 à 00:46, Donat ROBAUX a écrit :

- comment requêter sur plusieurs zones géographiques en même temps, ex: 2
départements?


Un exemple si tu as soif sur la rive droite de Bordeaux :)

(area[admin_level=8][name=Lormont]; area[admin_level=8][name=Cenon]; 
area[admin_level=8][name=Cenon]; area[admin_level=8][name=Floirac]; 
area[admin_level=8][name=Bassens];)->.a;


nwr[amenity=drinking_water](area.a)
;

out center;

--
Vincent Bergeot


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

Re: [OSM-talk-fr] pb sur un cset lié aux langues locales

[Vincent Bergeot]

Bonjour,

Le 03/01/2020 à 18:40, Christian Rogel a écrit :

Le 2 janv. 2020 à 16:34, Landry Breuil  a écrit :
pas fait d'OSM depuis un bail, mais en me promenant dans un coin que je
connais bien (lieu dit nommé 'le pous' ou 'lou pous' sur les panneaux
sur place), dans osmand (et sur la carte d'osm.org) j'ai eu la surprise
de voir 'Le Potz' qui est un nom completement inconnu sur place. - le
nom était correct pour moi auparavant (cf
https://www.openstreetmap.org/node/2077266629/history il y'a 8 mois), et
a été modifié par oc-OpenStreetMap dans le changeset
https://www.openstreetmap.org/changeset/70878777 .

J’ai passé l’information au président de l’IEO qui m’indique qu’il s’agirait 
d’une mauvaise manip
accompagnant un sourçage, mais, sans aucune intention de corriger les « name ».


Ok, mais c'est "anecdotique" par rapport à tout le reste. Que dans ce 
cas cela soit une erreur de manip, ok mais dans les autres cas, au vu de 
la fréquence et des volumes traités c'est peut-être des mauvaises manips 
mais systématiques.


Pour l'instant l'utilisateur est bloqué, merci à ceux qui ont commencé à 
nettoyer les différentes modifications (par exemple retrait de la source 
quand pas de name :) )


Que pensez vous de ce type d'ajout : 
https://www.openstreetmap.org/node/6444915153/history


Pour moi, cela pose 2 questions principales :

 * pourquoi ajouter une source à une traduction qui existe depuis 8
   mois (voire dans le cas de Bordeaux le name:oc=Bordèu a été ajouté
   il y a 5 ans, la source hier )
 * est-ce que cette source est libre de la bd topo ?
   http://bdtopoc.org/ je ne trouve pas de traces ni de la licence ni
   de la base de donnée (bon je n'ai pas passé des heures non plus !)

à plus


--
Vincent Bergeot

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