[talk-ph] Tie Points

2019-04-10 Diskussionsfäden Jim Morgan
Hi,

Figured there might be a few people on the list familiar with the concept of 
tie points here and in particular in connection with the Land Registry in the 
Philippines. 

I'm trying to solve a problem for a friend and need some help, so maybe contact 
me off list if you can help. There will be some consulting work in it if you're 
interested. 

Jim

-- 



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


Re: [talk-au] Shout out

2019-04-10 Diskussionsfäden Graeme Fitzpatrick
On Thu, 11 Apr 2019 at 10:14, Sebastian S.  wrote:

> So what is a good approach to do here?
> Ideally we could encourage the participant to make better valued
> contributions.
> E.g. by
> A) proper tagging
> B) use of Most recent images
> C) changest comments
>
> But how to reach him best?
>

& thank them very much for their wonderful efforts! :-)

Either start a discussion on a changeset, or send a message via their user
page "should" reach them?

Thanks

Graeme

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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden Grigory Rechistov via Talk-se
Hej,
Här är en liten rapport på sammanblandningsprocessen. Mitt skript visar 
någonting intressant, men det kräver några förbättringar innan det blir 
brukbart på riktigt. Vad är bra är att skriptet är väldigt snabbt. Som förut 
använder jag Vingåkers kommun som ett exempel där mycket skogsyta inte är 
kartlagd.

1. Här är vad som redan finns i OSM-databasen:  
https://atakua.org/p/nmd/conflation/vingaker-befintlig.png . Lite skog och 
åkermark här och där.
2. Här är hur importlagret ser ut innan "conflation":  
https://atakua.org/p/nmd/conflation/vingaker-importlager-fore.png . Mycket tätt 
skog överallt.
3. Här är importlagret efter bearbetningen:  
https://atakua.org/p/nmd/conflation/vingaker-importlager-efter.png . Man kan se 
nya ungefärligt rektangulära hål i skogar.
4. Om man samtidigt kollar importlagret och gamla datat ser man att hålen 
motsvarar till platser där skog redan finns på det nedre lagret:  
https://atakua.org/p/nmd/conflation/vingaker-importlager-med-bakgrund.png

Det är precis min avsikt — att gamla och nya data inte överlappar varandra. 
Varför blir hålen rektangulära? Eftersom jag använder rektangulära "bounding 
boxes" för att upptäcka eventuella överlappningar. Jo, man tappar lite data av 
importlagret på grund av  onödiga raderingar, men man undviker värre problem 
med motsägelsefulla objekt. Dessutom är "bounding boxes" galet snabbare än att 
försöka ta reda på huruvida två friformade polygoner korsas eller inte.

Slutsatser:
1. Mer uppmärksamhet på multipolygonerna. De är nämligen otänkbart finurliga.
2. Mer datafiltrering. Fortfarande för mycket fina små detaljer som måste bort.


Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [talk-au] Shout out

2019-04-10 Diskussionsfäden Sebastian S.
So what is a good approach to do here?
Ideally we could encourage the participant to make better valued contributions.
E.g. by 
A) proper tagging
B) use of Most recent images
C) changest comments

But how to reach him best?
Regards Sebastian
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 11 April 2019 8:02:29 am AEST, Graeme Fitzpatrick  
wrote:
>On Wed, 10 Apr 2019 at 18:12, David Wales 
>wrote:
>
>>
>> Probably worth loading up some LPI NSW imagery and seeing if things
>look
>> legitimate.
>>
>
>When you go into edit mode, it certainly appears that way.
>
>The person concerned is still very busily mapping, at the moment down
>Holsworthy way.
>
>I wonder if it may be somebody working for Microsoft or similar, purely
>using imagery, as there are no comments on any of their edits, nothing
>is
>named (eg retail buildings, schools etc), & the source on everything is
>Bing?
>
>I think I may have actually tried to contact them once before, to
>clarify a
>discrepancy between current maps & available imagery that I spotted via
>a
>Map Roulette challenge, but never got a response?
>
>Thanks
>
>Graeme
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [OSM-talk] Software configuration | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Yuri Astrakhan
On Wed, Apr 10, 2019 at 5:04 PM Rory McCann  wrote:

> In JOSM, people, or groups, can make their own tagging presets. AFAIK iD
> unfortunately doesn't have this feature. If it did, the iD version on
> openstreetmap.org could be configured to something special, people could
> have their personal tagging presets "saved" somehow, maybe one could
> "load other presets from a remote address" via a URL parameter, allowing
> one to "load a preset with a link".


Rory, I am actually hopping data items could become a general preset
storage for all editors. Each preset would be stored as a data item, and
editors would use a script to convert preset into a JSON file, or
eventually use it directly.  This approach has a number of advantages:

* easy to edit by community, track changes, and fix/revert in case of an
error
* easy to translate - one click description editing for every possible
language
* easy to verify / validate / cross-check - there are many ways to query
presets and to run validations on them, so an invalid preset can be quickly
fixed/reverted
* part of wiki - presets can be viewed as part of the regular wiki pages,
e.g. on a Tag:... page
* easy to add pictures and icons - part of wiki, or from commons - just
another property
* easy to categorize/partition presets - just another property to add
preset into a category, or have a whole category tree.
* easy to extend schema - just add more properties to target a new editor
feature - other editors will simply ignore it.
* ties with all other keys / tags / relations / relation roles -- if a
preset requires a tag, it is not a string, it is actually a reference to
that tag, with its own properties.
* easy to build custom UI -- structured data allows developers to have
custom editors for those presets

Obviously this has to be done in a non-disruptive, gradual way, and having
good quality control. I'm still researching on the best way to achieve this.

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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden Grigory Rechistov via Talk-se
>Är alla delar scripade, detta låter som ett manuellt steg?
Att konvertera etiketter och gallra datafil är skripterade. Det är 
konverteringen mellan olika vektorfilformat som fortfarande kräver manuellt 
arbete. Anledningar till detta:

1. Chaiken-filtern är tillgänglig endast i QGIS/GRASS. Och den är väsentlig för 
att kamma "trappsteg" i vektorn på behagligaste sättet.
2. QGIS förstår SHP och GML som vektorformat. SHP är lite korkat. Precis nu 
konverterar jag rasterfilerna av kommuner till GML-vektor (Kirunas kommun är 
den största...)
3. JOSM kan inte öppna GML, trots att man påstår här att den kan:  
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData , funkar den 
insticksmodulen inte.
3. JOSM läser fel SHP — taggarna tappas bort.
4. QGIS kan skriva till GeoJSON vilket JOSM kan öppna. Tack och lov! Men 
GeoJSON-insticksmodulen har sina buggar vid importen, t.ex.  
https://github.com/JOSM/geojson/issues/29 samt multipolygonerna blir felladdade 
också.
5. JOSM kan konvertera GeoJSON till OSM-XML som man kan senare gallra, rätta 
till osv. och sedan mata tillbaka till JOSM.

Usch! Jag lyckades ta bort ett extra steg idag men det kräver fortfarande flera 
manuella steg: GML -> GeoJSON -> OSM.

Och sedan blir conflation något manuellt arbete oavsett om man besegrar 
vektorformats galenskap eller inte. Nu håller jag på att förenkla conflation så 
mycket som möjligt.

>Среда, 10 апреля 2019, 20:37 +03:00 от Erik Johansson :
>
>On Wed, Apr 10, 2019 at 5:52 PM Grigory Rechistov via Talk-se
>< talk-se@openstreetmap.org > wrote:
>> 4. Konvertera etiketter, gallra datafil.
>
>Är alla delar scripade, detta låter som ett manuellt steg?


С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [OSM-talk] Software configuration | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Jóhannes Birgir Jensson
iD seems to have this feature via MapRules: 
https://github.com/openstreetmap/iD/pull/5617 


10. apríl 2019 kl. 21:08, skrifaði "Rory McCann" :

> On 07.04.19 14:43, John Whelan wrote:
> 
>> Tagging is not always easy, but I do have concerns when iD is so
>> commonly used but the recommended tags do not align with OpenStreetMap
>> I'll say normals.
>> 
>> Specifically one of my concerns is a semi-detached house is not
>> recognised in iD only the more general tag house.
> 
> In JOSM, people, or groups, can make their own tagging presets. AFAIK iD
> unfortunately doesn't have this feature. If it did, the iD version on
> openstreetmap.org could be configured to something special, people could
> have their personal tagging presets "saved" somehow, maybe one could
> "load other presets from a remote address" via a URL parameter, allowing
> one to "load a preset with a link". Then each iD user wouldn't be able
> to complain to the iD developers. But that's not possible now.
> 
> For now, the OSM wiki voting isn't binding, the people who make editors
> have a lot of control. I'm sure patches & feature requests would be
> welcome
> 
> ___
> 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-au] Shout out

2019-04-10 Diskussionsfäden Graeme Fitzpatrick
On Wed, 10 Apr 2019 at 18:12, David Wales  wrote:

>
> Probably worth loading up some LPI NSW imagery and seeing if things look
> legitimate.
>

When you go into edit mode, it certainly appears that way.

The person concerned is still very busily mapping, at the moment down
Holsworthy way.

I wonder if it may be somebody working for Microsoft or similar, purely
using imagery, as there are no comments on any of their edits, nothing is
named (eg retail buildings, schools etc), & the source on everything is
Bing?

I think I may have actually tried to contact them once before, to clarify a
discrepancy between current maps & available imagery that I spotted via a
Map Roulette challenge, but never got a response?

Thanks

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


Re: [Talk-GB] RFC: Solar panel mapping in the UK

2019-04-10 Diskussionsfäden Dan S
Hi all,

Thanks for the comments on solar panel mapping. (Plenty of mapping
happening already: thousands of UK solar panels added to the database
in the past month.) A few small responses:

SOLAR FARMS:

I'll defer to Russ's tagging advice about solar farms: power=plant
polygon (or sometimes multipolygon) as the outline of a solar farm,
with power=generator areas contained within it for the blocks of
panels. Previously, I was mapping solar farms as relations, but I'm
easily persuaded!

I don't have any advice about landuse/landcover other than that it's a
fairly separate issue, since those tags are not essential to the solar
power mapping.

I've been adding some solar farms that are listed in the REPD list on
the wiki. For those ones I've used a tag "repd:id=*" which I hope
makes it easy to identify them using the ID number in that database.
Some solar farms have more than one entry in the REPD (they submit a
new application form when they have an expansion).

ROOFTOP SOLAR:

For various reasons, if we can get solar installations mapped as areas
not just nodes, that'll be helpful. Areas will be more useful than
module-counting. However, I've noted that the imagery doesn't always
make this easy for rooftop solar: clarity is variable per region.

Is there any good way to tag the vertical tilt of a panel? I know in
many cases we won't be able to measure it well, but I thought I'd ask.
For example, there's roof:angle=* for the slope of a roof, which is a
mildly related concept.

Cheers
Dan

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


Re: [Talk-GB] Solar data

2019-04-10 Diskussionsfäden Russ Garrett
Hey Rob,

On Wed, 10 Apr 2019 at 22:30, Rob Nickerson  wrote:
> As the image (linked to below) from a WPD public webinar shows it is not easy 
> to map separate solar sites based in a single location. No way to tell which 
> panels belong to which site from aerial imagery alone.

Hah! That's a particularly pathological case, and I think it's a
situation where an extension project has been given a different name
from the original farm. A quick glance at the REPD indicates that
Copley Wood doesn't appear as an installation - I suspect it might be
down as "Higher Hill" and "Higher Hill (extension)" which would make
more sense. If that's the case I'd be inclined to map the entire area
as "Higher Hill" with the combined output of both.

What we don't have at the moment is any accepted way of dealing with
extensions and other sub-divisions of power plants. This is especially
problematic with some solar farms (especially older ones), which
started out as a very small installation but were significantly
extended later. I think they should be represented as a single entity
- at least at the top level - as the distinction between various
phases/extensions is really only of academic interest.

> The Renewable Energy Planning Database is one source of info. The government 
> have outsourced the task of tracking the growth of renewables to the company 
> listed on the file. They look at planning applications and speak with 
> developers. The capacity data is not always right as a developer may change 
> their plans. Also there are cases where some Wind sites are split into 2 as 
> the cross an admin boundary. In reality it is one Wind Farm site.

I'm trying to massage the REPD data into a more easily browsable
format (with clear licensing) at the moment - I'll see if I can get
some of those other datasets in there as well.

Cheers,

-- 
Russ Garrett
r...@garrett.co.uk

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


Re: [Talk-ro] name= pentru drumurile comunale, de ce?

2019-04-10 Diskussionsfäden Strainu
În mie., 10 apr. 2019 la 15:23, Vlad Sîngeorzan  a scris:
>
> Cred că echipa lui Anatolie ar fi urmat a modifica toate drumurile din 
> România după modelul acela, nu doar DC-urile, nu este vorba de tratament 
> special. Puteți vedea că în zona Arad că au început a denumi și DJ astfel.
> Ideea acuma ar fi dacă suntem de acord cu schema aceasta. Din punctul meu de 
> vedere dacă vrem să punem localitățile prin care trece s-ar potrivi mai 
> degrabă folosirea unor taguri de genul from= și to=, dar acestea sunt în 
> prezent rezervate rutelor de transport public.
> În general, în alte țări văd că drumurile sunt marcate doar prin ref=, fără 
> name=, înafara Olandei și a Belgiei care se pare că au o denumire oficială 
> pentru orice drum de țară (probabil că există reglementat și fiecare fermă 
> are o adresă; nu sunt denumiri construite precum este în cazul nostru).
> Mi s-ar părea normal să dăm nume doar când avem un nume de stradă în 
> interiorul localitățiilor sau când vor apărea denumiri consacrate ale 
> drumurilor, gen Autostrada Soarelui, Centura Brașov și sunt marcate și 
> cunoscute sub această denumire.
>
> Străinu, țin să te contrazic cu DC191, înțeleg că tu știi realitatea de pe 
> teren, dar făcând puțin research în documente oficiale se pare că drumurile 
> sunt altfel pe hartă decât pare.
> https://drive.google.com/file/d/1Oy6guuYLb7sh2lfJOhdMP9q32dFT4CjG/view?usp=sharing
>  în lista drumurilor din România se poate vedea cum că DC191 e Obedeni - 
> Anghelești, nu știu cât de oficiale și legale sunt documentele acestea, dar 
> aceste documente par a fi sursa principală inclusiv a datelor de pe OSM.
> Pe harta județului de pe site-ul primăriei Giurgiu apare așa cum e în mod 
> actual pe OSM: 
> http://www.primariagiurgiu.ro/portal/giurgiu/primarie/portal.nsf/All/1961B31FC1C65987C225812A0048439B/$FILE/01.ACAD-SBL-PI.pdf
> În HG 713/07.06.2006 se încadrează drumul Vadu Lat - DC 191 ca și DC 192, 
> deci așa cum putem vedea pe Google Maps: 
> http://legislatie.just.ro/Public/DetaliiDocument/72541
> Iar pe site-ul firmei betacops apare că se laudă cum că ei au construit un 
> "Pod pe DC191 km 0+900 peste canal de descarcare la Obedeni;" 
> http://www.betacops.ro/content/poduri%E2%80%93proiecte-tehnice . Acestă 
> descriere s-ar potrivi acestui pod: 
> https://www.mapillary.com/map/im/6fOySpYZNk_nPxvWBoVlgQ cred că e acesta prin 
> eliminare, deoarece în zonă există doar 3 poduri, unul în Vadu Lat peste râul 
> Neajov, altul peste Dâmbovnic, iar acesta este singurul care pare a fi peste 
> un canal de descărcare în zona Odobeni.
>
> În schimb am găsit și informații care atestă că DC191 ar fi Valu Lat - 
> Anghelești în presă, la inundațiile din 2014 și 2018:
> https://adevarul.ro/locale/giurgiu/judetul-giurgiu-avertizare-cod-portocaliu-inundatii-drumuri-inchise-mii-hectare-teren-ape-1_5aa3f6f4df52022f756792a3/index.html
> https://adevarul.ro/locale/giurgiu/15-localitati-judetul-giurgiu-afectate-inundatii-6-drumuri-inchise-circulatiei-1_548ae514448e03c0fdafdb23/index.html
> https://www.mediafax.ro/social/inundatii-in-tara-treisprezece-localitati-din-giurgiu-afectate-cursuri-suspendate-si-drumuri-inchise-in-teleorman-13714842
> https://www.romaniatv.net/peste-30-de-localitati-din-zece-judete-afectate-de-inundatii_408117.html
>
> Aș spune că datele nu par a fi copiate de pe Google Maps ci făcute pe 
> documentelor oficiale din România.

Așa s-ar părea. Eu m-am luat după proiectul "Modernizare drum comunal
DC 191 în comuna Bucșani, județul Giurgiu" care s-a întâmplat în 2014
și care a constat în reconstrucția podului peste Neajlov și asfaltarea
întregului triunghi, însă HG 713 pare să fie încă în vigoare. Îmi cer
scuze că nu m-am documentat suficient.

Cât privește subiectul discuției, dacă pentru DC capetele ar avea un
oarecare sens, pentru DJ/DN chiar nu sunt suficiente. De dragul
uniformității, și eu zic că nu ar trebui date nume decât unde există.

Strainu

>
> În mie., 10 apr. 2019 la 11:40, Strainu  a scris:
>>
>> Anatolie,
>>
>> OSM nu este și nu ar trebui făcut doar pentru navigație. La fel ca la DN, 
>> lista drumurilor județene [1] identifica drumurile printr-un număr și 
>> menționează cele mai importante localități prin care trece. Nu văd de ce nu 
>> s-ar aplica aceleași reguli și la DC.
>>
>> Și mai e o chestie: ca să aibă sens pe teren, harta trebuie să semene cu 
>> indicatoarele și bornele. Pe DC nu prea am văzut indicatoare, dar borne mai 
>> sunt, în special pe cele refăcute cu fonduri europene, iar bornele nu indica 
>> întotdeauna capătul drumului, ci doar următorul sat și numărul.
>>
>> Nu mai puțin important, datele voastre au și greșeli foarte foarte suspecte, 
>>  vezi de exemplu https://www.openstreetmap.org/way/40699328 Drumul ăla e 
>> Vadu Lat-Anghelești, dar cel mai problematic e că apare Obedeni-Anghelesti 
>> doar la google maps și site-uri derivate. Sper că știți și respectați faptul 
>> că nu poți importa date de la Google Maps.
>>
>> Cred că în interesul corectitudinii 

[Talk-GB] Solar data

2019-04-10 Diskussionsfäden Rob Nickerson
Hi all,

Been watching the thread on Solar. A couple of comments.

1 Boundaries.
As the image (linked to below) from a WPD public webinar shows it is not
easy to map separate solar sites based in a single location. No way to tell
which panels belong to which site from aerial imagery alone.

https://drive.google.com/file/d/0B6J5ZA1hu93bT3FoS2lBVXZQRzNMTkgzVTg1ZE9GbHVwTXZj/view?usp=sharing

2 Data
The Renewable Energy Planning Database is one source of info. The
government have outsourced the task of tracking the growth of renewables to
the company listed on the file. They look at planning applications and
speak with developers. The capacity data is not always right as a developer
may change their plans. Also there are cases where some Wind sites are
split into 2 as the cross an admin boundary. In reality it is one Wind Farm
site.

Other, potentially more useful sources are the Renewable Obligation
register (the register by which subsidies are paid) which includes
generating station address. For smaller sites the equivalent is the Feed In
Tarriff data. This incudes the first part of the postcode and the LSOA (ONS
area). Finally there is REGO (Renewable Energy Guarantees Origin). This is
the database to large sites register on if they want to sell renewable
energy to a supplier and the supplier wants proof it is coming from a
renewable source. Like the RO it has generating station address.

https://www.renewablesandchp.ofgem.gov.uk/
https://www.ofgem.gov.uk/publications-and-updates/feed-tariff-installation-report-31-december-2018

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


[OSM-talk] Software configuration | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Rory McCann

On 07.04.19 14:43, John Whelan wrote:
Tagging is not always easy, but I do have concerns when iD is so 
commonly used but the recommended tags do not align with OpenStreetMap 
I'll say normals.


Specifically one of my concerns is a semi-detached house is not 
recognised in iD only the more general tag house.


In JOSM, people, or groups, can make their own tagging presets. AFAIK iD 
unfortunately doesn't have this feature. If it did, the iD version on 
openstreetmap.org could be configured to something special, people could 
have their personal tagging presets "saved" somehow, maybe one could 
"load other presets from a remote address" via a URL parameter, allowing 
one to "load a preset with a link". Then each iD user wouldn't be able 
to complain to the iD developers. But that's not possible now.


For now, the OSM wiki voting isn't binding, the people who make editors 
have a lot of control. I'm sure patches & feature requests would be 
welcome



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


Re: [Talk-at] Hinweis Forumsthemen

2019-04-10 Diskussionsfäden Robert Grübler
Ist ein Link ein Crosspost?
Für mich nicht. Danke für den Hinweis auf eine hochinteressante Diskussion.

LG Robert

-Ursprüngliche Nachricht-
Von: gppes_...@web.de [mailto:gppes_...@web.de] 
Gesendet: Mittwoch, 10. April 2019 13:01
An: talk-at@openstreetmap.org
Betreff: [Talk-at] Hinweis Forumsthemen

Liebe Kollegen,

ich bin kein grosser Freund von Cross-Postings und verspreche solche Emails nur 
selten auszuschicken.

Fuer die Leute, die das Forum nicht so oft besuchen moechte ich aber auf 
folgende beide Themen, die ich durchaus interessant oder wichtig finde 
hinweisen:

1) OSM und "Privatsphaere" bei Einfahrten auf Privatgrundstuecken:
https://forum.openstreetmap.org/viewtopic.php?id=65913

2) Wann place=town verwenden, wann eher village oder sonstwas:
https://forum.openstreetmap.org/viewtopic.php?id=65610

Lg, Gppes

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


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


Re: [Talk-bf] [Talk-CI] INVITATION MAPATHON

2019-04-10 Diskussionsfäden Guy Maurel Konan
Merci pour le lien.
Cordialement,

**


[image: -]

Kouassi Guy Maurel KONAN
[image: https: //]about.me/guymaurelkonan


Web Entrepreneur
Consultant Cartographie & SIG Chez UNICEF Côte d'Ivoire

Consultant TIC & Cartographie Numérique
Co-fondateur #OSMCI I #BilletExpress
 I #NzassaNetwork 
Alumni I YALI DAKAR  I VIF


Contacts : (+225) 08 096 901 - 76 21 42 84
Mail : konanguymau...@gmail.com
Twitter : @konan_maurel
Skype : maurelkonan


Le mer. 10 avr. 2019 à 19:52, severin.menard 
a écrit :

> Bonsoir Maurel,
>
> Belle initiative, cependant il existe déjà depuis l'automne dernier une
> tâche créée par Arsène sur laquelle nous sommes quelques-uns à contribuer :
> http://taches.francophonelibre.org/project/276
>
> Séverin
>
>
>
> ‐‐‐ Original Message ‐‐‐
> Le mercredi 10 avril 2019 19:32, Guy Maurel Konan <
> konanguymau...@gmail.com> a écrit :
>
> Bonsoir à tous,
>
> Des Chiffres et Des Jeunes en collaboration avec la Fondation Performances
> Sociétales et la Communauté OpenSreetMap Côte d'Ivoire
> ,
> organisent le *Samedi 13 avril* au sein de l’ENSEA à l’université FHB de
> Cocody, le Mapathon de Daloa qui a pour objectif d’actualiser la carte de
> la ville de Daloa et effectuer une demande de cartographie des bâtiments
> et routes résidentielles en prélude de la phase de mapping.
>
> Nous vous invitons à nous rejoindre sur la tâche :
> https://tasks.hotosm.org/project/5910
>
> Cordialement,
>
>
> **
>
> [image: -]
>
>
> Kouassi Guy Maurel KONAN
> [image: https: //]about.me/guymaurelkonan
>
>
> Web Entrepreneur
> Consultant Cartographie & SIG Chez UNICEF Côte d'Ivoire
> 
> Consultant TIC & Cartographie Numérique
> Co-fondateur #OSMCI I #BilletExpress
>  I #NzassaNetwork
> 
> Alumni I YALI DAKAR  I VIF
> 
>
> Contacts : (+225) 08 096 901 - 76 21 42 84
> Mail : konanguymau...@gmail.com
> Twitter : @konan_maurel
> Skype : maurelkonan
>
>
>
___
Talk-bf mailing list
Talk-bf@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bf


Re: [OSM-talk-fr] [Talk-CI] INVITATION MAPATHON

2019-04-10 Diskussionsfäden severin.menard via Talk-fr
Bonsoir Maurel,

Belle initiative, cependant il existe déjà depuis l'automne dernier une tâche 
créée par Arsène sur laquelle nous sommes quelques-uns à contribuer : 
http://taches.francophonelibre.org/project/276

Séverin

‐‐‐ Original Message ‐‐‐
Le mercredi 10 avril 2019 19:32, Guy Maurel Konan  a 
écrit :

> Bonsoir à tous,
>
> Des Chiffres et Des Jeunes en collaboration avec la Fondation Performances 
> Sociétales et la Communauté OpenSreetMap Côte 
> d'Ivoirehttps://web.facebook.com/hashtag/openstreetmap?source=feed_text=HASHTAG&__xts__%5B0%5D=68.ARCsITKoWUxNbekGhnC9MlZnTvoh92rGGnT0bQedUaZ0SswqczhfneGn-T6_4e07CMg7GT8c8E7SH3QyLkDzAGoatOnxhFErBnbHnTWClvfSwbA32gcB2IW4FMxx4wjdbVP3d8CY18PWQuOpfGp0hi4ywc-9W1Xu-OGSs-M505I3mmVHEyk7aYiJf7JM1pBRVkTsQEZBVtJ3J7EfL89pPbNsenpfoKcOiR6wwgzOFoVORyekNZOSFK1yRI__AdbC4S00aqWzJY3pL4bbYah_ZfoTOi_uGfnucArdclrPmHTdKY0f9bJ-h972soEXvexw5D3X1x87AbemnQ2dYfWI7WM&__tn__=%2ANK-R,
>  organisent le Samedi 13 avril au sein de l’ENSEA à l’université FHB de 
> Cocody, le Mapathon de Daloa qui a pour objectif d’actualiser la carte de la 
> ville de Daloa et effectuer une demande de cartographie des bâtiments et 
> routes résidentielles en prélude de la phase de mapping.
>
> Nous vous invitons à nous rejoindre sur la tâche : 
> https://tasks.hotosm.org/project/5910
>
> Cordialement,
>
> 
>
> [-]
>   Kouassi Guy Maurel KONAN
> [https: //]about.me/guymaurelkonan
>
> Web Entrepreneur
> Consultant Cartographie & SIG Chez [UNICEF Côte 
> d'Ivoire](https://www.unicef.org/cotedivoire/)
> Consultant TIC & Cartographie Numérique
> Co-fondateur [#OSMCI](http://www.openstreetmap.ci/)I 
> [#BilletExpress](http://billetexpress.ml/) I 
> [#NzassaNetwork](http://www.nzassanetwork.net/)
> Alumni I [YALI DAKAR](http://www.yaliafriquedelouest.org/) I 
> [VIF](https://jeunesse.francophonie.org/volontariat/presentation-du-programme)
>
> Contacts : (+225) 08 096 901 - 76 21 42 84
> Mail : konanguymau...@gmail.com
> Twitter : @konan_maurel
> Skype : maurelkonan___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-bf] [Talk-CI] INVITATION MAPATHON

2019-04-10 Diskussionsfäden severin.menard via Talk-bf
Bonsoir Maurel,

Belle initiative, cependant il existe déjà depuis l'automne dernier une tâche 
créée par Arsène sur laquelle nous sommes quelques-uns à contribuer : 
http://taches.francophonelibre.org/project/276

Séverin

‐‐‐ Original Message ‐‐‐
Le mercredi 10 avril 2019 19:32, Guy Maurel Konan  a 
écrit :

> Bonsoir à tous,
>
> Des Chiffres et Des Jeunes en collaboration avec la Fondation Performances 
> Sociétales et la Communauté OpenSreetMap Côte 
> d'Ivoirehttps://web.facebook.com/hashtag/openstreetmap?source=feed_text=HASHTAG&__xts__%5B0%5D=68.ARCsITKoWUxNbekGhnC9MlZnTvoh92rGGnT0bQedUaZ0SswqczhfneGn-T6_4e07CMg7GT8c8E7SH3QyLkDzAGoatOnxhFErBnbHnTWClvfSwbA32gcB2IW4FMxx4wjdbVP3d8CY18PWQuOpfGp0hi4ywc-9W1Xu-OGSs-M505I3mmVHEyk7aYiJf7JM1pBRVkTsQEZBVtJ3J7EfL89pPbNsenpfoKcOiR6wwgzOFoVORyekNZOSFK1yRI__AdbC4S00aqWzJY3pL4bbYah_ZfoTOi_uGfnucArdclrPmHTdKY0f9bJ-h972soEXvexw5D3X1x87AbemnQ2dYfWI7WM&__tn__=%2ANK-R,
>  organisent le Samedi 13 avril au sein de l’ENSEA à l’université FHB de 
> Cocody, le Mapathon de Daloa qui a pour objectif d’actualiser la carte de la 
> ville de Daloa et effectuer une demande de cartographie des bâtiments et 
> routes résidentielles en prélude de la phase de mapping.
>
> Nous vous invitons à nous rejoindre sur la tâche : 
> https://tasks.hotosm.org/project/5910
>
> Cordialement,
>
> 
>
> [-]
>   Kouassi Guy Maurel KONAN
> [https: //]about.me/guymaurelkonan
>
> Web Entrepreneur
> Consultant Cartographie & SIG Chez [UNICEF Côte 
> d'Ivoire](https://www.unicef.org/cotedivoire/)
> Consultant TIC & Cartographie Numérique
> Co-fondateur [#OSMCI](http://www.openstreetmap.ci/)I 
> [#BilletExpress](http://billetexpress.ml/) I 
> [#NzassaNetwork](http://www.nzassanetwork.net/)
> Alumni I [YALI DAKAR](http://www.yaliafriquedelouest.org/) I 
> [VIF](https://jeunesse.francophonie.org/volontariat/presentation-du-programme)
>
> Contacts : (+225) 08 096 901 - 76 21 42 84
> Mail : konanguymau...@gmail.com
> Twitter : @konan_maurel
> Skype : maurelkonan
___
Talk-bf mailing list
Talk-bf@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bf


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

2019-04-10 Diskussionsfäden osm . sanspourriel

> Comment on tranche ?

Pour les *voies *c'est simple : s'il n'y a qu'une file sans possibilité
de se mettre sur le côté, c'est comme son nom l'indique :

service=drop_off

Si tu te mets là pour récupérer quelqu'un tu vas emm... du monde sauf si
tu arrives en retard.

Pour les *parkings*

déjà si ce sont des places de parking situées sur le bord, il suffit
d'utiliser parking:lane*

|parking:lane:|side|=|type  side est toujours |left|, |right| ou |both|.

type est |parallel|, |diagonal|, |perpendicular|, |marked|,
|no_parking|, |no_stopping| ou |fire_lane|.

Rien à préciser en plus car pour y accéder tu passes par une voie à
restriction d'accès.

Ensuite :
- kiss_n_ride = yes
- kiss_ride = yes

Ce sont des abréviations donc à éviter. Sinon pourquoi pas K ?

Reste donc service = drop_off ou kiss_and_ride = yes.

A priori si c'est un parking c'est plus du kiss_and_ride c'est à dire
qu'on peut aussi récupérer quelqu'un-e.

Si tout le monde suit mon raisonnement c'est tranché ;-)


Il y a aussi des trucs bâtards :

https://www.openstreetmap.org/way/180753263#map=18/48.44269/-4.41981

voie à une file au sud, voie à une file au nord (indiquée parking) : il
y a des plots pour créer des files de 4 voitures de long

afin que les gens restent dans leur voiture et ne bloquent pas tout.

Je pense que la voie principale devrait être laissée en service et les
parkings transformés en voies... service = kiss_and_ride (ou des micros
parkings kiss_and_ride)

Le 10/04/2019 à 15:49, Noémie Lehuby via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Donc si je résume :

Pour les voies de dépose-minute, on utilisera highway=service ou
highway=driveway, et un tag complémentaire, avec comme candidats :
- service=drop_off
- service = kiss_ride

Pour un parking dépose-minute, on utilisera amenity=parking et un tag
complémetaire avec comme candidats :
- service = drop_off
- kiss_ride = yes
- kiss_and_ride = yes
- kiss_n_ride = yes

Comment on tranche ?

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


[Talk-bf] INVITATION MAPATHON

2019-04-10 Diskussionsfäden Guy Maurel Konan
Bonsoir à tous,

Des Chiffres et Des Jeunes en collaboration avec la Fondation Performances
Sociétales et la Communauté OpenSreetMap Côte d'Ivoire
,
organisent le *Samedi 13 avril* au sein de l’ENSEA à l’université FHB de
Cocody, le Mapathon de Daloa qui a pour objectif d’actualiser la carte de
la ville de Daloa et effectuer une demande de cartographie des bâtiments et
routes résidentielles en prélude de la phase de mapping.

Nous vous invitons à nous rejoindre sur la tâche :
https://tasks.hotosm.org/project/5910

Cordialement,

**


[image: -]

Kouassi Guy Maurel KONAN
[image: https: //]about.me/guymaurelkonan


Web Entrepreneur
Consultant Cartographie & SIG Chez UNICEF Côte d'Ivoire

Consultant TIC & Cartographie Numérique
Co-fondateur #OSMCI I #BilletExpress
 I #NzassaNetwork 
Alumni I YALI DAKAR  I VIF


Contacts : (+225) 08 096 901 - 76 21 42 84
Mail : konanguymau...@gmail.com
Twitter : @konan_maurel
Skype : maurelkonan
___
Talk-bf mailing list
Talk-bf@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bf


[Talk-GB] (no subject)

2019-04-10 Diskussionsfäden Jez Nicholson
I see that Geospatial Commission's innovation project winners have been
announced
https://www.gov.uk/government/news/funding-awarded-to-innovative-data-projects
(scroll
to the bottom for the list)

OSMUK were assisting one of the bidding consortiums, but they unfortunately
didn't get through.

I can see Cyclestreets on there as well as Beeline.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk] iD influencing tagging

2019-04-10 Diskussionsfäden yves
The iD editor team has made a tremendous job so far, and it's probably 
because some people working together tightly have come up with good 
ideas, and this is good.
However, when such an idea become controversial, it would be good 
practice  to reach out openly with the wider community and other editors 
developers, and take the time to do so. But in the end, it's up to them. 
I don't see an 'Editor software rules working group' be a big success.


On another side, and when it comes to tagging (because it also comes to 
that), I do understand that somebody wanting to have things done feel 
irritated by the too few people discussing the matter at length on the 
tagging list and the wiki. However, these are  communication channels we 
have, and the people dedicated to it. For a maintainer of iD, to despise 
these channel for advice or discussion is not helping to gain trust in 
the development team, a very good way to make these channels worse, and 
everybody's frustration high.


Yves


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


Re: [Talk-ro] name= pentru drumurile comunale, de ce?

2019-04-10 Diskussionsfäden Attila Asztalos
Parerea mea strict personala este ca tag-ul "name" ar trebui sa ramana 
nefolosit la drumurile care nu au un nume mai specific decat "de la - 
spre". Informatia e prezenta in harta, se poate construi live sau 
pre-procesa daca e cazul, nu se justifica fortarea ei intr-un tag menit 
pentru denumiri explicite.


Se pare ca exista totusi cateva tag-uri care ar putea fi considerate 
oarecum inrudite, ca de ex. "destination" [1] (in doua sensuri separate 
"destination:forward" si "destination:backward"); desi pare mai degraba 
menit pentru destinatii majore (in sensul "pe aici spre Brasov"), campul 
poate contine valori multiple separate cu punct si virgula, si nu vad de 
ce prima valoare n-ar putea fi localitatea imediat urmatoare daca se 
doreste, asa cum apare de obicei si pe bornele de marcare. Un alt tag 
vag compatibil ar putea fi si "description" [2] desi e destul de clar ca 
nici acest tag nu e chiar menit scopului respectiv...


Cu stima,
  Attila

[1] - https://wiki.openstreetmap.org/wiki/Key%3Adestination
[2] - https://wiki.openstreetmap.org/wiki/Key%3Adescription

On 10-04-2019 20:03, Anatolie Golovco wrote:
Desigur ca noi stim despre regula cu copiatul de pe alte harti si mai 
ales despre regula cu google maps. Eu din 2008 editez in osm.


Cum a presupus si Vlad, pe linga a ne uita peste ce mai este vizibil 
in Mapillary, noi folosim anexele de la HG care nu sunt sub copyright.
DC191 a venit din o asemenea anexa. Tocmai am primit pe chat de la 
colegii mei screenshot cu acel document.


Daca tot am fost asa de mult blamati ca lucram in parteneriat cu 
Kaart, sa va mai zic ca avem si pe Kaart cu ochii pe noi sa nu 
incalcam cumva copyrighturi sau orice alta regula osm.


Intrebarea sa punem sau nu nume pe way este inca deschisa spre discutii.

On Wed, Apr 10, 2019 at 3:23 PM Vlad Sîngeorzan > wrote:


Cred că echipa lui Anatolie ar fi urmat a modifica toate drumurile
din România după modelul acela, nu doar DC-urile, nu este vorba de
tratament special. Puteți vedea că în zona Arad că au început a
denumi și DJ astfel.
Ideea acuma ar fi dacă suntem de acord cu schema aceasta. Din
punctul meu de vedere dacă vrem să punem localitățile prin care
trece s-ar potrivi mai degrabă folosirea unor taguri de genul
from= și to=, dar acestea sunt în prezent rezervate rutelor de
transport public.
În general, în alte țări văd că drumurile sunt marcate doar prin
ref=, fără name=, înafara Olandei și a Belgiei care se pare că au
o denumire oficială pentru orice drum de țară (probabil că există
reglementat și fiecare fermă are o adresă; nu sunt denumiri
construite precum este în cazul nostru).
Mi s-ar părea normal să dăm nume doar când avem un nume de stradă
în interiorul localitățiilor sau când vor apărea denumiri
consacrate ale drumurilor, gen Autostrada Soarelui, Centura Brașov
și sunt marcate și cunoscute sub această denumire.

Străinu, țin să te contrazic cu DC191, înțeleg că tu știi
realitatea de pe teren, dar făcând puțin research în documente
oficiale se pare că drumurile sunt altfel pe hartă decât pare.

https://drive.google.com/file/d/1Oy6guuYLb7sh2lfJOhdMP9q32dFT4CjG/view?usp=sharing
în lista drumurilor din România se poate vedea cum că DC191 e
Obedeni - Anghelești, nu știu cât de oficiale și legale sunt
documentele acestea, dar aceste documente par a fi sursa
principală inclusiv a datelor de pe OSM.
Pe harta județului de pe site-ul primăriei Giurgiu apare așa cum e
în mod actual pe OSM:

http://www.primariagiurgiu.ro/portal/giurgiu/primarie/portal.nsf/All/1961B31FC1C65987C225812A0048439B/$FILE/01.ACAD-SBL-PI.pdf
În HG 713/07.06.2006 se încadrează drumul Vadu Lat - DC 191 ca și
DC 192, deci așa cum putem vedea pe Google Maps:
http://legislatie.just.ro/Public/DetaliiDocument/72541
Iar pe site-ul firmei betacops apare că se laudă cum că ei au
construit un "Pod pe DC191 km 0+900 peste canal de descarcare la
Obedeni;"
http://www.betacops.ro/content/poduri%E2%80%93proiecte-tehnice .
Acestă descriere s-ar potrivi acestui pod:
https://www.mapillary.com/map/im/6fOySpYZNk_nPxvWBoVlgQ cred că e
acesta prin eliminare, deoarece în zonă există doar 3 poduri, unul
în Vadu Lat peste râul Neajov, altul peste Dâmbovnic, iar acesta
este singurul care pare a fi peste un canal de descărcare în zona
Odobeni.

În schimb am găsit și informații care atestă că DC191 ar fi Valu
Lat - Anghelești în presă, la inundațiile din 2014 și 2018:

https://adevarul.ro/locale/giurgiu/judetul-giurgiu-avertizare-cod-portocaliu-inundatii-drumuri-inchise-mii-hectare-teren-ape-1_5aa3f6f4df52022f756792a3/index.html

https://adevarul.ro/locale/giurgiu/15-localitati-judetul-giurgiu-afectate-inundatii-6-drumuri-inchise-circulatiei-1_548ae514448e03c0fdafdb23/index.html


Re: [OSM-talk-fr] Field papers

2019-04-10 Diskussionsfäden Cédric Frayssinet
Le 10/04/2019 à 18:15, Magalie Dartus a écrit :
> Pour info l'affichage du field paper fonctionne avec Chrome mais pas
> avec Firefox

C'est triste :(

Quant je constate cela, je reporte une issue ici :
https://webcompat.com/issues/new

Il y a une extension Firefox qui fait la majorité du boulot :
https://addons.mozilla.org/fr/firefox/addon/webcompatcom-reporter/

Cédric


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden Erik Johansson
On Wed, Apr 10, 2019 at 5:52 PM Grigory Rechistov via Talk-se
 wrote:
> 4. Konvertera etiketter, gallra datafil.

Är alla delar scripade, detta låter som ett manuellt steg?

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


Re: [OSM-talk-fr] [tech] taginfo fr > combinaisons

2019-04-10 Diskussionsfäden marc marc
Le 10.04.19 à 19:10, Marc M. a écrit :
>> page de combinaison vide
>> https://taginfo.openstreetmap.fr/tags/amenity=university#combinations
> 
> il y a eu des soucis les jours précédents.
> par exemple des stats totalement erronées.
> re-construction de la bdd taginfo en cours pour voir si cela
> résout le soucis ou pas.

reconstuction terminée.
la réponse est "Ce tableau présente uniquement les combinaisons
les plus fréquentes des tags les plus fréquents."
< 2000 objets n'est pas assez fréquent.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] autoveicoli, roulotte, camion e camper abbandonati

2019-04-10 Diskussionsfäden Volker Schmidt
Non capisco questa discussione, o mi sfugge qualcosa?
Trovo immondizie ingombranti nel bosco e discuto come mapparli in OSM?
La prima cosa che farei è una denuncia alla polizia locale. Prima lo
faccio, meglio, perché c'è più probabilità che ci siano ancora tracce degli
ex-proprietari. E poi si potrebbe anche essere roba rubata.
Ma non penso che dovrebbe essere mappato in OSM, salvo come discarica
abusiva, se è una cosa abituale, dove chiunque può portare la sua roba.

On Wed, 10 Apr 2019 at 19:07, liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu> wrote:

> Il 10/04/19 19:04, liste DOT girarsi AT posteo DOT eu ha scritto:
> > Ciao, questo è un mio vechio post dove chiedevo lumi su qualcosa di
> > simile, però l'historic mi convince poco, perchè ha senso se permane,
> > qui si tratta di abbandoni veri e propri, per cui io avevo optato per
> > abandoned:vehicle=wreck, wreck:type=crawler_excavator, proprio perchè
> > trattasi di volatilità dell'oggetto, historic per me ha senso per cose
> > "fisse" e volute, come castelli o costruzioni in genere, qui si tratta
> > di veri e propri abbandoni, direi di limitarsi al life cycle in quanto
> tale.
> >
> > Poi però la discussione non era proseguita, a parte l'intervento di
> > cascafico, e quindi non feci più nulla, ma l'escavatore è ancora lì.
> >
> >
>
> Chiedo suca ecco il link:
>
>
> http://gis.19327.n8.nabble.com/Escavatore-abbandonato-su-strada-agricola-forestale-td5908446.html
>
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk-fr] [tech] taginfo fr > combinaisons

2019-04-10 Diskussionsfäden marc marc
Bonjour,

Le 10.04.19 à 18:16, Nicolas Bétheuil a écrit :
> ce serait plutôt sur une liste d'admin que je devrais dire ça, 
> mais en fait je ne la connais pas.

t...@listes.openstreetmap.fr

> page de combinaison vide
> https://taginfo.openstreetmap.fr/tags/amenity=university#combinations

il y a eu des soucis les jours précédents.
par exemple des stats totalement erronées.
re-construction de la bdd taginfo en cours pour voir si cela
résout le soucis ou pas.

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


Re: [Talk-it] autoveicoli, roulotte, camion e camper abbandonati

2019-04-10 Diskussionsfäden liste DOT girarsi AT posteo DOT eu
Il 10/04/19 19:04, liste DOT girarsi AT posteo DOT eu ha scritto:
> Ciao, questo è un mio vechio post dove chiedevo lumi su qualcosa di
> simile, però l'historic mi convince poco, perchè ha senso se permane,
> qui si tratta di abbandoni veri e propri, per cui io avevo optato per
> abandoned:vehicle=wreck, wreck:type=crawler_excavator, proprio perchè
> trattasi di volatilità dell'oggetto, historic per me ha senso per cose
> "fisse" e volute, come castelli o costruzioni in genere, qui si tratta
> di veri e propri abbandoni, direi di limitarsi al life cycle in quanto tale.
> 
> Poi però la discussione non era proseguita, a parte l'intervento di
> cascafico, e quindi non feci più nulla, ma l'escavatore è ancora lì.
> 
> 

Chiedo suca ecco il link:

http://gis.19327.n8.nabble.com/Escavatore-abbandonato-su-strada-agricola-forestale-td5908446.html

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

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


Re: [Talk-it] autoveicoli, roulotte, camion e camper abbandonati

2019-04-10 Diskussionsfäden liste DOT girarsi AT posteo DOT eu
Ciao, questo è un mio vechio post dove chiedevo lumi su qualcosa di
simile, però l'historic mi convince poco, perchè ha senso se permane,
qui si tratta di abbandoni veri e propri, per cui io avevo optato per
abandoned:vehicle=wreck, wreck:type=crawler_excavator, proprio perchè
trattasi di volatilità dell'oggetto, historic per me ha senso per cose
"fisse" e volute, come castelli o costruzioni in genere, qui si tratta
di veri e propri abbandoni, direi di limitarsi al life cycle in quanto tale.

Poi però la discussione non era proseguita, a parte l'intervento di
cascafico, e quindi non feci più nulla, ma l'escavatore è ancora lì.


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

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


Re: [Talk-GB] OSM Wiki UK pages

2019-04-10 Diskussionsfäden Jez Nicholson
Possibly. People don't use category pages that often, but when they do it
is for a high-level overview or they are hunting for something. Better to
have fewer categories with more things in each than a deep, sparse tree.

So, Events in the United Kingdom is probably a useful category as there are
lots of them. Events in UK/Events in Brighton goes too far. Quarterly
Projects in the United Kingdom could hide away things like one was about
Post Offices.

It is very subjective. Perhaps we could formulate opinions ready to make a
plan at the AGM? I know that Harry did/does a lot of work on this.

On Wed, 10 Apr 2019 16:16 SK53,  wrote:

> A few points about the UK category with a view to making it slightly more
> usable, particularly for someone not familiar with the project.
>
>1. I think any page of the form XXX/YYY should not be in the top UK
>category: I doubt if many people are interested in Birmingham Trees or the
>Broadmarsh bus station redevelopment outside the local areas. Perhaps a
>local projects category to dump them in for now.
>2. I think all the individual quarterly project pages don't need to
>appear in the UK category either.
>3. All Open Data sources (OS, Lidar, Natural England etc) should be in
>their own sub-category
>4. OSM UK logos should be just in the OSM UK category
>5. There's no good link to pages about areas: the cities page is very
>sparse. Perhaps a category for pages based on local authorities or similar
>(i.e., there are a few which cover a traditional county where the county
>town is a separate unitary authority). At present the English Counties is
>quite a good landing page for this, but obviously doesn't cover the whole
>UK.
>
> Jerry
>
> On Wed, 10 Apr 2019 at 15:05, Jez Nicholson 
> wrote:
>
>> Hi all,
>>
>> For my sins, and for being in OSMUK, I volunteered to review the UK pages
>> on OSMWiki.
>> https://wiki.openstreetmap.org/wiki/WikiProject_United_Kingdom Here are
>> my conclusions:
>>
>> 1. It being a wiki, it takes care to not tread on other peoples' toes.. I
>> may have mildly perturbed a few people but I don't think (I hope) I caused
>> any deep resentment...I feel that UK specific pages 'belong' to us (you,
>> me, every UK mapper) and can more confidently edit them (still hesitantly)
>> than global pages.
>>
>> 2. There were many uncategorised and orphan pages. These are now all in
>> the https://wiki.openstreetmap.org/wiki/Category:United_Kingdom category
>> page. This should answer the question, "what pages are managed by the UK
>> OSMers?".
>>
>> 3. The category structures are often too deep and sub-divided to be
>> useful.
>>
>> 4. There are many pages, probably too many.
>>
>> 5. Many pages were created in the early days of OSM and now state
>> out-of-date information. This gives a bad impression to new users. Many
>> pages are simple enough to convert into past tense, or update after
>> researching. It's a living, breathing document and not a history book.
>>
>> 6. Creating a new page to share and document your personal projects can
>> be useful, e.g. I published my work in the open as
>> https://wiki.openstreetmap.org/wiki/Renewable_energy_in_the_United_Kingdom 
>> and
>> got valuable input.
>>
>> 7. There is no clear naming scheme for pages. I've used "xyz in the
>> United Kingdom" so that they show in alphabetical order but other schemes
>> are available. If pages include a '/' then this splits them into a rigid
>> single hierarchy...but what should that hierarchy be?
>>
>> 8. ...and finally... it is easy to complain about the OSM Wiki, but it is
>> ours to edit and improve. Any failings in the UK pages, at least, are ours.
>> I urge you to find a subject local to you and update it, cities are a good
>> place to start. Tread lightly to begin with and build up. Use the Talk tabs.
>>
>> Regards,
>>  Jez
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-it] appostamento di caccia su ruote

2019-04-10 Diskussionsfäden Andrea Albani
Il giorno mer 10 apr 2019 alle ore 10:47 demon_box 
ha scritto:

> ciao, per "l'angolo delle cose strane" ho un capanno di caccia fissato
> sopra
> un carretto con ruote.
>
> da ciò che intuisco, durante il periodo di caccia viene spostato dove
> meglio
> serve allo scopo e poi a periodo terminato, viene ri-spostato di qualche
> decina di metri, diciamo "parcheggiato" poco distante.
>
> come mi comporto?
>
>
Un oggetto su ruote che per sua natura può essere spostato, come confermi,
è da mappare ? A mio personale giudizio mi sembra poco georeferenziabile.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[OSM-talk-fr] taginfo fr > combinaisons

2019-04-10 Diskussionsfäden Nicolas Bétheuil
Hello les gens,

ce serait plutôt sur une liste d'admin que je devrais dire ça, mais en fait
je ne la connais pas.

en regardant, ça fait plusieurs fois que je tombe sur une page de
combinaison vide
https://taginfo.openstreetmap.fr/tags/amenity=university#combinations
ça réponds bien en 200 sur
*https://taginfo.openstreetmap.fr/api/4/tag/combinations?key=amenity=university=all=other_tag=desc=1=19=other_tag
*
mais les résultats sont vide

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


Re: [OSM-talk-fr] Field papers

2019-04-10 Diskussionsfäden Magalie Dartus
Pour info l'affichage du field paper fonctionne avec Chrome mais pas avec
Firefox

Le mer. 10 avr. 2019 à 15:15, Magalie Dartus  a
écrit :

> Bonjour,
>
> Je suis en train de créer un atelier d'initiation OSM.
> Je voudrais utiliser les field papers pour la collecte de données terrain.
> Pour cet atelier je préfère utiliser ID pour la numérisation des données
> observées et ce parce que je manque de temps pour pouvoir former à l'outil
> JOSM.
> Le problème est que quand je fais le transfert des photos des Field papers
> dans ID il n'affiche pas la photo en fond de carte. Il reconnais très bien
> l'endroit grâce au QRcode mais la photo n'est pas visible, du coup on ne
> peut pas tracer les objets.
> J'ai fais le test avec JOSM ça marche nickel...
>
> Est-ce que quelqu'un connait ce problème?
>
> Merci et bonne journée
> Magalie
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden Grigory Rechistov via Talk-se
Hej,
Nu har jag skurit Sverige i bitar :-)! Här  
https://drive.google.com/open?id=1JfAidyqIdelsRj1tjrpG-OR6IkJuHxWE (400 MB) 
finns en arkivfil med 291 GeoTIFF-filer motsvarande till samtliga kommuner. 
Kommunernas gränser hittar man här som SHP-filer:  
https://atakua.org/p/nmd/kommuner-shp.tar.bz2
Det var gjort med det här skriptet:  
https://github.com/grigory-rechistov/nmd-osm-tools/blob/master/get-kommun-raster.sh

För varje  GeoTIFF-fil behöver man göra följande steg:
1. Vektorizera (gdal_vectorize)
2. Jämna ut vektorn med GRASS-Chaiken och GRASS-Douglas-Peucker verktygen
3. Exportera till OSM-XML (genom GeoJSON som mellanformat). JOSM läser nämligen 
varken SHP eller GML som QGIS producerar.
4. Konvertera etiketter, gallra datafil.
5. Conflate nya datat med det befintliga datat, fixa kvarstående överlappande 
ytor manuellt eller med ett verktyg.
6. Få tillstånd och ladda datat upp till OSM under ett särskilt konto.
7. Ha koll genom osmose.openstreetmap.fr att inga problem dykt upp, eventuellt 
rätta dem till.

Jag är fortfarande upptagen med conflate-skriptet för det femte steget.

Vi behöver även skapa en allmän tabell någonstans för att ha koll på vilka 
delar redan har laddats upp till OSM, vad för problem uppstod, vem håller på 
att bearbeta vilka kommuner osv.


>Låter som en bra ide att bruta upp importen i mindre bitar.
>
>Det ger oss också möjlighet att förbättra algoritmen om så behövs undervägs.
>
>
>___
>Talk-se mailing list
>Talk-se@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-se


С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [OSM-talk-fr] Retour sur les places de Parking PMR

2019-04-10 Diskussionsfäden Jacques Foucry
Le mercredi 10 avr. 2019 à 04:13:51 (-0700), pyrog à écrit:
> La recherche dans OSMand de parkings avec des places PMR est possible (mais
> pas conviviale) :
> * rechercher "parking"
> * choisir "Parc de stationnement"
> * appuyez sur le bouton filtre
> * tout en bas de la liste, choisir "Accessibilité aux fauteuils roulants" et
> cocher la ou les option(s) souhaitée(s) :
> Oui, non, limitée, Accès conçu pour les fauteuils roulants
> 
> Mais il n'y a rien pour les places de parking dédiée. J'ai créé une demande
> d'amélioration :
> https://github.com/osmandapp/Osmand/issues/6805
> 
> Vous pouvez rajouter un  pour inciter les dévs à la traiter rapidement.

Ok, c'est noté, merci.

-- 
Jacques Foucry

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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden egil
On 2019-04-07 17:47, Grigory Rechistov via Talk-se wrote:
> Hej,
>
> >En särskild användare bör skapas.
> Sant, det är enligt guidelinjerna:
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account
>
> >Hur vi ska identifiera områden vet jag ej.
> > ska man identifiera områden manuellt för import, eller kan man göra
> en enda
> > import för hela landet? Någon som vet hur det går till?
>
> Min känsla är att försöka importera hela landet meddetsamma vore
> opraktiskt: jättestora filer, många svåra konflikter med befintliga
> data att lösa samtidigt osv. Länen är också för stora. Det finns 290
> kommuner; kanske en kommun i taget vore ett lagom stort ärende för att
> klara utan överdrivna ansträngningar?
Låter som en bra ide att bruta upp importen i mindre bitar.

Det ger oss också möjlighet att förbättra algoritmen om så behövs undervägs.



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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden Grigory Rechistov via Talk-se
Hej egil,
>Informationen om hur detta data tagits fram skulle jag vilja anges tydligt i 
>planen/var det nu passar bäst.

Det håller jag med, ska göras.


>Вторник,  9 апреля 2019, 23:39 +03:00 от egil :
>
>Hej Grigory
>Tusen tack för ditt utförliga svar. 
>Jag är inte längre lika skeptisk längre. Vi får lita på att dem
>  på naturvårdsverket har koll på sina infraröda bilder och AI.
>Informationen om hur detta data tagits fram skulle jag vilja
>  anges tydligt i planen/var det nu passar bäst.
>Kul att du lyckats lista ut och jobba runt gdal_sieve.py's
>konstigheter :)
>
>Mvh
>
>
>
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [OSM-talk] Dialects of English | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Yuri Astrakhan
Excellent point Rory, thx. We can already enter tag description in data
items in many English variants, e.g. Patois or Canadian or even Old English
:), and iD editor will automatically get the right one when showing tag
info. There is now a discussion on how to region-limit tags too (this is
different from "language-limiting" we have now, that needs to go away).

* a 2 min video on how to add descriptions -
https://wiki.openstreetmap.org/wiki/Data_items
* amenity=college data item https://wiki.openstreetmap.org/wiki/Item:Q4763


On Wed, Apr 10, 2019 at 5:24 AM Rory McCann  wrote:

>
> A better example might be "college", which has different meanings in
> different dialects of English, or "gallon" or "football"
>
> I don't think there is a solution this, except better localization of
> software. Or we all just switch to Esperanto or Irish or something.
>
> If you want real fun, just talk about "tabling an agenda item" 
>
> On 08/04/2019 18:32, Yuri Astrakhan wrote:
> > Martin, thanks for explanation, but my point still stands -- in tags, we
> > treat words not at their own meaning, but as IDs that represent some
> > agreed concepts.  The German wiki page has a warning about
> > "evangelical", so it is likely not all German-speaking mappers are aware
> > of the distinction, or know English well enough to know this.  The same
> > applies to highways - "highway" the word has different meaning in
> > different regions, whereas "highway" the OSM tag should have just a
> > single meaning that's clear to every mapper and every consumer.
> >
> > On Mon, Apr 8, 2019 at 3:50 AM Martin Koppenhoefer
> > mailto:dieterdre...@gmail.com>> wrote:
> >
> >
> >
> > sent from a phone
> >
> >  > On 7. Apr 2019, at 22:23, Yuri Astrakhan  > > wrote:
> >  >
> >  > A good example is "denomination=evangelical" -- German speakers
> > should not use it for "evangelisch" which stands for
> > denomination=protestant. The word may be the same, but we treat
> > "evangelical" as an ID for a specific meaning, rather than reflect
> > local language customs.
> >
> >
> > actually “evangelical” translates in German to “evangelikal”, which
> > doesn’t seem to be very confusing. Someone thinking it means
> > “evangelisch” is likely mapping in a domain s/he isn’t acquainted
> with.
> >
> > Cheers, Martin
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-legal-talk] OSM for training ML machines

2019-04-10 Diskussionsfäden Tom Lee via legal-talk
I'll defer to others on the finer points of how downstream or intermediate
ML products fit into the licensing picture, but this did catch my eye:

> If you need an example:  Take a translator for geographic names trained
> using OSM data.  This translator in practical use will spit out names
> or name components identical to those from the OSM database (if it does
> not it'd be pretty useless).  These names - in sufficient volume -
> evidently form a derivative database IMO - even if they are not the
> result of a literal copy but result from 'knowledge' encoded in a
> neural network.

I have sometimes sene similar arguments about intellectual property brought
up in engineering-focused conversations, which propose elaborate technical
mechanisms by which data might be transformed, then recreated, and in the
process its intellectual property rights somehow purged. There are already
several community guidelines explaining why this isn't acceptable. Beyond
that, my own sense is that this is at odds with how the legal system
approaches these questions (and confusion about what "transformative use"
means). If a party has custody of proprietary data, feeds it through a
black box that a judge and jury don't really understand, and the original
data comes out the other side--well, you can see why it's a hard argument
to win.

I think the risk of recreating OSM data via ML trickery is pretty low: it's
an elaborate approach that offer dubious legal advantages. If the question
is whether OSM could claim rights over a fictional but plausible map-like
output from an OSM-trained ML model, I'd say the question is more open. But
I suspect this is a less worrisome scenario for most.

On Wed, Apr 10, 2019 at 10:12 AM Christoph Hormann 
wrote:

> On Wednesday 10 April 2019, althio wrote:
> >
> > You may have skipped parts of my message, so excuse me if I repeat a
> > few lines. You quoted only two sentences and I slightly wonder if you
> > genuinely read the whole.
>
> I am sorry if i left the impression that i was specifically criticizing
> your ideas - i was more referring to the general course of the
> discussion towards a rather mechanical exegesis of the ODbL based on a
> simplistic view of how algorithms work as a mechanical process
> converting well defined input data into well defined output data.
>
> > [...]
> > I don't think my original message can be read as "sweepingly declare
> > any output of algorithms as having no copyright connection".
>
> I did not mean to imply that - but since your line of reasoning only
> covers this case it is to be expected that people assume this is the
> only relevant case.
>
> > [...]
> >
> > My final two cents:
> > Take the Geocoding guideline, replace "Geocoding" by "Machine
> > Learning" and this is, in my humble opinion, an acceptable first
> > draft for discussion.
>
> But as far as i understand you, you up-front want to declare
> the "database" behind the Machine Learning, i.e. the adaptive part of
> the algorithms that gets modified through training, to be a produced
> work and therefore not subject to share-alike.
>
> If not i don't see the practical usefulness in applying the geocoding
> guideline to this in analogy because while for geocoding the individual
> result is a frequent practical use case Machine Learning and similar
> algorithms are mostly used to produce bulk results which are usually
> substantial in terms of database law.
>
> As far as the Horizontal Layers guideline and the concept of produced
> works in general is concerned - the only consistent view of these
> concepts is IMO to consider them to be limited exclusively to cases
> when you are talking about things produced for and used only for direct
> human consumption.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] OSM for training ML machines

2019-04-10 Diskussionsfäden Christoph Hormann
On Wednesday 10 April 2019, althio wrote:
>
> You may have skipped parts of my message, so excuse me if I repeat a
> few lines. You quoted only two sentences and I slightly wonder if you
> genuinely read the whole.

I am sorry if i left the impression that i was specifically criticizing
your ideas - i was more referring to the general course of the
discussion towards a rather mechanical exegesis of the ODbL based on a
simplistic view of how algorithms work as a mechanical process
converting well defined input data into well defined output data.

> [...]
> I don't think my original message can be read as "sweepingly declare
> any output of algorithms as having no copyright connection".

I did not mean to imply that - but since your line of reasoning only
covers this case it is to be expected that people assume this is the
only relevant case.

> [...]
>
> My final two cents:
> Take the Geocoding guideline, replace "Geocoding" by "Machine
> Learning" and this is, in my humble opinion, an acceptable first
> draft for discussion.

But as far as i understand you, you up-front want to declare
the "database" behind the Machine Learning, i.e. the adaptive part of
the algorithms that gets modified through training, to be a produced
work and therefore not subject to share-alike.

If not i don't see the practical usefulness in applying the geocoding
guideline to this in analogy because while for geocoding the individual
result is a frequent practical use case Machine Learning and similar
algorithms are mostly used to produce bulk results which are usually
substantial in terms of database law.

As far as the Horizontal Layers guideline and the concept of produced
works in general is concerned - the only consistent view of these
concepts is IMO to consider them to be limited exclusively to cases
when you are talking about things produced for and used only for direct
human consumption.

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

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


[Talk-GB] OSM Wiki UK pages

2019-04-10 Diskussionsfäden Jez Nicholson
Hi all,

For my sins, and for being in OSMUK, I volunteered to review the UK pages
on OSMWiki. https://wiki.openstreetmap.org/wiki/WikiProject_United_Kingdom Here
are my conclusions:

1. It being a wiki, it takes care to not tread on other peoples' toes.. I
may have mildly perturbed a few people but I don't think (I hope) I caused
any deep resentment...I feel that UK specific pages 'belong' to us (you,
me, every UK mapper) and can more confidently edit them (still hesitantly)
than global pages.

2. There were many uncategorised and orphan pages. These are now all in the
https://wiki.openstreetmap.org/wiki/Category:United_Kingdom category page.
This should answer the question, "what pages are managed by the UK OSMers?".

3. The category structures are often too deep and sub-divided to be useful.

4. There are many pages, probably too many.

5. Many pages were created in the early days of OSM and now state
out-of-date information. This gives a bad impression to new users. Many
pages are simple enough to convert into past tense, or update after
researching. It's a living, breathing document and not a history book.

6. Creating a new page to share and document your personal projects can be
useful, e.g. I published my work in the open as
https://wiki.openstreetmap.org/wiki/Renewable_energy_in_the_United_Kingdom and
got valuable input.

7. There is no clear naming scheme for pages. I've used "xyz in the United
Kingdom" so that they show in alphabetical order but other schemes are
available. If pages include a '/' then this splits them into a rigid single
hierarchy...but what should that hierarchy be?

8. ...and finally... it is easy to complain about the OSM Wiki, but it is
ours to edit and improve. Any failings in the UK pages, at least, are ours.
I urge you to find a subject local to you and update it, cities are a good
place to start. Tread lightly to begin with and build up. Use the Talk tabs.

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


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

2019-04-10 Diskussionsfäden Noémie Lehuby via Talk-fr

Donc si je résume :

Pour les voies de dépose-minute, on utilisera highway=service ou 
highway=driveway, et un tag complémentaire, avec comme candidats :

- service=drop_off
- service = kiss_ride

Pour un parking dépose-minute, on utilisera amenity=parking et un tag 
complémetaire avec comme candidats :

- service = drop_off
- kiss_ride = yes
- kiss_and_ride = yes
- kiss_n_ride = yes

Comment on tranche ?


Le 05/04/2019 à 14:03, marc marc a écrit :

c'est le beau fou
cela montre qu'on aurait du remonter cela sur tagging la fois
précédente pour essayer d'avoir un qlq chose harmonisé :-)

il semble n'y avoir que 2 tag documenté :
maxstay=load-unload : il a l'avantage de pouvoir couvrir
2 cas dans une recherche : bande de dépose minute et emplacement
style parking.

parking:lane:both=no_parking convient aussi pour une bande de dépose minute

Pour une dépose le long d'une voie de service, parking:lane:=* +
parking:condition:=kiss_and_ride ?

après c'est clair que cela mériterait :
- une harmonisation : drop_off <> kiss_ride et and <> _n_ <> &
- documenter la solution "finale" sur le wiki
- voir pour une valeur de service=*
pour ma part j'aurais été tenté par service=driveway
vu que c'est la voie qui mène à la gare ou l'aéroport

Le 05.04.19 à 12:01, althio a écrit :

Je reste sur mon candidat :
highway=service + service=drop_off
+ fee... + maxstay...

cf: https://lists.openstreetmap.org/pipermail/talk-fr/2018-January/087452.html

-- althio

On Fri, 5 Apr 2019 at 11:34, Noémie Lehuby via Talk-fr
 wrote:

Hello,

Je n'ai rien trouvé sur le sujet dans le wiki : comment cartographier un 
dépose-minute, d'une gare ou d'un aéroport par exemple ?

Je dirais
si c'est un parking : amenity=parking + kiss_ride = yes
parce que dépose minute se dit "Kiss & Ride" en anglais, et en miroir de 
park_ride qu'on utilise pour les parking relais.
Il y a quelques très rares occurrences de kiss_ride = * et de 
capacity:kiss_and_ride dans OSM.

si c'est une voie de circulation (ce qui est à mon avis le cas le plus 
fréquent) :
highway=service + service=kiss_ride ?

--
nlehuby

___
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


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


Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-10 Diskussionsfäden Yves P.

> Je l'utilise plutôt que water_point surtout pour le rappel de la forme des 
> poteaux incendie.

> Les photos et affichent qui illustrent les pages du wiki pour water_point 
> montrent des installations avec des robinets domestiques, là où les bornes de 
> puisage ont, à la couleur près, la forme des poteaux incendie.
Pas de photo dans la page anglaise et française, juste le panneau.
À la description, « [un] lieux où de l'eau potable est disponible en grande 
quantité pour remplir des réservoirs. » ça colle pour une borne de puisage.

> J'ai donc gardé une partie de la valeur (hydrant) et changé la clé pour 
> amenity, vu que ces installations ne sont pas des dispositifs de secours. 
> Mais clairement je n'ai pas avant de recourir à ce tag demandé d'avis sur 
> Tagging ou ici, donc suggestions bienvenues pour faire évoluer ou converger 
> avec d'autres pratiques, bien sûr.
J’ai des photos de bornes de puisages (d’ancien poteaux incendie « réformés », 
de vraies bornes avec un compteur) à mettre sur Wikimedia Commons.
Ça peut servir pour discuter sur la liste Tagging…

Je viens de voir passer le message de Marc :
> amenity=water_point + design=pillar ?

Pour moi, la caractéristique principale n’est pas tellement la forme, mais 
l’usage réservé aux services de la ville. Il n’y a pas de robinet, mais (en 
France) un raccord Guillemin ou DSP.

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


[OSM-talk-fr] Field papers

2019-04-10 Diskussionsfäden Magalie Dartus
Bonjour,

Je suis en train de créer un atelier d'initiation OSM.
Je voudrais utiliser les field papers pour la collecte de données terrain.
Pour cet atelier je préfère utiliser ID pour la numérisation des données
observées et ce parce que je manque de temps pour pouvoir former à l'outil
JOSM.
Le problème est que quand je fais le transfert des photos des Field papers
dans ID il n'affiche pas la photo en fond de carte. Il reconnais très bien
l'endroit grâce au QRcode mais la photo n'est pas visible, du coup on ne
peut pas tracer les objets.
J'ai fais le test avec JOSM ça marche nickel...

Est-ce que quelqu'un connait ce problème?

Merci et bonne journée
Magalie
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] domanda banale - denominazione palazzo

2019-04-10 Diskussionsfäden scratera
...non mi piace ...
http://www.strutture.provincia.tn.it/Dettaglio_Strutture.aspx?cod_s=D335=3
...qua l'edificio si chiama appunto Palazzo istruzione quindi questo è il
nome
...poi al limite puoi mettere operator=Provincia autonoma di trento al cui
interno poi ci sono vari uffici e se vuoi andare sullo specifico esiste la
mappatura indoor 
https://wiki.openstreetmap.org/wiki/Key:indoor
...eccoti un esempio 
https://openlevelup.net/?l=-1#19/46.06703/11.14989



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

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


Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-10 Diskussionsfäden marc marc
Le 10.04.19 à 14:57, Vincent de Château-Thierry a écrit :
> forme des poteaux incendie.

amenity=water_point + design=pillar ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-legal-talk] OSM for training ML machines

2019-04-10 Diskussionsfäden althio
Christoph,

You may have skipped parts of my message, so excuse me if I repeat a few lines.
You quoted only two sentences and I slightly wonder if you genuinely
read the whole.
If I misread your critique, please help me and maybe quote the exact
and detailed part where you disagree, not the introductive summary
only.


> > A typical "learned" model, based on a ML algorithm and a substantial
> > extract of OSM data:
> > That seems like a Produced Work to me.
>
> Maybe i have not been clear enough with my comment - approaching this
> matter based on gut feeling and wishful thinking (seems like...)
> without considering the practical effects is a very bad idea.

I stand by my initial assessment:
In a **typical use case** for applying ML algorithms (not just
replicate the training data in bulk), I consider Produced Work as the
best fit.


> You can design 'learning' algorithms to essentially replicate the
> training data so to just sweepingly declare any output of algorithms as
> having no copyright connection to training data is a recipe for desaster [...]

If you replicate the original OSM data, in a substantial amount, this
does not qualify any more.
This is underlined in my first message under:
"licence for the results (outputs): **provided there are an
insubstantial extract or contain no OSM data** [...]"
and
"If the results (outputs) are used to create a new database that
contains the whole or a substantial part of the contents of the OSM
database, this new database would be considered a Derivative Database
and would trigger share-alike obligations under section 4.4.b of the
ODbL. [shameless plug of Geocoding guideline]"

I don't think my original message can be read as "sweepingly declare
any output of algorithms as having no copyright connection".
I don't think we can have a fruitful discussion if you selectively
read messages or redact some important parts.


> is a recipe for desaster (if you subscribe to the spirit of the OdbL) or a 
> recipe for
> success (if your goal is to abolish share-alike and attribution through
> the back door - which of course many corporate OSM data users would
> find highly desirable).

No other comment on this section.


> as also said concentrating exclusively on the produced work vs. derivative 
> database is not really helpful,
> [snip]
> that does not mean that the output of this algorithm, [...], is not a 
> derivative database.

I consider your interpretation very similar to mine.
I fail to see what you are criticizing.


> If you need an example:  Take a translator for geographic names [...].
> These names - in sufficient volume - evidently form a derivative database IMO

I agree with you.
Yet I don't see why you provide this example, or where you disagree with me.

For the record: I find the geocoding example more interesting since it
already has practical applications, it provides a parallel for the
data process of ML and it comes with a Community-LegalWG guideline.


> When considering this subject, maybe think of it less as a question of
> copying data, think of it more as a process of mimicry.

My final two cents:
Take the Geocoding guideline, replace "Geocoding" by "Machine
Learning" and this is, in my humble opinion, an acceptable first draft
for discussion.
Is this draft suitable, or is there any parts that do not hold against
reality or practical effects?
Is there a need to take into account the type of input and output
data, and whether the output data is suitable for inclusion in a
geographical database such as OSM?
See also bits of the Horizontal Layers guideline, such as "If you
improve data used in the OpenStreetMap layer, such as additions or
factual corrections, then you need to share those improvements." Would
they apply? How it could be extended for non-map products?

-- althio

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


Re: [OSM-talk-fr] massifs arbustifs et/ou de fleurs => Village green

2019-04-10 Diskussionsfäden Cyrille37 OSM

Le 10/04/2019 à 13:47, Eric Brosselin - Osm a écrit :

@Cyrille

C'est cet usage détourné de sa vocation initiale qui est discuté.

Personnellement je n'utiliserais pas ce tag pour cartographier les 
petits bouts de verdure urbains.


En plus traditionnellement pas de village green, coudert, ou rietz en 
Touraine !


Merci Éric pour ces explications. Ça me fait donc un "gros" paquets de 
corrections à faire, en Touraine.


Cyrille37.



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


Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-10 Diskussionsfäden Vincent de Château-Thierry

> De: "Yves P." 
> 
> Je suis plus perplexe avec amenity=hydrant : il n’y en a que 64 dans
> tag info : https://taginfo.openstreetmap.org/tags/amenity=hydrant
> 
> amenity=water_point me parait mieux : 19 442 noeuds dans tag info :
> https://taginfo.openstreetmap.org/tags/amenity=water_point
> Comme l’usage d’une borne de puisage semble être réservée aux
> services communaux ou aux paysans , je mettrais en plus
> access=designated ( ou au pire access=no).

Oui amenity=hydrant est discutable. Je l'utilise plutôt que water_point surtout 
pour le rappel de la forme des poteaux incendie. Les photos et affichent qui 
illustrent les pages du wiki pour water_point montrent des installations avec 
des robinets domestiques, là où les bornes de puisage ont, à la couleur près, 
la forme des poteaux incendie. J'ai donc gardé une partie de la valeur 
(hydrant) et changé la clé pour amenity, vu que ces installations ne sont pas 
des dispositifs de secours. Mais clairement je n'ai pas avant de recourir à ce 
tag demandé d'avis sur Tagging ou ici, donc suggestions bienvenues pour faire 
évoluer ou converger avec d'autres pratiques, bien sûr.

vincent

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


Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-10 Diskussionsfäden Yves P.

> Ce que je taggue en amenity=hydrant ce sont des bornes qui ont la forme de 
> poteaux incendie, mais qui sont "nativement" des bornes de puisage.
> Ca se trouve dans le commerce : 
> https://www.bayard.fr/nc/produits/nos-produits/produit/page/borne-de-puisage-incongelable-serie-d2-10.html
>  
> 
>  sans idée de déclassement de poteau incendie. Je ne laisse pas de tag 
> emergency sur ces bornes, juste une note pour éviter un retagguage au profit 
> de emergency=*, qui serait erroné.
Que tu ne mettes pas d’attribut emergency=fire_hydrant (ou 
disused:emergency=fire_hydrant) me va parfaitement 

Je suis plus perplexe avec amenity=hydrant : il n’y en a que 64 dans tag info : 
https://taginfo.openstreetmap.org/tags/amenity=hydrant 


amenity=water_point me parait mieux : 19 442 noeuds dans tag info : 
https://taginfo.openstreetmap.org/tags/amenity=water_point 

Comme l’usage d’une borne de puisage semble être réservée aux services 
communaux ou aux paysans , je mettrais en plus access=designated (ou au pire 
access=no).

—
Yves

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


Re: [OSM-talk] Dialects of English | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Volker Schmidt
I don't think there is a solution this, except better localization of
> software. Or we all just switch to Esperanto or Irish or something.
>

Esperanto is a solution, and we use it in OSM, only that OSM's Esperanto is
British English

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


Re: [Talk-ro] name= pentru drumurile comunale, de ce?

2019-04-10 Diskussionsfäden Vlad Sîngeorzan
Cred că echipa lui Anatolie ar fi urmat a modifica toate drumurile din
România după modelul acela, nu doar DC-urile, nu este vorba de tratament
special. Puteți vedea că în zona Arad că au început a denumi și DJ astfel.
Ideea acuma ar fi dacă suntem de acord cu schema aceasta. Din punctul meu
de vedere dacă vrem să punem localitățile prin care trece s-ar potrivi mai
degrabă folosirea unor taguri de genul from= și to=, dar acestea sunt în
prezent rezervate rutelor de transport public.
În general, în alte țări văd că drumurile sunt marcate doar prin ref=, fără
name=, înafara Olandei și a Belgiei care se pare că au o denumire oficială
pentru orice drum de țară (probabil că există reglementat și fiecare fermă
are o adresă; nu sunt denumiri construite precum este în cazul nostru).
Mi s-ar părea normal să dăm nume doar când avem un nume de stradă în
interiorul localitățiilor sau când vor apărea denumiri consacrate ale
drumurilor, gen Autostrada Soarelui, Centura Brașov și sunt marcate și
cunoscute sub această denumire.

Străinu, țin să te contrazic cu DC191, înțeleg că tu știi realitatea de pe
teren, dar făcând puțin research în documente oficiale se pare că drumurile
sunt altfel pe hartă decât pare.
https://drive.google.com/file/d/1Oy6guuYLb7sh2lfJOhdMP9q32dFT4CjG/view?usp=sharing
în lista drumurilor din România se poate vedea cum că DC191 e Obedeni -
Anghelești, nu știu cât de oficiale și legale sunt documentele acestea, dar
aceste documente par a fi sursa principală inclusiv a datelor de pe OSM.
Pe harta județului de pe site-ul primăriei Giurgiu apare așa cum e în mod
actual pe OSM:
http://www.primariagiurgiu.ro/portal/giurgiu/primarie/portal.nsf/All/1961B31FC1C65987C225812A0048439B/$FILE/01.ACAD-SBL-PI.pdf
În HG 713/07.06.2006 se încadrează drumul Vadu Lat - DC 191 ca și DC 192,
deci așa cum putem vedea pe Google Maps:
http://legislatie.just.ro/Public/DetaliiDocument/72541
Iar pe site-ul firmei betacops apare că se laudă cum că ei au construit un
"Pod pe DC191 km 0+900 peste canal de descarcare la Obedeni;"
http://www.betacops.ro/content/poduri%E2%80%93proiecte-tehnice . Acestă
descriere s-ar potrivi acestui pod:
https://www.mapillary.com/map/im/6fOySpYZNk_nPxvWBoVlgQ cred că e acesta
prin eliminare, deoarece în zonă există doar 3 poduri, unul în Vadu Lat
peste râul Neajov, altul peste Dâmbovnic, iar acesta este singurul care
pare a fi peste un canal de descărcare în zona Odobeni.

În schimb am găsit și informații care atestă că DC191 ar fi Valu Lat -
Anghelești în presă, la inundațiile din 2014 și 2018:
https://adevarul.ro/locale/giurgiu/judetul-giurgiu-avertizare-cod-portocaliu-inundatii-drumuri-inchise-mii-hectare-teren-ape-1_5aa3f6f4df52022f756792a3/index.html
https://adevarul.ro/locale/giurgiu/15-localitati-judetul-giurgiu-afectate-inundatii-6-drumuri-inchise-circulatiei-1_548ae514448e03c0fdafdb23/index.html
https://www.mediafax.ro/social/inundatii-in-tara-treisprezece-localitati-din-giurgiu-afectate-cursuri-suspendate-si-drumuri-inchise-in-teleorman-13714842
https://www.romaniatv.net/peste-30-de-localitati-din-zece-judete-afectate-de-inundatii_408117.html

Aș spune că datele nu par a fi copiate de pe Google Maps ci făcute pe
documentelor oficiale din România.

În mie., 10 apr. 2019 la 11:40, Strainu  a scris:

> Anatolie,
>
> OSM nu este și nu ar trebui făcut doar pentru navigație. La fel ca la DN,
> lista drumurilor județene [1] identifica drumurile printr-un număr și
> menționează cele mai importante localități prin care trece. Nu văd de ce nu
> s-ar aplica aceleași reguli și la DC.
>
> Și mai e o chestie: ca să aibă sens pe teren, harta trebuie să semene cu
> indicatoarele și bornele. Pe DC nu prea am văzut indicatoare, dar borne mai
> sunt, în special pe cele refăcute cu fonduri europene, iar bornele nu
> indica întotdeauna capătul drumului, ci doar următorul sat și numărul.
>
> Nu mai puțin important, datele voastre au și greșeli foarte foarte
> suspecte,  vezi de exemplu https://www.openstreetmap.org/way/40699328
> Drumul ăla e Vadu Lat-Anghelești, dar cel mai problematic e că apare
> Obedeni-Anghelesti doar la google maps și site-uri derivate. Sper că știți
> și respectați faptul că nu poți importa date de la Google Maps.
>
> Cred că în interesul corectitudinii ar fi bine să faceți revert și să mai
> filtrati datele, timp în care s-ar putea ajunge, eventual, la decizia pe
> care o dorești privitoare la nume. E mai bine și pentru voi ca firmă și
> pentru osm ca munca voastră să fie deasupra oricărei bănuieli.
>
> Cu prietenie,
> Strainu
>
> [1]
> https://www.scribd.com/document/365493384/Lista-Drumurilor-Judetene-Din-Romania
>
> Pe luni, 8 aprilie 2019, Anatolie Golovco  a
> scris:
>
>> Buna
>>
>> Pentru inceput as vrea sa fac citeva concretizari:
>>
>> * Editarile nu sunt facute de un bot sau orice alt mod automatizat de
>> interventie. Intradevar sunt multe editari, dar asta datoreaza faptului ca
>> lucreaza o echipa de oameni full time.
>> * @Razvan Eu am validat cu echipa si ei nu obisnuesc 

Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-10 Diskussionsfäden Vincent de Château-Thierry
Bonjour,

> De: "pyrog" 
> 
> > Du coup le conclusion de tout ça pour les vertes c'est qu'on met
> amenity=hydrant, mais est-ce qu'on enlève le emergency=fire_hydrant
> ou pas ?
> 
> Enlever *emergency=fire_hydrant* n'est pas forcément une bonne idée
> si il s'agit d'un poteau incendie qui a été déclassé (pas de débit
> suffisant pour la lutte incendie), car il peut-être répertorié par le SDIS 
> local.
> 
> En théorie, il aura été repeint en vert pour signaler qu'il n'est
> plus utilisable par les pompiers, mais ça n'est pas toujours le cas.

Ce que je taggue en amenity=hydrant ce sont des bornes qui ont la forme de 
poteaux incendie, mais qui sont "nativement" des bornes de puisage. Ca se 
trouve dans le commerce : 
https://www.bayard.fr/nc/produits/nos-produits/produit/page/borne-de-puisage-incongelable-serie-d2-10.html
 sans idée de déclassement de poteau incendie. Je ne laisse pas de tag 
emergency sur ces bornes, juste une note pour éviter un retagguage au profit de 
emergency=*, qui serait erroné.
Exemple ici : https://www.openstreetmap.org/node/4029438650

vincent

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


Re: [Talk-pt] Toponimia de Cascais - Abuxarda ou Abucharda ?

2019-04-10 Diskussionsfäden Marcos Oliveira
Partilho a opinião do FulanoHermínio. 



De: FulanoHerminio
Enviado: 10 de abril de 2019 13:15
Para: talk-pt@openstreetmap.org
Assunto: Re: [Talk-pt] Toponimia de Cascais - Abuxarda ou Abucharda ?

Boas!

Porque não referenciar a designação antiga com old_name=Abucharda? Assim fiquem 
os dois registados na BD.

https://wiki.openstreetmap.org/wiki/Pt:Key:name

FulanoHerminio


Am 10.04.19 um 12:18 schrieb Topo Lusitania Lusitania via Talk-pt:
Caros

Recentemente foi apontado por um anónimo que no OSM a grafia da dita localidade 
estava incorrecta.
Contactei o ultimo mapeador da zona sobre a alteração que tinha efectuado 
(Rúdisicyon) e eis a sua resposta: 

Quote
Olá,
Quanto aos nomes das localidades, baseei-me no que é dito em Toponímia do 
Concelho de Cascais, de J. Diogo Correia 
(https://biblioteca.cascais.pt/bibliotecadigital/27306/27306_item1/P15.html). 
Aí está explicada a origem. Para mais, existe uma placa toponímica à entrada da 
localidade, com esta mesma grafia, que fotografei quando lá passei 
(https://commons.wikimedia.org/wiki/File:Abucharda,_entrada_da_localidade._04-18.jpg).
Unquote

A esta mensagem eu respondi o seguinte:
Olá Isso cria um problema na base de dados, pois nas buscas serão feitas com a 
grafia actual, que está nas placas toponímicas modernas… O livro que indicas 
refere o uso das diversas variantes, apesar de as apontar como incorrectas A 
própria CM de Cascais usa actualmente apenas a grafia Abuxarda. Este seria um 
tema interessante para a Talk-pt Acho que aqui se aplica a regra de mapear “o 
que está no terreno” Cumprimentos TL

O que pensam os colaboradores OSM ? Ou será que esta lista está mesmo morta, 
como é dito no grupo OSMPortugal do Telegram ?
Cumprimentos
TopoLusitania





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


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


Re: [Talk-pt] Toponimia de Cascais - Abuxarda ou Abucharda ?

2019-04-10 Diskussionsfäden FulanoHerminio

Boas!

Porque não referenciar a designação antiga com old_name=Abucharda? Assim 
fiquem os dois registados na BD.


https://wiki.openstreetmap.org/wiki/Pt:Key:name

FulanoHerminio


Am 10.04.19 um 12:18 schrieb Topo Lusitania Lusitania via Talk-pt:

Caros

Recentemente foi apontado por um anónimo que no OSM a grafia da dita 
localidade estava incorrecta.
Contactei o ultimo mapeador da zona sobre a alteração que tinha 
efectuado (Rúdisicyon) e eis a sua resposta:


Quote
Olá,
Quanto aos nomes das localidades, baseei-me no que é dito em Toponímia 
do Concelho de Cascais, de J. Diogo Correia 
(https://biblioteca.cascais.pt/bibliotecadigital/27306/27306_item1/P15.html). 
Aí está explicada a origem. Para mais, existe uma placa toponímica à 
entrada da localidade, com esta mesma grafia, que fotografei quando lá 
passei 
(https://commons.wikimedia.org/wiki/File:Abucharda,_entrada_da_localidade._04-18.jpg).

Unquote

A esta mensagem eu respondi o seguinte:
Olá Isso cria um problema na base de dados, pois nas buscas serão 
feitas com a grafia actual, que está nas placas toponímicas modernas… 
O livro que indicas refere o uso das diversas variantes, apesar de as 
apontar como incorrectas A própria CM de Cascais usa actualmente 
apenas a grafia Abuxarda. Este seria um tema interessante para a 
Talk-pt Acho que aqui se aplica a regra de mapear “o que está no 
terreno” Cumprimentos TL


O que pensam os colaboradores OSM ? Ou será que esta lista está mesmo 
morta, como é dito no grupo OSMPortugal do Telegram ?

Cumprimentos
TopoLusitania




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



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


Re: [OSM-talk-fr] massifs arbustifs et/ou de fleurs => Village green

2019-04-10 Diskussionsfäden Eric Brosselin - Osm

Bonjour,
/
/
Quelques précisions.

/Le 07/04/2019 à 21:57, marc marc a écrit ://
/
/landuse=village_green est en effet une mauvaise idée. le tag décrit 
plusieurs choses différente : - le sens uk initial est la place du 
village qui semble typiquement être avec un bout de verdure mais pas 
toujours (parfois c'est un parc avec un grand lac)/


Ce n'est pas tout à fait ça.
Originellement un « village green » est un pré communal au centre d'un 
village avec un ou plusieurs points d'eau (pour le bétail).
En Grande-Bretagne le terme « village green » a parfois été appliqué (et 
l'est toujours semble t-il) à d'autres lieux (lacs, plage, et même 
kiosque à musique !)
Ceci car les « Commons Acts » qui régissent les « village green » 
permettent de les protéger de toute transformation abusive.
Donc certains essaient de faire reconnaître des choses qui ne sont pas 
originellement des "green" (ex kiosque à musique) comme tels afin de 
bénéficier

de cette législation favorable.
Voilà l'explication.

Source article Wikipédia  >>> 
https://en.wikipedia.org/wiki/Village_green#cite_note-3


/c'est donc un mélange de leisure et operator:type voir de access=* - 
par extension certains l'ont utilisé hors uk pour dire que c'est un 
coin de verdure ou que c'est un espace public ou un mélange./


Non il n' y a pas d'extension à d'autres pays.
Le tag « village green » a été (et est toujours) utilisé en dehors du 
Royaume-Uni _avec raison_ puisque ce type de lieu existe dans de 
nombreux pays !


Comme aux USA (village green)[très rare], en Hollande (brink), en 
Allemagne (anger), au Danemark (forte), en Pologne (nawsie), en 
République tchèque (navès),
en Roumanie (notamment en Bucovine et dans les villages saxons de 
Transylvanie), en Belgique, ...
En France aussi dans certaines régions (Massif central, Limousin, Midi, 
Nord, Artois...)  sous le nom de "coudert" ou"couderc" (pays d'oc) et 
"rietz" dans le nord.


Dans tous ces pays la définition est la même que pour le « village green 
» britannique.
Il s'agit d'une pâture commune qui possède un ou plusieurs point d'eau. 
Elle peut être bordée d'arbres (qui servaient de fourrage).
Elle est souvent située au centre d'un village ou à la croisée de 
chemins, routes.
Elle comprend parfois certains "équipements communs" tels que : four à 
pain, lavoir, ...


Du fait des changements de pratiques agricoles et de l'évolution 
urbaine, de nombreux espaces de ce type ont disparu ou ont été transformés.



En France (et ailleurs) ce tag  a donc été détourné de sa vocation 
originelle (qui est de cartographier ce pré communal) pour cartographier 
les petits "espaces verts" urbains (hors squares et parcs)
Voir la discussion ici >>> 
https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dvillage_green et 
sur la liste Tagging


Il y a actuellement plus de 6900 polygones cartographiés comme «village 
green»  en France  donc quelques milliers en trop si on reste sur la 
définition de base !
Pour information en 2005 la Open Space Society 
comptait (seulement) 
3650 "greens" enregistrés en Angleterre.


Dans la page anglaise du wiki il est dit que ce tag est utilisé, par 
consensus, en Espagne pour cartographier les/"paseos"/ qui si elles 
n'ont pas le même aspect que les "green" anglais remplissent la même 
fonction d'espace commun.


En France  ce tag pourrait retrouver un sens s'il n'était utilisé _que_ 
pour cartographier (en milieu rural) ce genre d'espace central commun 
(place du village enherbée)
Et ceci pas seulement dans les régions où les villages possèdent 
traditionnellement un couderc, un rietz.


/pour un parterre de fleur, landuse=flowerbed me semble une mauvaise 
idée car ce n'est pas une utilisation du terrain mais sa couverture 
donc landcover=flowerbed pour les zones d'arbuste landcover=scrub Le 
07.04.19 à 13:38, Stéphane Péneau a écrit : /
/Si je lis le wiki, ça me semble une mauvaise idée : 
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvillage_green /
/Bonjour Je les tague comme "espace vert" => landuse=village_green , 
les végétaux et autres décorations pouvant changer selon les envies 
des jardiniers de "La ville". Je l'utilise généralement pour ce qui 
est entretenu par "La ville". Cyrille37. /

//

@Cyrille

C'est cet usage détourné de sa vocation initiale qui est discuté.

Personnellement je n'utiliserais pas ce tag pour cartographier les 
petits bouts de verdure urbains.


En plus traditionnellement pas de village green, coudert, ou rietz en 
Touraine !


Éric


Je vais améliorer le wiki qui laisse à désirer.

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


Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-10 Diskussionsfäden pyrog
> Du coup le conclusion de tout ça pour les vertes c'est qu'on met
amenity=hydrant, mais est-ce qu'on enlève le emergency=fire_hydrant ou pas ?

Enlever *emergency=fire_hydrant* n'est pas forcément une bonne idée si il
s'agit d'un poteau incendie qui a été déclassé (pas de débit suffisant pour
la lutte incendie), car il peut-être répertorié par le SDIS local.

En théorie, il aura été repeint en vert pour signaler qu'il n'est plus
utilisable par les pompiers, mais ça n'est pas toujours le cas.

Sur la carte osmhydrant, ces PEI sont "barrés" et il n'y a pas de cercle
rouge tracé pour indiquer leur rayon d'action.
L'attribut utilisé est *disused:emergency=fire_hydrant* avec éventuellement
*color=green* si le poteau est effectivement repeint en vert.

Un exemple : https://www.osmhydrant.org/beta/#node/3249128489 (activer
"photo integration" dans les réglages pour voir la photo).

En conclusion, rajouter le préfixe *disused:* et ajouter éventuellement
l'attribut pour indiquer que c'est une borne de puisage.

_
Yves



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Retour sur les places de Parking PMR

2019-04-10 Diskussionsfäden pyrog
>Oublié (décidément !) de rajouter que tu peux aussi contacter les dev.
d'OsmAnd pour un rajout de surcouche *de POI* pour les places PMR (il y a
déjà les parcs de stationnement, dans la liste) si le rendu osm-fr ne te
convient pas ;)

Dans les secteurs où il n'y a pas trop de connection 3G/4G… télécharger une
carte en ligne n'est pas évident.
Et surtout, on perd le rendu vectoriel d'OSMand.

La recherche dans OSMand de parkings avec des places PMR est possible (mais
pas conviviale) :
* rechercher "parking"
* choisir "Parc de stationnement"
* appuyez sur le bouton filtre
* tout en bas de la liste, choisir "Accessibilité aux fauteuils roulants" et
cocher la ou les option(s) souhaitée(s) :
Oui, non, limitée, Accès conçu pour les fauteuils roulants

Mais il n'y a rien pour les places de parking dédiée. J'ai créé une demande
d'amélioration :
https://github.com/osmandapp/Osmand/issues/6805

Vous pouvez rajouter un  pour inciter les dévs à la traiter rapidement.

—
Yves



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


[Talk-at] Hinweis Forumsthemen

2019-04-10 Diskussionsfäden gppes_osm
Liebe Kollegen,

ich bin kein grosser Freund von Cross-Postings und verspreche solche Emails nur 
selten auszuschicken.

Fuer die Leute, die das Forum nicht so oft besuchen moechte ich aber auf 
folgende beide Themen, die ich durchaus interessant oder wichtig finde 
hinweisen:

1) OSM und "Privatsphaere" bei Einfahrten auf Privatgrundstuecken:
https://forum.openstreetmap.org/viewtopic.php?id=65913

2) Wann place=town verwenden, wann eher village oder sonstwas:
https://forum.openstreetmap.org/viewtopic.php?id=65610

Lg, Gppes

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


Re: [OSM-talk] Dialects of English | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Yves
Please note that ID make a pretty good job in localization. I'd say that to 
influence tags meaning, the Transifex tasks, open to any contributors, is a 
more powerful tool than iD code and pressets.
Yves___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-legal-talk] OSM for training ML machines

2019-04-10 Diskussionsfäden Christoph Hormann
On Wednesday 10 April 2019, althio wrote:
>
> A typical "learned" model, based on a ML algorithm and a substantial
> extract of OSM data:
> That seems like a Produced Work to me.
>
> Hence...
> [...]

Maybe i have not been clear enough with my comment - approaching this
matter based on gut feeling and wishful thinking (seems like...)
without considering the practical effects is a very bad idea.

You can design 'learning' algorithms to essentially replicate the
training data so to just sweepingly declare any output of algorithms as
having no copyright connection to training data is a recipe for
desaster (if you subscribe to the spirit of the OdbL) or a recipe for
success (if your goal is to abolish share-alike and attribution through
the back door - which of course many corporate OSM data users would
find highly desirable).

And as also said concentrating exclusively on the produced work vs.
derivative database is not really helpful, in particular since we have
established a long time ago that using a produced work to reconstruct
semantic information of substantial volume will not set you free of the
requirements of the ODbL regarding derivative databases.  So even if
you have a basis for considering the algorithm trained with OSM data a
produced work, that does not mean that the output of this algorithm,
which might be data of exactly the same type as in the OSM database, is
not a derivative database.

If you need an example:  Take a translator for geographic names trained
using OSM data.  This translator in practical use will spit out names
or name components identical to those from the OSM database (if it does
not it'd be pretty useless).  These names - in sufficient volume -
evidently form a derivative database IMO - even if they are not the
result of a literal copy but result from 'knowledge' encoded in a
neural network.

When considering this subject, maybe think of it less as a question of
copying data, think of it more as a process of mimicry.

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

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


Re: [Talk-it] autoveicoli, roulotte, camion e camper abbandonati

2019-04-10 Diskussionsfäden demon_box
Italy General mailing list wrote
> Personalmente eviterei di mappare certe "strutture" che possono rimanere 
> lì per anni ma magari il comune un certo giorno trova i fondi e in una 
> settimana fa sparire questi oggetti mappati. 

Posso anche essere tranquillamente d'accordo con questa interpretazione ma
segnalo che tutti i miei casi si riferiscono a zone isolate, fuori mano,
liberamente accessibili ma private perciò semmai un giorno il veicolo verrà
rimosso sarà il proprietario a farlo e perciò, secondo me, ciò ricade nel
caso di un qualsiasi cambiamento su un qualsiasi oggetto che abbiamo mappato
in passato, ad es. una casa che viene demolita e basta.
a ben pensarci, niente è per sempre di ciò che mappiamo, addirittura gli
elementi naturali possono cambiare!

--enrico





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

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


[Talk-it] obblighi e restrizioni alla circolazione

2019-04-10 Diskussionsfäden Alessandro Palmas

Ciao lista,
oggi nelle Wikimedia news uscirà una breve sulle relazioni di obbligo o 
divieto di svolta.
Qui https://commons.wikimedia.org/wiki/File:Restrizioni_in_Italia.jpg 
trovate l'immagine di JOSM che crea una artwork carina.


A parte la curiosità, ho contato poco meno di 79.000 relazioni di questo 
tipo, decisamente poche per la realtà italiana. Vi ricordo che con JOSM 
installando il plugin turn_restriction mappare le restrizioni è molto 
semplice e migliora di molto il routing.


Alessandro

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


Re: [Talk-it] domanda banale - denominazione palazzo

2019-04-10 Diskussionsfäden Marco Ciampa
On Wed, Apr 10, 2019 at 11:25:47AM +0200, Marco Ciampa wrote:
> Ho scritto su Telegram ma evidentemente non c'era nessuno "pronto"...
> 
> Copio incollo:
> 
> Domandina veloce: a Trento in via Gilli 3 c'è il "Palazzo Istruzione" che
> è anche sede del "Dipartimento Istruzione e Cultura della PAT" ... come
> ci metto queste info? building name per me andrebbe solo la prima, ma la
> seconda? È come una scuola che sta dentro un palazzo storico, come
> separare il nome del palazzo dalla funzione?

Ho risolto (come mi hanno suggerito su Telegram) facendo così:

name=funzione
building:name=nome del palazzo

Spero sia giusto.

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




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


Re: [Talk-it] autoveicoli, roulotte, camion e camper abbandonati

2019-04-10 Diskussionsfäden Alessandro P. via Talk-it

Il 10/04/19 10:53, demon_box ha scritto:

ciao, in zone extra urbane (ad es. vicino al bosco) mi capita spesso di
imbattermi in automobili, roulotte, camion oppure camper abbandonati in
maniera evidente.


Personalmente eviterei di mappare certe "strutture" che possono rimanere 
lì per anni ma magari il comune un certo giorno trova i fondi e in una 
settimana fa sparire questi oggetti mappati. A quel punto ci troveremmo 
con queste strutture effimere mappate ma non più esistenti.


Facendo la tara sull'utilità di mapparle contro la possibilità che 
dall'oggi al domani scompaiano io voto decisamente per non mapparle.


Alessandro

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


[Talk-it] domanda banale - denominazione palazzo

2019-04-10 Diskussionsfäden Marco Ciampa
Ho scritto su Telegram ma evidentemente non c'era nessuno "pronto"...

Copio incollo:

Domandina veloce: a Trento in via Gilli 3 c'è il "Palazzo Istruzione" che
è anche sede del "Dipartimento Istruzione e Cultura della PAT" ... come
ci metto queste info? building name per me andrebbe solo la prima, ma la
seconda? È come una scuola che sta dentro un palazzo storico, come
separare il nome del palazzo dalla funzione?

--

Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




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


[OSM-talk] Dialects of English | Re: iD influencing tagging

2019-04-10 Diskussionsfäden Rory McCann


A better example might be "college", which has different meanings in
different dialects of English, or "gallon" or "football"

I don't think there is a solution this, except better localization of
software. Or we all just switch to Esperanto or Irish or something.

If you want real fun, just talk about "tabling an agenda item" 

On 08/04/2019 18:32, Yuri Astrakhan wrote:
Martin, thanks for explanation, but my point still stands -- in tags, we 
treat words not at their own meaning, but as IDs that represent some 
agreed concepts.  The German wiki page has a warning about 
"evangelical", so it is likely not all German-speaking mappers are aware 
of the distinction, or know English well enough to know this.  The same 
applies to highways - "highway" the word has different meaning in 
different regions, whereas "highway" the OSM tag should have just a 
single meaning that's clear to every mapper and every consumer.


On Mon, Apr 8, 2019 at 3:50 AM Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:




sent from a phone

 > On 7. Apr 2019, at 22:23, Yuri Astrakhan mailto:yuriastrak...@gmail.com>> wrote:
 >
 > A good example is "denomination=evangelical" -- German speakers
should not use it for "evangelisch" which stands for
denomination=protestant. The word may be the same, but we treat
"evangelical" as an ID for a specific meaning, rather than reflect
local language customs.


actually “evangelical” translates in German to “evangelikal”, which
doesn’t seem to be very confusing. Someone thinking it means
“evangelisch” is likely mapping in a domain s/he isn’t acquainted with.

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


[Talk-it] autoveicoli, roulotte, camion e camper abbandonati

2019-04-10 Diskussionsfäden demon_box
ciao, in zone extra urbane (ad es. vicino al bosco) mi capita spesso di
imbattermi in automobili, roulotte, camion oppure camper abbandonati in
maniera evidente.

non sono incidentati (quasi mai), a volte hanno ancora addirittura anche la
targa ma si capisce che sono lì da anni e da lì nessuno ha intenzione di
spostarli. è perciò un oggetto statico ed in quanto tale secondo me
mappabile.

come si taggano?

in passato avevo trovato una soluzione tipo

historic=car_wreck

certo il termine historic è un po' tirato, si intende piuttosto un oggetto
semplicemente "vecchio" ma non ha di certo nessun valore
turistico/storico...

qualcuno ha qualche idea magari migliore?

grazie

--enrico




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

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


[Talk-it] appostamento di caccia su ruote

2019-04-10 Diskussionsfäden demon_box
ciao, per "l'angolo delle cose strane" ho un capanno di caccia fissato sopra
un carretto con ruote.

da ciò che intuisco, durante il periodo di caccia viene spostato dove meglio
serve allo scopo e poi a periodo terminato, viene ri-spostato di qualche
decina di metri, diciamo "parcheggiato" poco distante.

come mi comporto?

ad   amenity=hunting_stand aggiungo

mobile=yes
moveable=yes   ?

o cos'altro?
che mi dite?

tra l'altro nella mia provincia è già il secondo che trovo...

grazie

--enrico




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

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


Re: [OSM-legal-talk] OSM for training ML machines

2019-04-10 Diskussionsfäden althio
I will add my 2 cents in the same pot as Kathleen.

A typical "learned" model, based on a ML algorithm and a substantial
extract of OSM data:
That seems like a Produced Work to me.

Hence...
- licence for the training inputs (underlying database, data
structures built before learning): release under ODbL (Derivative
Database; publish the entire database; or alterations; or algorithm)
- licence for the model (weights, internal data structures built
during learning): Produced Work, release under any license that you
like (Share Alike: no), required to credit OpenStreetMap (Attribution:
yes)
- licence for the results (outputs): provided there are an
insubstantial extract or contain no OSM data, release under any
license that you like (Share Alike: no), not required to credit
OpenStreetMap (Attribution: no)

If the results (outputs) are used to create a new database that
contains the whole or a substantial part of the contents of the OSM
database, this new database would be considered a Derivative Database
and would trigger share-alike obligations under section 4.4.b of the
ODbL. [shameless plug of Geocoding guideline]

In fact, I think the Geocoding guideline is a very good starting point
and could be extended to cover other applications (ML-based or not).
Geocoder underlying database ~equivalent~ training inputs
Geocoder application ~equivalent~ ML-based model
Geocoding results ~equivalent~ model outputs

This is my understanding or interpretation of the current materials:
https://opendatacommons.org/licenses/odbl/1.0/
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline
https://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline

-- althio

On Tue, 9 Apr 2019 at 15:35, Kathleen Lu via legal-talk
 wrote:
>
> My two cents:
> I'm not sure what you mean by internal data structures. If OSM data is used 
> to train a ML algorithm, then I would think that the training inputs could be 
> a substantial extract (possibly a trivial transformation of an extract). But 
> what is trained would be an algorithm/weights, which I generally do not think 
> of as a database at all? But since it uses an OSM database, a Produced Work 
> seems the right concept:
> "a work (such as an image, audiovisual material, text,
> or sounds) resulting from using the whole or a Substantial part of the
> Contents (via a search or other query) from this Database, a Derivative
> Database, or this Database as part of a Collective Database."
> -Kathleen
>
>
>
> On Tue, Apr 9, 2019 at 5:06 AM Frederik Ramm  wrote:
>>
>> Hi,
>>
>> is it a community consensus that, when someone uses OSM to train their
>> machine learning "black box", the internal data structures built during
>> learning constitute a derivative database? Or are there people who argue
>> that somehow the "black box" can ingest OSM data at will and still
>> remain 100% intellectual property of its operator?
>>
>> Further, assuming that we have a system that has ingested OSM by deep
>> learning and we say that this means its internal database is ODbL, what
>> would this mean for the output later produced by the same machine?
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk

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


Re: [talk-au] Shout out

2019-04-10 Diskussionsfäden David Wales
Fair enough.

Probably worth loading up some LPI NSW imagery and seeing if things look 
legitimate. 



On 10 April 2019 4:14:50 pm AEST, Warin <61sundow...@gmail.com> wrote:
>Quible... no change set comments.
>It does look good, but I have not bothered to check any of it.
>
>
>On 10/04/19 16:08, Dion Moult wrote:
>> Awesome work! The user in question is "balcoath" - it looks great!
>>
>>
>> Dion Moult
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, April 10, 2019 1:43 PM, David Wales
> wrote:
>>
>>> Hi Talk-AU,
>>>
>>> I just noticed evidence of some serious mapping commitment around
>Revesby.
>>>
>>> As far as I can tell, one person has been tracing all the buildings
>in
>>> this area, for the last 8 years!
>>>
>>> https://www.openstreetmap.org/#map=15/-33.9537/151.0142
>>>
>>> Impressive!
>>>
>>> Regards,
>>> David Wales
>>>
>>> Talk-au mailing list
>>> Talk-au@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>
>
>
>___
>Talk-au mailing list
>Talk-au@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [OSM-talk-fr] Cartographie de l'accessibilité fauteuils roulants et aveugles

2019-04-10 Diskussionsfäden Vincent Bergeot

Le 09/04/2019 à 20:21, Violaine_Do a écrit :
Merci Marc, je demande ça pour les valeurs à utiliser sur le wiki 
francais (fr:handicaps) par rapport aux usages (en effet suggestion 
d'utiliser bad à la place de limited ou incorrect sur ce wiki), donc 
j'aimerais mettre ça à jour, j'osais pas changer le wiki sans vos 
retours.



Bonjour,

nous avons eu justement cette discussion autour de la valeur bad il y a 
2 jours avec Adrien et Louis-Julien.


J'ai posé 2 osmecum 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum#Les_fiches_OSMecum


je n'ai pas fait apparaître cette valeur.

Pourquoi ?

Car dans le cas des fauteuils, je pense que la valeur bad est une erreur 
(sans doute dans un processus de traduction comme access=yes).


Tel que c'est décrit (et ce n'est renseigné que dans le wiki en 
français), cela me semble surtout corresponde à limited et si besoin en 
ajoutant d'autres tags type wheelchair:description=* et/ou des éléments 
factuels de type hauteur de la marche, revêtement, ...


Taginfo nous donne 741 occurences 
(https://taginfo.openstreetmap.org/tags/wheelchair=bad#overview) pour 
wheelchair=bad dont (553 en france 
https://taginfo.openstreetmap.fr/search?q=wheelchair%3Dbad).


Donc c'est quand même un peu franco-français. Je ne suis pas sur que la 
discussion sur tagging soit nécessaire ?


à plus






Sur ma todo la traduction de kerb en fr, et trouver ces fameuses fiches.
@+

On 09/04/2019 00:44, marc marc wrote:

Bonjour,

Le 09.04.19 à 02:38, Violaine_Do a écrit :

J'ai détaillé mes questions sur la page discussion du wiki dédié :
https://wiki.openstreetmap.org/wiki/FR_talk:Handicaps

je ne comprend pas la question "qu'est-ce qu'on fait ?"
les cas les plus courant/important
tactile_paving=yes|no|incorrect
wheelchair=yes|no|limited
kerb=raised|lowered|flush

ce qui manque c'est :
- la traduction en français de la page kerb
- faire le lien vers les fiches de... heu.. Françoise je crois

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




--
Vincent Bergeot


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


Re: [Talk-it] Dubbop su tag inscription (forse)

2019-04-10 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 9. Apr 2019, at 15:25, demon_box  wrote:
> 
> inscription=POSTE E TELEGRAFI   messo sul building?


volendo, c‘è anche historic=epigraph (proposed)


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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-04-10 Diskussionsfäden Grigory Rechistov via Talk-se
Hej Anders,
> Hur många överlappande polygoner blir det i en kommun?
Bra fråga. För de kommuner som redan är väl kartlagda misstänker jag att 
antalet blir stort, liksom tusentals befintliga polygoner mot tiotusentals nya 
polygoner från importen.

> Det är lätt att missa något scenario man inte tänkt på i en algoritm.
Jo, det är min mening att algoritmen ska vara mycket konservativ och vid minst 
osäkerhet ska markera polygoner med en tagg (jag ämnar nämna den 
"nmd2018:conflicts-with"). Sedan kan en människa hitta alla polygoner med den 
där taggen och lösa eventuella överlappningar själv.

Även om  algoritmen  beslutar  att en väg ska bort blir det hellre den nya 
vägen från importen än den befintliga vägen.

Även vid en sådan metod finns det risk att få för mycket eventuella konflikter 
i vissa kommuner. I så fall får man uppfinna en bättre algoritm. Någonting som, 
innan man vectorizerar rastern för kommunen maskerar man pixlar som redan har 
skog/åkermark på OSM.

Om allt går bra har jag ett prototypskript för conflation ikväll. Då får jag 
pröva det på Vingåkers kommun för vilken jag tidigare har fått data .

>Вторник,  9 апреля 2019, 16:01 +03:00 от Micke :
>
>Hej!
>
>Hur många överlappande polygoner blir det i en kommun?
>
>Är det enklare och säkrare om dessa hanteras av en människa som tar beslut om 
>vilken polygon som är bäst? Förutsatt att det inte blir för stor mängd så 
>tycker jag det låter säkrare. Det är lätt att missa något scenario man inte 
>tänkt på i en algoritm.
>
>/Anders Andersson
>
С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-lt] Metinis susitikimas

2019-04-10 Diskussionsfäden Tomas Straupis
Sveiki
Primenu, kad šiandien 18:00 Savičiaus Špunkoje:
https://openmap.lt/#m/18/54.67875/25.28902/0/0//p2811970425
vyks metinis asociacijos „Atvirasis žemėlapis“ susitikimas.

Kviečiami visi, norintys pasikalbėti apie OpenStreetMap, aptarti
rūpimus dalykus, paklausti klausimus, susipažinti, na ir šiaip
pablegyzgoti apie žemėlapius.

Susitikimas bus rūsyje, tai sakykite barmenams ir barmenėms, kad
einate „pas Tomą“, jus nukreips žemyn :-)

-- 
Tomas

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


Re: [Talk-gb-westmidlands] A34 cycle route

2019-04-10 Diskussionsfäden Andy Robinson
Excellent, Cheers Brian.

 

Andy

 

From: Brian Prangle [mailto:br...@mappa-mercia.org] 
Sent: 09 April 2019 22:04
To: Andy Robinson
Cc: OSM Group WM
Subject: Re: [Talk-gb-westmidlands] A34 cycle route

 

All in hand I have surveyed most of it and added it as an untagged way

I'll tag it tomorrow

 

On Tue, 9 Apr 2019, 21:15 Andy Robinson,  wrote:

I see the new A34 cycle route is basically open. Looks like there is some 
mapping to do! Alas I can’t get onto it anytime soon.

 

Cheers

Andy (now very definitely in Cheshire)

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

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


Re: [talk-au] Shout out

2019-04-10 Diskussionsfäden Warin

Quible... no change set comments.
It does look good, but I have not bothered to check any of it.


On 10/04/19 16:08, Dion Moult wrote:

Awesome work! The user in question is "balcoath" - it looks great!


Dion Moult

‐‐‐ Original Message ‐‐‐
On Wednesday, April 10, 2019 1:43 PM, David Wales  
wrote:


Hi Talk-AU,

I just noticed evidence of some serious mapping commitment around Revesby.

As far as I can tell, one person has been tracing all the buildings in
this area, for the last 8 years!

https://www.openstreetmap.org/#map=15/-33.9537/151.0142

Impressive!

Regards,
David Wales

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



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




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


Re: [talk-au] Shout out

2019-04-10 Diskussionsfäden Dion Moult
Awesome work! The user in question is "balcoath" - it looks great!


Dion Moult

‐‐‐ Original Message ‐‐‐
On Wednesday, April 10, 2019 1:43 PM, David Wales  
wrote:

> Hi Talk-AU,
>
> I just noticed evidence of some serious mapping commitment around Revesby.
>
> As far as I can tell, one person has been tracing all the buildings in
> this area, for the last 8 years!
>
> https://www.openstreetmap.org/#map=15/-33.9537/151.0142
>
> Impressive!
>
> Regards,
> David Wales
>
> 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