Re: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione aldoct
Grazie, siete sempre disponibili e utilissimi



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

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


Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

2020-05-07 Per discussione stevea
Our wiki is a vital source of reference and "how to."  It deserves the very 
best effort we can give it.  Sometimes, especially with a complex topic where 
local knowledge matters, yet so also does learned, scholarly perspective, a 
Discussion page gets wordy and detailed.  I do believe OSM wants to get this 
page as "right" as it can.  Minh and I agree there can be "multiple books in 
the library about (roughly) one subject;" the wiki he started on Boundaries is 
"more descriptive"while this one is "more prescriptive."  We walk a careful 
edge.  There are some crafted boundaries (heh) of syntax and semantics.  Let's 
build upon what we've built (with some effort).

Greg, the sort of COG Connecticut has built (an RCOG) is unique as "COG entity 
in a state with no counties."  There are also COGs in states with counties and 
I temporarily assume perhaps in states with townships, though I can't offer 
immediately a concrete example.  I don't know what numerical value of 
admin_level we would begin to assign to these (we shouldn't assign any, imho, 
and it seems your opinion, too), I have heard 5, 5.5. 6 and 7.  "Collisions 
with existing," hence 5.5.  We started to do this with CDPs at 8 and backed 
that out:  they're not these.

Please, put the boundary in the map if you must and tag it boundary=COG and 
let's be done, please.  No admin_level value at all, unless we can tolerate 
seemingly endless discussion and maybe some heated argument, too.  Clifford 
hasn't the patience as loudly and clearly, patience is wearing thin.  If we 
must continue, let's be careful to keep it civil and scholarly if we can.

And shorter.

Paul's mentioning of COGs in Oregon reminds me the decision didn't go over well 
(years ago) with many in Oregon, who rather strongly feel their COGs should 
have an admin_level value, though I'm not sure any numerical value revealed 
itself.  I made a call for an expert in Oregon's Blue Book to chime in; 
nothing.  (There are "collisions" in the number space with 5, 6 and 7 in other 
states).  If we let this genie out of this bottle, poof, we suddenly have a 
rainbow of values and state-specific up-and-down-the-hierarchy relationships 
between brand new things that need pigeon-holing we don't need to do:  these 
already have names and a tagging scheme (boundary=COG).  Maybe that's OK, maybe 
admin_level wasn't meant to be "beaten up" like that.  I don't look forward to 
participating in those discussions, that's for sure.

It's manageable, it takes some words and time to slog through.  Let's keep that 
trimmed well.

SteveA

> On May 7, 2020, at 6:07 PM, Greg Troxel  wrote:
> For what it's worth, I live in Massachusetts, which is next to
> Connecticut, and generally pay attention.  I have aboslutely zero idea
> what a COG/MPO is, but I think admin_level belongs on state/county/town
> and things that pretty much everybody recognizes as admininstrative
> subdivisions.  There are school districts, sewer districts, historical
> districts, and a ton of other things, that are something else.
> 
> I do fear for the future of OSM that wiki editing is such a big thing.


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


Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

2020-05-07 Per discussione Greg Troxel
stevea  writes:

> The topic is active again at
> https://wiki.osm.org/wiki/Talk:United_States_admin_level#Recently_added_Connecticut_COG_.28Regions.29_as_5_and_CDP_as_10_should_be_deleted
> and seems to need the assistance of seasoned political scientists who
> can say whether a COG in Connecticut, for example, is "a government"
> or not.  (I say a COG/MPO is a LIMITED government, like a sewer
> district, so isn't "really" a "full spectrum" government, therefore
> shouldn't get an admin_level value, as this key associates with
> boundary=administrative).

For what it's worth, I live in Massachusetts, which is next to
Connecticut, and generally pay attention.  I have aboslutely zero idea
what a COG/MPO is, but I think admin_level belongs on state/county/town
and things that pretty much everybody recognizes as admininstrative
subdivisions.  There are school districts, sewer districts, historical
districts, and a ton of other things, that are something else.

I do fear for the future of OSM that wiki editing is such a big thing.

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


Re: [Talk-it] Village / Town

2020-05-07 Per discussione totera
dieterdreist wrote
> Civitella del Tronto apparently has the città title.

Oltre al fatto che si tratta di un titolo onorifico, non potremmo usare come
criterio la "città" per un altro motivo: il titolo è conferito al comune,
non al centro abitato.

Questo mi dà l'occasione per far notare una confusione che risale alla notte
dei tempi di OSM in Italia: ci fu un primo import in cui vennero inseriti
come place tutti i comuni, con il nome del comune e la popolazione
(censimento 2001) di tutto il comune sul nodo, poi successivamente fu messo
a disposizione il tool per l'importazione delle altre località abitate.

Nacquero così due problemi: dati sulla popolazione incoerenti (con abitanti
praticamente contati due volte!) e classificazione del centro abitato non
sempre corrispondente alla realtà.

Ad esempio, per restare in Abruzzo, abbiamo come town Tortoreto (840
abitanti, non c'è neanche la scuola media, probabilmente l'unico servizio di
una certa importanza è il municipio); ancora più grave la situazione di uno
dei centri toccati dalle modifiche di Fintocubano/Fra00, San Giovanni
Teatino, che è town con 226 abitanti e non ha neanche il municipio visto che
la sede comunale è Sambuceto.

Nel tempo mi pare che l'utente fayor abbia sistemato i nomi delle località
per i comuni sparsi; per la popolazione c'è da prendere ad esempio l'ottimo
lavoro fatto in Umbria da arcanma, che ha riportato la popolazione del
comune sulla relazione e quella della località sul centro omonimo, con tanto
di note esplicative.

Visto che è stato risollevato il tema della classificazione, sarebbe
opportuno dare uno sguardo e correggere anche queste situazioni.



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

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


Re: [Talk-hr] Kucni brojevi

2020-05-07 Per discussione Matija Nalis
TL;DR:

Ja addr:city, addr:postcode, addr:country ne bih stavljao ako ne
postoji jako dobar razlog u nekom specificnom slucaju (a i tada sa
note tagom koji objasnjava situaciju zasto).

Detalji nize

On Thu, May 07, 2020 at 12:12:17AM +0200, hbogner wrote:
> On 06. 05. 2020. 12:21, Janko Mihelić wrote:
> > uto, 5. svi 2020. u 22:52 Martin Sever  napisao je:
> > 
> > > nisam siguran kod "addr:place" ili "addr:city". Npr.
> > > kad se ime naselja i poštanskog ureda nisu jednaki.
> > > Evo primjer jednog šoping centra
> > > https://www.openstreetmap.org/way/230131183
> > > Ovdje je pod "addr:place" ime naselja u kojem se objekt nalazi, a pod
> > > "addr:city" ime naselja u kojem je odredišni poštanski ured.
> > > Da li je ovakvo označavanje u redu, ili treba nešto promjeniti?
> > > 
> > 
> > Dobra pitanja! Malo sam prokopao, i evo odgovora. addr:place=* se koristi
> > za sela u kojima nema imena ulica. Dakle ako netko u selu ima adresu
> > "Bebrina 34", "Bebrina" se ne stavlja u addr:street, jer to nije ime ulice,
> > nego "addr:place=Bebrina". Također, ne bi trebalo na ulice
> > (highway=residential) stavljati ta imena sela, jer opet, to nisu imena
> > ulica. To viđam često.
> > Drugim riječima, na tvojem šoping centru krivo je upisan taj tag, pošto
> > postoji ime ulice. addr:street i addr:place ne bi trebali postojati zajedno.

Ovo za addr:place je posebno korisno, tnx!

> > addr:city se koristi za ime grada u kojem je neka kuća, uz ime ulice. Nemam
> > pojma kakve bi veze imao odredišni poštanski ured. Također, taj tag je
> > pomalo suvišan, jer često postoje granice grada pa je jasno u kojem je
> > gradu neka adresa. Ali nije krivo ako ga se postavi.
> > 
> > Janko

Slazem se sa Jankom oko toga.

> što se tiče samog označavanja adresa ovo su oznake koje bi svaki kućni broj
> trebao sadržavati:
> 
> addr:housenumber
> addr:street - ili addr:place kao što kaže Janko
> addr:city - neznam koliki je ovo konflikt ako se koristi addr:place
> addr:postcode
> 
> opcionalno:
> addr:country - nije potreban ali se može staviti
> 
> Ovo mi je usmeno potvrđeno nakon predavanja:
> https://2018.stateofthemap.org/2018/T094-Addressing_addresses/
> Bitno je da se unificiramo na razini države i da svi to stavljaju.

A koji je onda smisao administrative boundary? Ne bi li iz toga
trebalo biti ocito koja drzava i grad su u pitanju za neki POI?

Gledam slideove tog predavanja sto si poslao, na p.40 kaze da su 
mandatory samo:
"addr:housenumber, addr:housename" i 
"addr:street or addr:place (not both)"

Tako ja i stavljam (mahom samo addr:housenumber i addr:street), a i
to sto je u slideovima je konzistentno sa:
https://wiki.openstreetmap.org/wiki/Key:addr

Cisto zato, jer naime nije neka sreca imati bazu podatka sa
dupliciranim podacima, jer ti duplici hoce ponekad biti razliciti, a
onda imamo nekonzistenciju (npr. ako je POI sa addr:city sa jednim
imenom koji je unutar boundary=administrative sa drugim imenom).

IMHO bolje je imati samo jedan podatak, onaj preferirani - u nasem
slucaju mislim da bi to radije bio ispravan boundary=administrative 
(a ne addr:city po svim POIs)

A addr:postcode mi se pogotovo cini problematican kod nas (za razliku
od recimo, Londona - gdje je fiksan, na tablama i prakticki bitniji od
ulice i kucnog broja!) - ako je to onaj postanski broj koji se pise na
pismo prije imena grada i gdje moras ici po paket kada je postar
prelijen pozvoniti da preda paket...

Npr.  za isti kucni broj na Vrbanima su u zadnjih par godina
mijenjali postcode barem tri puta, kako su stavljali koju nadleznu
postu (prvo je bio 10110 - Ozaljska, pa su onda to micali na Point
Centar / Rudeška, pa onda na 10104 Hrgovići).  Tak da moram sad imati
spisak koji dokument/kartica mi se vodi na kojem postanskom broju
(dok ne isteknu), iako su svi na potpuno istoj fizickoj lokaciji/adresi.
Tak da je u Zg recimo sigurnije pisati uvijek "1 Zagreb", cak i
ako znas koji ti je tocan postanski broj (jer je pitanje dokle ce
biti), barem po mojim iskustvima.

Dodatni problem s postanskim brojem kod nas je sto on nije "on the
ground" podatak (tj. za razliku od ulice i kucnog broja ga na terenu
ne mozemo fizicki provjeriti), tako da ga isto ne bih stavljao u
addr:postcode na POI/buildings (u boundary=* za manja
mjesta gdje je postcode fiksan je pozeljan, svakako).

-- 
Opinions above are GNU-copylefted.

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


Re: [Talk-us] How to map snowmobile trails in US?

2020-05-07 Per discussione Bob Gambrel
Thanks for all the ideas so far. I like the route (relationship) approach
and that seems very appropriate. Unfortunately I did not do the mapping and
am just trying to figure out how much to get involved in this snowmobile
project yet (am concentrating on bike paths, etc for now).

In my neck of woods some parts of the snowmobile routes are on existing or
newly created paths/tracks/etc. They can be mapped easily. I understand how
to handle them. Other parts are in ditches near side of the road, along
fences near Interstate highways, on property lines between farms, etc. In
those area there is no way that would be mapped during the summer. So in
some sense it seems the right thing to do is to have a way there, of some
type, that represents something that is invisible in summer but part of a
snowmobile route.

So imagine this simple example. A path (of some sort) goes from point A to
B. Between points B and C there is no way (no path, road, highway, cycle
way, foot path, track, etc. Then there is another path of some sort between
points C and D. So the relationship (a snowmobile route) includes ways
"AB", "BC" and "CD". What type of way should "BC" be?

This area shows such a snowmobile trail:

https://www.openstreetmap.org/edit#map=17/45.83596/-95.31124

Much of it is not along any visible way of any sort. It looks like part of
it could be on an existing (but not mapped unpaved service road) and part
of it crosses a stream next to (but probably on) an unmapped little bridge.
If all the ways that were mappable were actually mapped, most of the
snomobile trail would still be on unmapped (unmappable) "invisible in the
summer" ways.

I can transfer this thread/discussion to another forum (tagging?) if
appropriate. Thank you for all your energy and patience so far!

On Thu, May 7, 2020 at 6:37 PM Dave Swarthout 
wrote:

> > Please only use highway=track when there is an forestry or agricultural
> road / track which is passable by 2-track vehicles such as farm tractors,
> logging trucks, or 4wd cars
> +1
>
> You might better use something like highway=path which allows for use by
> multiple vehicle types (snowmobile, ATC, ATV) as well as on foot via
> snowshoe or ski. Unless of course, it overlaps an agricultural or logging
> track.
>
> On Thu, May 7, 2020 at 11:14 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Winter-only snowmobile routes are mapped if they are signed. Create a
>> route relation with type=route + route=snowmobile (used 141 times) - see
>> https://wiki.openstreetmap.org/wiki/Tag%3Aroute%3Dsnowmobile
>>
>> Please only use highway=track when there is an forestry or agricultural
>> road / track which is passable by 2-track vehicles such as farm tractors,
>> logging trucks, or 4wd cars.
>>
>> -- Joseph Eisenberg
>>
>> (You might try the Tagging mailing list for questions about how to tag
>> something: tagg...@openstreetmap.org)
>>
>> On Thu, May 7, 2020 at 8:43 AM Kevin Broderick 
>> wrote:
>>
>>> Ideally, I'd say that most snowmobile routes should be relations, not
>>> ways. At least in the places I'm familiar with (New England and Montana), a
>>> significant portion of the snowmobile trail network overlaps with seasonal
>>> roads that are open to wheeled traffic in some conditions. Having the
>>> summer ground truth mapped accurately is hugely helpful if you're poking
>>> around in the summer, whether it be hiking, biking, riding an on/off-road
>>> motorcycle, etc; as you noted, some snowmachine trails are virtually
>>> invisible in the summer and may even be impassable (I'm familiar with some
>>> spots in Vermont where the snowmachine trails transit across swamp or
>>> marshland once it's frozen—not something you want to try to cross on foot
>>> or wheeled vehicle).
>>>
>>> Around here, there's also the side issue of someone having mapped one of
>>> the ITS routes as a track for a long distance, when it actually should be a
>>> series of ways with different data, as some parts are well-maintained
>>> gravel roads in the summer, others are less-well-maintained, some are
>>> public ways and others aren't.
>>>
>>> To answer the question about sections that specifically cross fields:
>>> I'd still be tempted to tag that as highway=track, with appropriate access
>>> and surface tags. I'm not sure it's the best way to do it, but I can't come
>>> up with a better way, and the track in question would likely be passable
>>> with permission and the right vehicle.
>>>
>>> As for sections that cross [frozen] marshes, or other areas that aren't
>>> passable when the ground is thawed, I don't know. Maybe there is a use case
>>> for "highway=frozen" or something similar, as ice_road is applied to
>>> another way, and none of the highway= values with which  I'm familiar would
>>> make sense.
>>>
>>> On Thu, May 7, 2020 at 10:41 AM Bob Gambrel  wrote:
>>>
 Am newby to talk-us. This may have been discussed in the past but not
 handy with searching archives yet.

 In Minnesota I 

Re: [Talk-it] Village / Town

2020-05-07 Per discussione totera
dieterdreist wrote
> Nereto is the legal seat of a union of 12 municipalities, and the town
> hall looks quite impressive for a “village”
> https://it.m.wikipedia.org/wiki/Unione_dei_comuni_Città_Territorio-Val_Vibrata
> 
> I believe it’s an edge case. The official website also has a page about
> the “town”
> https://www.comune.nereto.te.it/la-citta
> 
> Civitella del Tronto apparently has the città title.

(Passo all'italiano, credo valga la pena proseguire questa discussione)

Nereto ha un istituto di istruzione superiore, l'agenzia INPS, il Centro per
l'Impiego, quindi è sicuramente sede di servizi utilizzati anche dagli
abitanti dei centri vicini; Civitella del Tronto, anche se ha la sua
importanza storico/turistica, no.

Ciao,
Gianluca



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

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


Re: [Talk-us] How to map snowmobile trails in US?

2020-05-07 Per discussione Dave Swarthout
> Please only use highway=track when there is an forestry or agricultural
road / track which is passable by 2-track vehicles such as farm tractors,
logging trucks, or 4wd cars
+1

You might better use something like highway=path which allows for use by
multiple vehicle types (snowmobile, ATC, ATV) as well as on foot via
snowshoe or ski. Unless of course, it overlaps an agricultural or logging
track.

On Thu, May 7, 2020 at 11:14 PM Joseph Eisenberg 
wrote:

> Winter-only snowmobile routes are mapped if they are signed. Create a
> route relation with type=route + route=snowmobile (used 141 times) - see
> https://wiki.openstreetmap.org/wiki/Tag%3Aroute%3Dsnowmobile
>
> Please only use highway=track when there is an forestry or agricultural
> road / track which is passable by 2-track vehicles such as farm tractors,
> logging trucks, or 4wd cars.
>
> -- Joseph Eisenberg
>
> (You might try the Tagging mailing list for questions about how to tag
> something: tagg...@openstreetmap.org)
>
> On Thu, May 7, 2020 at 8:43 AM Kevin Broderick 
> wrote:
>
>> Ideally, I'd say that most snowmobile routes should be relations, not
>> ways. At least in the places I'm familiar with (New England and Montana), a
>> significant portion of the snowmobile trail network overlaps with seasonal
>> roads that are open to wheeled traffic in some conditions. Having the
>> summer ground truth mapped accurately is hugely helpful if you're poking
>> around in the summer, whether it be hiking, biking, riding an on/off-road
>> motorcycle, etc; as you noted, some snowmachine trails are virtually
>> invisible in the summer and may even be impassable (I'm familiar with some
>> spots in Vermont where the snowmachine trails transit across swamp or
>> marshland once it's frozen—not something you want to try to cross on foot
>> or wheeled vehicle).
>>
>> Around here, there's also the side issue of someone having mapped one of
>> the ITS routes as a track for a long distance, when it actually should be a
>> series of ways with different data, as some parts are well-maintained
>> gravel roads in the summer, others are less-well-maintained, some are
>> public ways and others aren't.
>>
>> To answer the question about sections that specifically cross fields: I'd
>> still be tempted to tag that as highway=track, with appropriate access and
>> surface tags. I'm not sure it's the best way to do it, but I can't come up
>> with a better way, and the track in question would likely be passable with
>> permission and the right vehicle.
>>
>> As for sections that cross [frozen] marshes, or other areas that aren't
>> passable when the ground is thawed, I don't know. Maybe there is a use case
>> for "highway=frozen" or something similar, as ice_road is applied to
>> another way, and none of the highway= values with which  I'm familiar would
>> make sense.
>>
>> On Thu, May 7, 2020 at 10:41 AM Bob Gambrel  wrote:
>>
>>> Am newby to talk-us. This may have been discussed in the past but not
>>> handy with searching archives yet.
>>>
>>> In Minnesota I have seen snowmobile trails mapped in OSM as follows:
>>>
>>> highway=track
>>> snowmobile=designated
>>> surface=unpaved
>>>
>>> In both aerial photos and observation on the ground, there is almost
>>> always no track visible. In the winter, with snow cover, the location of
>>> the track is visible because it is compacted by snowmobiles. In the spring
>>> there might be some evidence in areas with grasses that would have been
>>> tamped down by the snowmobiles.
>>>
>>> Question: Is this the right way to map snowmobile trails? The thing that
>>> concerns me, of course, is the use of "track" because of it is not apparent
>>> most of the time.
>>>
>>> Another question: is there a forum or expert group or something that
>>> discusses this? I would like to join that conversation if there is  one
>>> going on.
>>>
>>> I think it is a good idea to map these trails. It seems there maybe
>>> should be another type of highway? Something like: "not visible on the
>>> ground most of the year". Note that ice_road=yes is not appropriate here
>>> (in most cases) as (in most cases) these trails are not on frozen water
>>> bodies.
>>>
>>> As further info, where I was able to observe there are a number of signs
>>> posted such as stop signs, caution signs, etc. So there clearly is
>>> government involvement.
>>>
>>> Any thoughts?
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>>
>> --
>> Kevin Broderick
>> k...@kevinbroderick.com
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at 

Re: [Talk-hr] Mapiranje svih gradjevina u RH

2020-05-07 Per discussione Matija Nalis

On Tue, May 05, 2020 at 06:09:06PM +0200, martinswo...@gmail.com wrote:
> Nisam mislio da nije korisno mapirati sve, za to i sluzi OSM.

Mislim da je to vise bilo u smislu  "ima li nesto smisla ucrtavati
sada, ako ce uskoro doci bolji dataset", a ne "ima li smisla to uopce
ikada ucrtavati"...

> Medutim, sada je upravo trenutak da se jos jednom kontaktira DGU, jer moraju 
> adaptirati postojece zakonodavstvo do srpnja 2021. god. Mislim da zato ima 
> razloga zasto je DGU pristao OSM-u dati na raspolaganje te dodatne layere, 
> odnosno su to neki gradovi prepoznali. Razlog je sljedeca EU direktiva:
> 
> Open Data and Public Sector Information (PSI) Directive 2019/1024
> https://ec.europa.eu/digital-single-market/en/european-legislation-reuse-public-sector-information
> https://ec.europa.eu/digital-single-market/en/news/implementation-psi-directive-croatia
> 
> Uz to, upravo je u tijeku definiranje high value datasets, i tu se upravo 
> spominje katastar. Znaci od 2021 god. u svim zemljama clanicama trebao bi 
> biti dostupan katastarski layer, ne samo za OSM, nego za sve.
> 
> Eto, samo da znate uokviriti u planove. Treba sada vec energicno traziti da 
> OSM dobije pristup katastarskom layeru. Pitam se vise, zasto DGU nije vec u 
> proslom postupku dala odobrenje OSM-u za koristenje tog layera. Pitajte! 
> Inace kontaktirajte Središnji državni ured za razvoj digitalnog društva 
> (rdd.gov.hr)!

Interesantno, zivi bili pa vidjeli sto ce biti pokriveno direktivom
da se mora objaviti!  A to zasto se DGU bori rukama i nogama protiv
besplatnog dijeljenja podatka koje inace skupo prodaju mi nije
previse cudno :)


> -Ursprüngliche Nachricht-
> Von: hbogner  
> Gesendet: Dienstag, 5. Mai 2020 13:56
> An: talk-hr@openstreetmap.org
> Betreff: Re: [Talk-hr] Mapiranje svih gradjevina u RH
> 
> On 02. 05. 2020. 13:46, Janko Mihelić wrote:
> > On Fri, May 1, 2020, 11:37  wrote:
> > 
> >> Imamo li digitalni layer katastarskih cestica odnosno gradevina od 
> >> drzavne uprave? Ja bih krenuo u mapiranje toga kad to bude bilo 
> >> dostupno. Sve ostalo nije bas previse tocno.
> >>
> >> Sto se tice adresa, ustaljena praksa u drugim drzavama je ulaz (su 
> >> ulazi) u zgradu tocno na liniji zgrade prema cesti (vidi npr Beč).
> >>
> > 
> > Ima li smisla ucrtavati, o tome bi se dalo pričati. Ako digitalni 
> > layer dobijemo za 5 godina, to znači da ćemo toliko vremena biti bez 
> > koliko-toliko okej građevina. Nitko se neće tjerati da ucrtava. Jedino 
> > ako ima neki pametniji posao koji bi bio korisniji ili lakši pa da na 
> > to usmjerimo snage.
> > 
> > Što se adresa tiče, moj pristup je bio da se (a slično sam čitao na 
> > glavnoj tagging mailing listi), kad god je moguće, cijela zgrada označi sa 
> > adresom.
> > Na taj način ako stavimo POI u zgradu, on bi u nekim pametnijim 
> > geokoderima mogao preuzeti adresu zgrade oko njega (ako već nema 
> > adresu). Također, ako se ucrta 5 ulaza u neku veliku zgradu, onda bi 
> > ruter mogao rutati u najbliži ulaz od zgrade sa tom adresom.
> > 
> > Ako svaki ulaz neke zgrade ima drugu adresu, onda sam za pristup 
> > adrese na ulazima.
> > 
> > Inače nisam protiv toga da se adresa mapira više puta, dakle ako se 
> > mapira na zgradi i na ulazu, ne vidim problem.
> > 
> > Malo je zeznuto u slučaju industrijskog dvorišta koje ima jednu adresu.
> > Možeš adresu staviti na ulaznu kapiju, ulaznu recepciju, na upravnu 
> > zgradu, na cijelo zemljište.. Po meni je sve to okej, ako ih se 
> > adresira nekoliko, sve je ispravno. Ali opet, ako se stavi adresa na 
> > cijelo zemljište, pametni geokoder bi mogao dodijeliti svima unutra tu 
> > adresu.
> > 
> > Janko
> 
> 
> Ima smisla, to i je smisao OSM-a. Odradi ono što možeš s onim što imaš, a 
> kasnije se to nadograđuje. Ako čekamo ostvaranje državnih podataka možemo 
> odmah prestai sve što radimo, gasimo sve i čekamo da to netko drugi odradi 
> umjesto nas.
> 
> Ja sam do sad preferirao POI unutar građevine, ili POI na ulazu koji je 
> označen kao ulaz i kao kućni broj.
> 
> 
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr
> 
> 
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr

-- 
Opinions above are GNU-copylefted.

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


Re: [Talk-hr] Ukidanje dodatne domene osmhr.org

2020-05-07 Per discussione Matija Nalis
slazem se, neka istekne...

On Tue, May 05, 2020 at 01:44:00PM +0200, hbogner wrote:
> Još prije nekoliko godina tiskali smo nekoliko stotina osm i osm-hr letaka
> koje smo podjelili na dorscluc.org ili prosljedili ljudima okolo.
> 
> Jedini problem, koji smo naknadno uočili, je bio url na naš web, umjesto
> osm-hr.org pisalo je osmhr.org
> 
> Najbrže rješenje za taj problem je bio zakupiti osmhr.org domenu i
> redirektati ju na naš pravi web osm-hr.org što sam i napravio.
> 
> Mislim da više nema smisla paćati za tu dodatnu domenu.
> 
> Ako netko ima volje plaćati nek se javi, inače puštamo da istekne.

-- 
Opinions above are GNU-copylefted.

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


Re: [talk-cz] Značení firem

2020-05-07 Per discussione Jan Sten Adámek via talk-cz
Ahoj,

> Zdravím všechny, a jsem tu s dotazem. Poslední dobou narážím na to, že se
> (zejména) noví uživatelé snaží na mapu dostat firmu. A téměř vždy to končí
> prostým strčením do name u budovy, případně všech budov na pozemku, v
> horším případě i včetně popisu toho, co ta firma dělá/nabízí.
> Osobně jsem se doteď vyhýbala tomu, firmy do OSM dávat. Po projetí wiki se
> mi potvrdilo, že ten můj původní důvod trvá :) Je v tom totiž docela
> bordel, a podle mě se s tím zatím vůbec nepočítá.

Myslím si, že firmy by v mapě být měly, je to jedna z běžných funkcí mapy, 
Mapy.cz, Google Maps i Bing Maps je mají. Některé druhy firem mají tagy docela 
dobře dokumentované (třeba office=it nebo craft=bakery), u jiných je to horší.
https://wiki.openstreetmap.org/wiki/Category:Offices
https://wiki.openstreetmap.org/wiki/Key:craft

> Velká stavební firma:
> Centrála, závody - office=company & company=construction nebo
> nezdokumentované office=construction (viz debata u klíčů
> ) , k tomu jméno
> a kontakty

office=construction je víc používané než company=construction a víc odpovídá 
ostatním office:
https://taginfo.openstreetmap.org/tags/office=construction
https://taginfo.openstreetmap.org/tags/company=construction

> obalovna/betonárka
> landuse=industrial & industrial=?? / man_made=plant &
> product=concrete/asphalt a k tomu jméno a kontakty

man_made=plant nevidím dokumentované ani používané (jen 1 uzel). Existuje 
man_made=works, ale to je spíš pro budovy. IMO pokud je to velký areál, který 
obsahuje několik různých částí (zásobníky, míchací věže, skládky), tak dává 
smysl to označit landuse. Nejspíš landuse=industrial industrial=factory 
product=asphalt|concrete.

> stavební dvůr, tj. skládkové plochy + plochy pro mechanizaci
> jen landuse=industrial a jméno

landuse=industrial industrial=construction?

> strojírenská firma
> landuse=industrial & industrial=machine_shop / man_made=plant =??
> a jméno + kontakty

To první nebo jiný industrial=*.

> logistické centrum
> landuse=commercial + jméno + kontakty

landuse=industrial industrial=warehouse|port|storage (pobočky, kam mohou 
zákazníci: office=logistics), případně kombinovat s cargo.

Sten

signature.asc
Description: This is a digitally signed message part.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione Volker Schmidt
Scusa, hai ragione, non avo risposto.
Che cosa intendi con "concatenare relazioni" ?

On Thu, 7 May 2020 at 22:45, aldoct  wrote:

> Domanda 1 = A posto!
> Domanda 2 Come fare a concatenare le relazioni?
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione Martin Koppenhoefer


sent from a phone

> On 7. May 2020, at 22:45, aldoct  wrote:
> 
> Domanda 2 Come fare a concatenare le relazioni?


mettendo relazioni come membri in altre relazioni...

https://wiki.openstreetmap.org/wiki/Super-Relation

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


Re: [OSM-talk-fr] Moulinette pour lire EXIF, générer GPX, et préremplir dans JOSM?

2020-05-07 Per discussione Vincent de Château-Thierry

> De: "Shohreh" 
> 
> Oui, mais y a-t-il un moyen de pré-ajouter des nodes pour réduire un
> peu le boulot ?

Ca ne réduit pas le boulot je pense. Si tu sous-entends que c'est à JOSM de les 
ajouter pour toi, d'une je ne connais pas la fonction magique pour faire ça, et 
de deux j'espère que ton coup d'oeil pour choisir l'endroit du node shop=* a 
plus de valeur que le résultat d'un algorithme, dont je ne vois pas trop sur 
quoi il s'appuierait pour ajouter un node à un endroit pertinent. Ajouter un 
node, c'est juste un double-clic, je pense que chercher à l'optimiser va 
surtout te faire perdre du temps.
Plus généralement, ajouter des infos dans OSM suite à une collecte terrain, 
c'est pas du travail mécanique, c'est vraiment à voir comme du jardinage : 
c'est manuel, subjectif, avec tes partis-pris, ton jus de cerveau, et ta 
mémoire des lieux visités...

vincent

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


[talk-cz] Značení firem

2020-05-07 Per discussione majka
Zdravím všechny, a jsem tu s dotazem. Poslední dobou narážím na to, že se
(zejména) noví uživatelé snaží na mapu dostat firmu. A téměř vždy to končí
prostým strčením do name u budovy, případně všech budov na pozemku, v
horším případě i včetně popisu toho, co ta firma dělá/nabízí.
Osobně jsem se doteď vyhýbala tomu, firmy do OSM dávat. Po projetí wiki se
mi potvrdilo, že ten můj původní důvod trvá :) Je v tom totiž docela
bordel, a podle mě se s tím zatím vůbec nepočítá.

Může někdo dát pár příkladů, jak by se to mělo udělat?

Pár konkrétních případů a přidáno jak by to mohlo vypadat:

Velká stavební firma:
Centrála, závody - office=company & company=construction nebo
nezdokumentované office=construction (viz debata u klíčů
) , k tomu jméno
a kontakty

obalovna/betonárka
landuse=industrial & industrial=?? / man_made=plant &
product=concrete/asphalt a k tomu jméno a kontakty

stavební dvůr, tj. skládkové plochy + plochy pro mechanizaci
jen landuse=industrial a jméno

strojírenská firma
landuse=industrial & industrial=machine_shop / man_made=plant =??
a jméno + kontakty

logistické centrum
landuse=commercial + jméno + kontakty

A u landuse+man_made variant dávat obojí? Ani jedno z toho, a dát to nějak
jinak?

Zvykově bych to nacpala do landuse, i když je to v důsledku nesmysl (firma
jako landuse).

Ideálně bychom se na něčem domluvili a dalo by se to na wiki, abychom tam
případné uživatele mohli odkázat.

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


Re: [OSM-talk-fr] Moulinette pour lire EXIF, générer GPX, et préremplir dans JOSM?

2020-05-07 Per discussione Shohreh
Oui, mais y a-t-il un moyen de pré-ajouter des nodes pour réduire un peu le
boulot ?



--
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: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione aldoct
Domanda 1 = A posto!
Domanda 2 Come fare a concatenare le relazioni?



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

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


Re: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione Volker Schmidt
Per cercare e controllare per completezza delle relazioni c'è il sito Relation
Analyzer 
che fra altre cose ti permette cercare per nome/parte di nome e/o ref e/o
altri tag.
Ho fatto una rapida verifica. RA ti fa vedere 44 relazioni con "sentiero
Italia" nel nome

On Thu, 7 May 2020 at 22:32, Ivo Reano  wrote:

> Interessanti domande.
> Nello specifico ti dovrà rispondere AlfredoSP che ha curato per il CAI
> tutto il percorso.
> Il SI 2019 è stato suddiviso in tratti regionali.
> Per il Piemonte è la relazione 7029511, che è la tratta SI00
> Si tratta di una super relazione, nel senso che è composta da relazioni di
> percorsi.
>
> In realtà non saprei rispondere alle domande, però provo a dire come
> faccio io.
> Posso aprire Josm su una zona dove so che passa il percorso e lo trovo
> nella lista delle relazioni
> Oppure più facilmente da waymarkedtrails, però devi posizionarti su un
> territorio dove passa!
> Alla domanda due provo a risponderti, non garantisco sia la risposta più
> corretta.
> Una tratta è in relazione con la successiva perché è all'interno di una
> relazione padre.
> Probabilmente non esiste ancora una super super relazione con tutto il
> Sentiero Italia CAI 2019.
> Ma dacci il tempo e lo faremo!
> Ivo/Jrachi
>
> Il giorno gio 7 mag 2020 alle ore 21:54 aldoct  ha
> scritto:
>
>> Domanda 1: Come fare una ricerca di una relazione? Mettiamo che voglio
>> sapere, ad esempio, se esiste qualche relazione che riguarda il Sentiero
>> Italia o un suo tratto regionale; come faccio a saperlo?
>> Domanda 2: Come si fà a concatenare le relazioni fra di loro? Se creo una
>> relazione su una singola tappa del Sentiero Italia, come faccio a metterla
>> in relazione alla tappa successiva?
>> Saluti
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione Ivo Reano
Pardon! Ho parlato senza guardare più in largo :)
Relazione: Sentiero Italia (1021025)
Comprende tutto.

Il giorno gio 7 mag 2020 alle ore 22:31 Ivo Reano  ha
scritto:

> Interessanti domande.
> Nello specifico ti dovrà rispondere AlfredoSP che ha curato per il CAI
> tutto il percorso.
> Il SI 2019 è stato suddiviso in tratti regionali.
> Per il Piemonte è la relazione 7029511, che è la tratta SI00
> Si tratta di una super relazione, nel senso che è composta da relazioni di
> percorsi.
>
> In realtà non saprei rispondere alle domande, però provo a dire come
> faccio io.
> Posso aprire Josm su una zona dove so che passa il percorso e lo trovo
> nella lista delle relazioni
> Oppure più facilmente da waymarkedtrails, però devi posizionarti su un
> territorio dove passa!
> Alla domanda due provo a risponderti, non garantisco sia la risposta più
> corretta.
> Una tratta è in relazione con la successiva perché è all'interno di una
> relazione padre.
> Probabilmente non esiste ancora una super super relazione con tutto il
> Sentiero Italia CAI 2019.
> Ma dacci il tempo e lo faremo!
> Ivo/Jrachi
>
> Il giorno gio 7 mag 2020 alle ore 21:54 aldoct  ha
> scritto:
>
>> Domanda 1: Come fare una ricerca di una relazione? Mettiamo che voglio
>> sapere, ad esempio, se esiste qualche relazione che riguarda il Sentiero
>> Italia o un suo tratto regionale; come faccio a saperlo?
>> Domanda 2: Come si fà a concatenare le relazioni fra di loro? Se creo una
>> relazione su una singola tappa del Sentiero Italia, come faccio a metterla
>> in relazione alla tappa successiva?
>> Saluti
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione Ivo Reano
Interessanti domande.
Nello specifico ti dovrà rispondere AlfredoSP che ha curato per il CAI
tutto il percorso.
Il SI 2019 è stato suddiviso in tratti regionali.
Per il Piemonte è la relazione 7029511, che è la tratta SI00
Si tratta di una super relazione, nel senso che è composta da relazioni di
percorsi.

In realtà non saprei rispondere alle domande, però provo a dire come faccio
io.
Posso aprire Josm su una zona dove so che passa il percorso e lo trovo
nella lista delle relazioni
Oppure più facilmente da waymarkedtrails, però devi posizionarti su un
territorio dove passa!
Alla domanda due provo a risponderti, non garantisco sia la risposta più
corretta.
Una tratta è in relazione con la successiva perché è all'interno di una
relazione padre.
Probabilmente non esiste ancora una super super relazione con tutto il
Sentiero Italia CAI 2019.
Ma dacci il tempo e lo faremo!
Ivo/Jrachi

Il giorno gio 7 mag 2020 alle ore 21:54 aldoct  ha
scritto:

> Domanda 1: Come fare una ricerca di una relazione? Mettiamo che voglio
> sapere, ad esempio, se esiste qualche relazione che riguarda il Sentiero
> Italia o un suo tratto regionale; come faccio a saperlo?
> Domanda 2: Come si fà a concatenare le relazioni fra di loro? Se creo una
> relazione su una singola tappa del Sentiero Italia, come faccio a metterla
> in relazione alla tappa successiva?
> Saluti
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Nomi delle vie

2020-05-07 Per discussione Luigi Scuotto
Riguardo i nomi delle stra ho trovato un documento del comune di bergamo
magari puoservire
https://www.indicenormativa.it/sites/default/files/2018-10/110_TOPONOMASTICA__163_3272.pdf


Il giorno mer 6 mag 2020 alle ore 10:53 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> Am Mi., 6. Mai 2020 um 07:14 Uhr schrieb Francesco Ansanelli <
> franci...@gmail.com>:
>
>> Ciao Martin,
>>
>> penso che dipenda dai comuni, come per Camillo Benso che è scritto in
>> tutte le varianti.
>> Appoggio l'idea di scrivere "von" in minuscolo in ogni caso, come per la
>> famiglia d'Azeglio.
>>
>>
>
> sì, al meno per l' "official_name" il nome dovrebbe essere esattamente
> quello che è stato deliberato dal consiglio comunale.
> Invece per "name" penso dovremmo usare i nomi secondo le regole OSM
>
> Fonti del Wiki:
>
> 1.
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> (purtroppo non c'è la pagina in italiano). Per me questa regola dice di
> usare il nome completo (Johann W) perché senza Johann sarebbe
> un'abbreviazione.
>
>
> 2.
> Questa pagina sarebbe presente in italiano, ma non cita il paragrafo che
> ci interessa:
> https://wiki.openstreetmap.org/wiki/Key:name#Road_names
>
> "Road names, especially highway names, may commemorate individuals."
> (Bene, è il nostro caso. Male, che non dice niente però). . "Use the
> name=* tag if the name is suitable for general usage (such as for
> navigation); otherwise, use the official_name
> =* or alt_name
> =* tag."  -> in questo
> caso direi che "Via Goethe" andrebbe bene per uso comune (come la
> navigazione) quindi per "name", e nel caso che il nome ufficiale fosse "Via
> Wolfgang von Goethe", la versione completa dovrebbe andare in "alt_name"
> secondo questa regola.
>
>
> 3.
> Sono andato anche qui:
> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
>
> - "l nome dell'area di circolazione *NON* si scrive tutto in maiuscolo ma
> seguendo le regole della lingua italiana"  -> su questo non sono del tutto
> d'accordo, penso si dovrebbe scrivere come da delibera, e se ci fossero
> errori nella delibera sarebbe comunque così. Questo al meno per
> "official_name"
>
> - "*Non si usano abbreviazioni.*" -> questo conferma la versione estesa
>
> - la pagina conferma anche il minuscolo del "von" in quanto siamo prima
> del XIX secolo (al proposito: nascita o morte?)
>
> - "Le aree di circolazione intitolate a personaggi storici o contemporanei
> devono contenere prima l’indicazione di eventuali titoli onorifici,
> religiosi, nobiliari o qualifiche professionali (se presenti), poi il nome
> ed in seguito il cognome (es. Via Maresciallo Luigi Cadorna, Via Don
> Giovanni Minzoni, Via Papa Pio Dodicesimo). I titoli nobiliari (re,
> principe, duca, marchese, conte, visconte e barone) se accompagnati dal
> nome del casato devono essere posti dopo il nome e cognome (es. Via Camillo
> Benso Conte di Cavour, Piazza Emanuele Filiberto di Savoia Duca d'Aosta).
> Appellativi e titoli sono scritti con l'iniziale maiuscola (detta *maiuscola
> di rispetto* o *reverenziale*)."
> quindi "Freiherr Johann Wolfgang von Goethe"? Oppure "Grossherzoglicher
> Staatsminister Freiherr Johann Wolfgang von Goethe"? Forse sarebbe da
> tradurre "Großherzoglicher Staatsminister" (ministro granducale)? Forse
> anche "Freiherr" (barone)?
>
>
> Ciao
> Martin
>
>
>
> ___
> 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] Moulinette pour lire EXIF, générer GPX, et préremplir dans JOSM?

2020-05-07 Per discussione Frédéric Rodrigo

Le 07/05/2020 à 22:00, Shohreh a écrit :

Bonjour,

J'ai pris pas mal photos de commerces dans un coin. Les photos sont toutes
géotaggées et assez correctement pusique je loggais le parcours.

Pour me simplifier un peu la vie, je pensais à une moulinette du genre :
1. Lire tous les JPG du répertoire
2. Extraire les coords GPS de EXIF
3. Ajouter à un GPX, en incluant lien vers le JPG
4. Ouvrir le GPX dans JOSM, qui va ajouter les photos sur la carte
5. Pour élément photo, JOSM va ajouter un node "shop" vide
6. Manuellement, je vais compléter chaque node (shop=truc, name=machin,
address=bidule)
7. Une fois tous les commerces traités, j'uploade.

Est-ce la bonne façon de procéder ? Y a-t-il un script dispo, sous Windows
voire Linux ?

Merci.



Tu peux simplement ouvrir les JPEG dans JOSM. Il utilise les coordonnées 
pour placer les images et .. c'est tout.




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


[OSM-talk-fr] Moulinette pour lire EXIF, générer GPX, et préremplir dans JOSM?

2020-05-07 Per discussione Shohreh
Bonjour,

J'ai pris pas mal photos de commerces dans un coin. Les photos sont toutes
géotaggées et assez correctement pusique je loggais le parcours.

Pour me simplifier un peu la vie, je pensais à une moulinette du genre :
1. Lire tous les JPG du répertoire
2. Extraire les coords GPS de EXIF
3. Ajouter à un GPX, en incluant lien vers le JPG
4. Ouvrir le GPX dans JOSM, qui va ajouter les photos sur la carte
5. Pour élément photo, JOSM va ajouter un node "shop" vide
6. Manuellement, je vais compléter chaque node (shop=truc, name=machin,
address=bidule)
7. Une fois tous les commerces traités, j'uploade.

Est-ce la bonne façon de procéder ? Y a-t-il un script dispo, sous Windows
voire Linux ?

Merci.



--
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-it] Un paio di questioni riguardanti le relazioni

2020-05-07 Per discussione aldoct
Domanda 1: Come fare una ricerca di una relazione? Mettiamo che voglio
sapere, ad esempio, se esiste qualche relazione che riguarda il Sentiero
Italia o un suo tratto regionale; come faccio a saperlo?
Domanda 2: Come si fà a concatenare le relazioni fra di loro? Se creo una
relazione su una singola tappa del Sentiero Italia, come faccio a metterla
in relazione alla tappa successiva?
Saluti 



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

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


Re: [Talk-lt] Nuotoliniai JOSM, QGIS susitikimai

2020-05-07 Per discussione Nerijus Baliūnas
On Thu, 7 May 2020 20:10:21 +0300 Nerijus Baliūnas 
 wrote:

> Pasirodo būtinai reikia turėti kamerą.

Be kameros kaip ir atrodo, kad leidžia prisijungti, rašo:
Ruošiama...
Netrukus galėsite prisijungti

bet nieko nevyksta.

Nerijus

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


[Talk-cat] Las Calles de las Mujeres

2020-05-07 Per discussione Lanxana .
Bona tarda!

aquest cap de setmana ens hem proposat pujar Madrid al projecte de "Las
Calles de las Mujeres", per aquest motiu es farà un hackató dissabte amb
unes breus presentacions del projecte, dades i viquipedia i la invitació a
tothom a ajudar a filtrar els carrers.

Si us animeu, us podeu apuntar aquí: http://meetu.ps/e/HZl0s/wwHdH/d

L'enllaç a l'event s'enviarà als inscrits, la plataforma serà jitsi dins de
riot.

Tenim algunes altres ciutats pendents d'acabar de processar i pujar, i
properament està previst fer-ho amb Sevilla i València, que té més
complexitat lingüística al nomenclàtor.

Us esperem!


Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat


[Talk-es] Las calles de las Mujeres en Madrid

2020-05-07 Per discussione Lanxana .
Buenas tardes!

para este fin de semana nos hemos propuesto subir Madrid al proyecto de
"Las Calles de las Mujeres". Se quería hacer un evento presencial, al
estilo del que se hizo con Zaragoza, pero dada la situación actual, lo
vamos a hacer virtual.

Os invito a uniros y descubrir juntos cuántas calles tienen nombre de mujer
en Madrid. Os podéis inscribir en este meetup:
http://meetu.ps/e/HZl0s/wwHdH/d

Tenemos algunas ciudades más en el tintero, que se empezaron a procesar y
hay que revisar, y la vista puesta en Sevilla y Valencia, para próximos
eventos.

Saludos y a cuidarse!


Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-07 Per discussione Jérôme Amagat
C'est pas facile pour le rendu, exemple l'île de Sein :
rendu osm : https://www.openstreetmap.org/#map=14/48.0367/-4.8522
rendu osm fr :
http://tile.openstreetmap.fr/?zoom=14=48.0373=-4.85245=B000
vue aérienne sur le geoportail :
https://www.geoportail.gouv.fr/carte?c=-4.852870844451901,48.03364219188839=14=ORTHOIMAGERY.ORTHOPHOTOS::GEOPORTAIL:OGC:WMTS(1)=yes

J'en profite pour signalé qu'il y a un problème sur le rendu fr, ça fait
maintenant un bon moment que la Gironde est asséché :
http://tile.openstreetmap.fr/?zoom=10=45.32095=-0.73387=B000FFF
La mise à jour du bleu de l'océan ne se fait pas.
(ça permet de dire à ceux qui ne le savent pas que ce bleu, placé grâce aux
natural=coastline n'est pas mis à jour aussi souvent que le reste sur le
rendu osm et donc que, après avoir modifié la ligne de côte, ça peut
prendre plusieurs jours voir semaine à être mis à jour.)

Autre chose, je signale que le Golfe de Gascogne, la Manche et d'autres ont
disparu du rendu à faible zoom car les grandes relations qui existaient
auparavant ont été remplacé par un node...
ces grandes relations ne plaisent pas à certains, les raisons évoquées sont
: trop grande, difficile a maintenir et la limite d'un golfe, d'une mer ...
sont approximatives.
Leur solution c'est de les remplacer par un node.
par exemples la Manche :
https://www.openstreetmap.org/node/7367542816
Maintenant il faut zoomé au bon endroit pour le voir sur le rendu et je
vois pas comment ce node pourrait être utile pour quoi que ce soit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-07 Per discussione Eric SIBERT

Le 07/05/2020 à 13:54, Djo_man via Talk-fr a écrit :
J'aimerais bien et j'y pense depuis un bout de temps car effectivement 
le wiki lui-même (coastline, Beach, bare_rock, mud, tidal, tidalflat, 
frontieres marines, shoal, etc) manque de ces images. Mais il va falloir 
s'y coller car ce n'est pas si simple...


S'il vous plaît... dessine-moi une mangrove...

;-)

Mes 0,02 €

Eric

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


Re: [Talk-it] Problems near Trieste

2020-05-07 Per discussione Cascafico Giovanni
Hello Andy and thanks for your interest.

Unfortunately, some local mappers already patched the damages. This morning
I posted a message [1] in regional ML (talk-it-fvg) in order to evaluate
the amount of corrections already done and to choose the best approach
(between the four you listed).

Purtroppo alcuni mappatori ci hanno già messo una pezza. Stamane ho mandato
un messaggio [1] nella lista regionale (talk-it-fvg) per valutare quante
correzioni sono già state fatte e scegliere la migliore soluzione (tra le
quattro che hai elencato).

[1]
https://lists.openstreetmap.org/pipermail/talk-it-fvg/2020-May/001681.html

Il giorno gio 7 mag 2020 alle ore 16:51 Andy Townsend 
ha scritto:

> (apologies for English - rough Italian translation follows)
>
> Hello,
>
> At the Data Working Group we've had a number of complaints about some
> edits near Trieste - see
> http://resultmaps.neis-one.org/osm-discussion-comments?uid=10474167 and
> https://www.openstreetmap.org/user_blocks/3675 .
>
> They were asked, in a previous block, to engage with other mappers and
> discuss their differences with them.  That never happened, and as it's been
> a few days now with no reply we'll need to think about tidying up the
> data.  A typical complaint about this mapper is something like "Many
> inventions of absolutely non-existent objects", but is the best approach to:
>
>- revert everything they've done that hasn't since been edited by
>other mappers
>- revert everything they've done that hasn't since been edited by
>other mappers, but only after a certain date (and if so what date)?
>- revert only certain changesets (and if so which ones)
>- revert nothing, and let local mappers fix anything that they haven't
>already fixed?
>
> As we've had lots of different complaints about this user I thought that
> it made sense to ask here for other people's opinions too.
>
> Best Regards,
>
> Andy, from the Data Working Group.
>
>
> (traduzione approssimativa)
>
> Ciao,
>
> Al Data Working Group abbiamo avuto una serie di lamentele su alcune
> modifiche nei pressi di Trieste - vedi
> http://resultmaps.neis-one.org/osm-discussion-comments?uid=10474167 e
> https: //www.openstreetmap. org / user_blocks / 3675.
>
> È stato chiesto, in un blocco precedente, di interagire con altri
> mappatori e discutere le loro differenze con loro. Ciò non è mai accaduto e
> dato che sono passati alcuni giorni senza risposta, dovremo pensare di
> mettere in ordine i dati. Una lamentela tipica di questo mappatore è
> qualcosa come "Molte invenzioni di oggetti assolutamente inesistenti", ma è
> l'approccio migliore a:
>
>
>- ripristina tutto ciò che hanno fatto che da allora non è stato
>modificato da altri mappatori
>- ripristinare tutto quello che hanno fatto che non è stato modificato
>da altri mappatori, ma solo dopo una certa data (e se sì, quale data)?
>- ripristina solo alcuni changeset (e in tal caso quali)
>- non ripristinare nulla e lasciare che i mapper locali riparino
>qualcosa che non hanno già risolto?
>
>
> Dato che abbiamo avuto molte diverse lamentele su questo utente, ho
> pensato che fosse logico chiedere anche qui le opinioni degli altri.
>
> I migliori saluti,
>
> Andy, dal gruppo di lavoro sui dati.
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-lt] Nuotoliniai JOSM, QGIS susitikimai

2020-05-07 Per discussione Nerijus Baliūnas
On Thu, 7 May 2020 20:05:55 +0300 Nerijus Baliūnas 
 wrote:

> Kažkaip nieko nevyksta.

Pasirodo būtinai reikia turėti kamerą.

Nerijus

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


Re: [Talk-lt] Nuotoliniai JOSM, QGIS susitikimai

2020-05-07 Per discussione Nerijus Baliūnas
On Wed, 6 May 2020 19:02:15 +0300 Tomas Straupis  
wrote:

> Sveiki
> 
>   Taigi rytoj, ketvirtadienį, 2020-05-07 20:00 su bokalu rankoj
> pakalbėsim apie JOSM.
>   Google meet nuoroda:
>   https://meet.google.com/gbs-wrtg-ewy
> 
> P.S. Vis dar galite parašyti, jei norite sužinoti apie kažkokius
> specifinius dalykus.

Kažkaip nieko nevyksta.

Nerijus

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


Re: [Talk-us] How to map snowmobile trails in US?

2020-05-07 Per discussione Joseph Eisenberg
Winter-only snowmobile routes are mapped if they are signed. Create a route
relation with type=route + route=snowmobile (used 141 times) - see
https://wiki.openstreetmap.org/wiki/Tag%3Aroute%3Dsnowmobile

Please only use highway=track when there is an forestry or agricultural
road / track which is passable by 2-track vehicles such as farm tractors,
logging trucks, or 4wd cars.

-- Joseph Eisenberg

(You might try the Tagging mailing list for questions about how to tag
something: tagg...@openstreetmap.org)

On Thu, May 7, 2020 at 8:43 AM Kevin Broderick 
wrote:

> Ideally, I'd say that most snowmobile routes should be relations, not
> ways. At least in the places I'm familiar with (New England and Montana), a
> significant portion of the snowmobile trail network overlaps with seasonal
> roads that are open to wheeled traffic in some conditions. Having the
> summer ground truth mapped accurately is hugely helpful if you're poking
> around in the summer, whether it be hiking, biking, riding an on/off-road
> motorcycle, etc; as you noted, some snowmachine trails are virtually
> invisible in the summer and may even be impassable (I'm familiar with some
> spots in Vermont where the snowmachine trails transit across swamp or
> marshland once it's frozen—not something you want to try to cross on foot
> or wheeled vehicle).
>
> Around here, there's also the side issue of someone having mapped one of
> the ITS routes as a track for a long distance, when it actually should be a
> series of ways with different data, as some parts are well-maintained
> gravel roads in the summer, others are less-well-maintained, some are
> public ways and others aren't.
>
> To answer the question about sections that specifically cross fields: I'd
> still be tempted to tag that as highway=track, with appropriate access and
> surface tags. I'm not sure it's the best way to do it, but I can't come up
> with a better way, and the track in question would likely be passable with
> permission and the right vehicle.
>
> As for sections that cross [frozen] marshes, or other areas that aren't
> passable when the ground is thawed, I don't know. Maybe there is a use case
> for "highway=frozen" or something similar, as ice_road is applied to
> another way, and none of the highway= values with which  I'm familiar would
> make sense.
>
> On Thu, May 7, 2020 at 10:41 AM Bob Gambrel  wrote:
>
>> Am newby to talk-us. This may have been discussed in the past but not
>> handy with searching archives yet.
>>
>> In Minnesota I have seen snowmobile trails mapped in OSM as follows:
>>
>> highway=track
>> snowmobile=designated
>> surface=unpaved
>>
>> In both aerial photos and observation on the ground, there is almost
>> always no track visible. In the winter, with snow cover, the location of
>> the track is visible because it is compacted by snowmobiles. In the spring
>> there might be some evidence in areas with grasses that would have been
>> tamped down by the snowmobiles.
>>
>> Question: Is this the right way to map snowmobile trails? The thing that
>> concerns me, of course, is the use of "track" because of it is not apparent
>> most of the time.
>>
>> Another question: is there a forum or expert group or something that
>> discusses this? I would like to join that conversation if there is  one
>> going on.
>>
>> I think it is a good idea to map these trails. It seems there maybe
>> should be another type of highway? Something like: "not visible on the
>> ground most of the year". Note that ice_road=yes is not appropriate here
>> (in most cases) as (in most cases) these trails are not on frozen water
>> bodies.
>>
>> As further info, where I was able to observe there are a number of signs
>> posted such as stop signs, caution signs, etc. So there clearly is
>> government involvement.
>>
>> Any thoughts?
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] How to map snowmobile trails in US?

2020-05-07 Per discussione Kevin Broderick
Ideally, I'd say that most snowmobile routes should be relations, not ways.
At least in the places I'm familiar with (New England and Montana), a
significant portion of the snowmobile trail network overlaps with seasonal
roads that are open to wheeled traffic in some conditions. Having the
summer ground truth mapped accurately is hugely helpful if you're poking
around in the summer, whether it be hiking, biking, riding an on/off-road
motorcycle, etc; as you noted, some snowmachine trails are virtually
invisible in the summer and may even be impassable (I'm familiar with some
spots in Vermont where the snowmachine trails transit across swamp or
marshland once it's frozen—not something you want to try to cross on foot
or wheeled vehicle).

Around here, there's also the side issue of someone having mapped one of
the ITS routes as a track for a long distance, when it actually should be a
series of ways with different data, as some parts are well-maintained
gravel roads in the summer, others are less-well-maintained, some are
public ways and others aren't.

To answer the question about sections that specifically cross fields: I'd
still be tempted to tag that as highway=track, with appropriate access and
surface tags. I'm not sure it's the best way to do it, but I can't come up
with a better way, and the track in question would likely be passable with
permission and the right vehicle.

As for sections that cross [frozen] marshes, or other areas that aren't
passable when the ground is thawed, I don't know. Maybe there is a use case
for "highway=frozen" or something similar, as ice_road is applied to
another way, and none of the highway= values with which  I'm familiar would
make sense.

On Thu, May 7, 2020 at 10:41 AM Bob Gambrel  wrote:

> Am newby to talk-us. This may have been discussed in the past but not
> handy with searching archives yet.
>
> In Minnesota I have seen snowmobile trails mapped in OSM as follows:
>
> highway=track
> snowmobile=designated
> surface=unpaved
>
> In both aerial photos and observation on the ground, there is almost
> always no track visible. In the winter, with snow cover, the location of
> the track is visible because it is compacted by snowmobiles. In the spring
> there might be some evidence in areas with grasses that would have been
> tamped down by the snowmobiles.
>
> Question: Is this the right way to map snowmobile trails? The thing that
> concerns me, of course, is the use of "track" because of it is not apparent
> most of the time.
>
> Another question: is there a forum or expert group or something that
> discusses this? I would like to join that conversation if there is  one
> going on.
>
> I think it is a good idea to map these trails. It seems there maybe should
> be another type of highway? Something like: "not visible on the ground most
> of the year". Note that ice_road=yes is not appropriate here (in most
> cases) as (in most cases) these trails are not on frozen water bodies.
>
> As further info, where I was able to observe there are a number of signs
> posted such as stop signs, caution signs, etc. So there clearly is
> government involvement.
>
> Any thoughts?
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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


[Talk-it] Problems near Trieste

2020-05-07 Per discussione Andy Townsend

(apologies for English - rough Italian translation follows)

Hello,

At the Data Working Group we've had a number of complaints about some 
edits near Trieste - see 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=10474167 and 
https://www.openstreetmap.org/user_blocks/3675 .


They were asked, in a previous block, to engage with other mappers and 
discuss their differences with them.  That never happened, and as it's 
been a few days now with no reply we'll need to think about tidying up 
the data.  A typical complaint about this mapper is something like "Many 
inventions of absolutely non-existent objects", but is the best approach to:


 * revert everything they've done that hasn't since been edited by
   other mappers
 * revert everything they've done that hasn't since been edited by
   other mappers, but only after a certain date (and if so what date)?
 * revert only certain changesets (and if so which ones)
 * revert nothing, and let local mappers fix anything that they haven't
   already fixed?

As we've had lots of different complaints about this user I thought that 
it made sense to ask here for other people's opinions too.


Best Regards,

Andy, from the Data Working Group.


(traduzione approssimativa)

Ciao,

Al Data Working Group abbiamo avuto una serie di lamentele su alcune 
modifiche nei pressi di Trieste - vedi 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=10474167 e 
https: //www.openstreetmap. org / user_blocks / 3675.


È stato chiesto, in un blocco precedente, di interagire con altri 
mappatori e discutere le loro differenze con loro. Ciò non è mai 
accaduto e dato che sono passati alcuni giorni senza risposta, dovremo 
pensare di mettere in ordine i dati. Una lamentela tipica di questo 
mappatore è qualcosa come "Molte invenzioni di oggetti assolutamente 
inesistenti", ma è l'approccio migliore a:


 * ripristina tutto ciò che hanno fatto che da allora non è stato
   modificato da altri mappatori
 * ripristinare tutto quello che hanno fatto che non è stato modificato
   da altri mappatori, ma solo dopo una certa data (e se sì, quale data)?
 * ripristina solo alcuni changeset (e in tal caso quali)
 * non ripristinare nulla e lasciare che i mapper locali riparino
   qualcosa che non hanno già risolto?


Dato che abbiamo avuto molte diverse lamentele su questo utente, ho 
pensato che fosse logico chiedere anche qui le opinioni degli altri.


I migliori saluti,

Andy, dal gruppo di lavoro sui dati.


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


[Talk-us] How to map snowmobile trails in US?

2020-05-07 Per discussione Bob Gambrel
Am newby to talk-us. This may have been discussed in the past but not handy
with searching archives yet.

In Minnesota I have seen snowmobile trails mapped in OSM as follows:

highway=track
snowmobile=designated
surface=unpaved

In both aerial photos and observation on the ground, there is almost always
no track visible. In the winter, with snow cover, the location of the track
is visible because it is compacted by snowmobiles. In the spring there
might be some evidence in areas with grasses that would have been tamped
down by the snowmobiles.

Question: Is this the right way to map snowmobile trails? The thing that
concerns me, of course, is the use of "track" because of it is not apparent
most of the time.

Another question: is there a forum or expert group or something that
discusses this? I would like to join that conversation if there is  one
going on.

I think it is a good idea to map these trails. It seems there maybe should
be another type of highway? Something like: "not visible on the ground most
of the year". Note that ice_road=yes is not appropriate here (in most
cases) as (in most cases) these trails are not on frozen water bodies.

As further info, where I was able to observe there are a number of signs
posted such as stop signs, caution signs, etc. So there clearly is
government involvement.

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


[OSRM-talk] Need help writing a lua script for public transit (bus)

2020-05-07 Per discussione simone zanda


Hi there

I trying to figure out more about the .lua scripts in order to create a profile 
that would create sensible approximations of bus routes.
I know that many public transit routes are modelled as relations in osm.

Can  someone help me?



Tanks

Simone
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Axel Listes
Le 07/05/2020 à 12:17, Florimond Berthoux a écrit :
> Je crois que ce que tu souhaites Axel c'est de répliquer le site
> https://carte.velo-iledefrance.fr pour ta métropole et faire un
> https://carte.trifouilly-les-oies-avelo.fr ?

Oui Florimond c'est exactement cela !
Merci pour ton retour, je vais tester cela en fin d’après midi.

À plus.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

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


Re: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Niels Elgaard Larsen
Michael Andersen:
> Der er en del parkeringskældre i OSM, der kun tillader køretøjer op til 1,9 
> m. Og så
> er der https://www.openstreetmap.org/node/5030243561 ;-)


Ja, jeg satte den bare til 2 meter fordi jeg ved at jeg kan kigge over den og 
jeg er
mindre en 2 meter. Så to meter var på den sikre side.

Nu har jeg checket, og den er faktisk kun lidt under 1.5 meter høj.


Så jeg havde fået en unødig advarsel ved Rema1000 der. Men hellere en for meget 
end
en for lidt.

Så det viser jo bare at biler ikke skal være så store igen før man skal holde 
øje med
højden.

> 
> Mvh Hjart
> 
>  
> 
> torsdag den 7. maj 2020 13.48.34 CEST skrev Niels Elgaard Larsen:
> 
>> Michael Andersen:
> 
>> > Ihvertfald i Osmand kan man taste højden på sit køretøj ind, men hvem
> 
>> > kender den og
> 
>> >
> 
>> > tænker på taste det ind inden man kører?
> 
>>
> 
>> Man skal jo kun taste det ind når man kører i en ny bil.
> 
>> Og hvis man nu kører i to lastbiler, der ikke var helt lige høje, så kunne
> 
>> man jo taste højden for den laveste ind,
> 
>> Og i Osmand kan man lave flere "driving" profiler, så man har en for hver
> 
>> lastbil.
> 
>>
> 
>> Hvis jeg kørte rundt i en lastbil, der var omkring 3 meter høj, så ville jeg
> 
>> helt sikkert taste højden for min lastbil ind i Osmand.
> 
>>
> 
>> Hvis man ikke ved hvor høj ens bil er, så hjælper skiltningen jo heller
> 
>> ikke.
> 
>>
> 
>> Faktisk har jeg engang sat højden til 2 meter for min bil (hvilket er
> 
>> rigeligt). Men det var nok mest fordi jeg undersøgte, hvad Osmand kunne.
> 
>>
> 
>> Og der findes næppe nogen broer, parkeringskældre, færger osv, der er for
> 
>> lave til min bil.
> 
>>
> 
>> Desuden så sidder jeg jo med øjnene næsten oppe under taget på min lille
> 
>> bil, så jeg kunne nok godt på øjemål vurdere om den gik.
> 
>>
> 
>> Men hvis lastbilen er dobbelt så høj, som førerhuset, så er det svært.
> 
>  
> 
>  
> 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
> 


-- 
Niels Elgaard Larsen

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


[OSM-talk-fr] Schéma pour le marnage

2020-05-07 Per discussione Yves P.
Quelques liens en vrac pour aider les terriens :)

https://fr.wikipedia.org/wiki/Marnage_(mar%C3%A9e) 


http://www.actunautique.com/2019/06/comprendre-une-carte-marine-les-sondes-couleurs-et-fonds.html
 

• la couleur blanche indique les grandes profondeurs,
• le bleu, indique les faibles profondeurs (0 à 10 m de profondeur). Plus le 
bleu est foncé, moins il y a d’eau,
• le vert montre l’estran (bande de côte couverte à marée haute et découverte à 
marée basse);

http://www.glossaire-eau.fr/concept/estran
https://envlit.ifremer.fr/region/basse_normandie/milieu/milieux_marins/le_marnage
 

https://www.ouest-france.fr/normandie/grandes-marees-hauteur-deau-marnage-et-coefficient-3199287
 

http://www.icem-freinet.net/~btj/520maree/maree08.htm 

https://sarasvatiweb.wordpress.com/2016/10/22/estran/

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


Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

2020-05-07 Per discussione stevea
On May 7, 2020, at 5:32 AM, Clifford Snow  wrote:
> Steve,
> I don't have the patience to put up with discussions about admin levels. As 
> you know they can drag on forever. I did post a link to the discussion on the 
> Connecticut Slack channel. Maybe that will get more people involved.
> 
> Good luck,
> Clifford

I appreciate the Slack post, I appreciate your wish for good luck, I appreciate 
you reminding us that patience can quickly wear thin regarding OSM admin_level 
discussions.  Indeed, they can frequently use good luck.

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


Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

2020-05-07 Per discussione Clifford Snow
Steve,
I don't have the patience to put up with discussions about admin levels. As
you know they can drag on forever. I did post a link to the discussion on
the Connecticut Slack channel. Maybe that will get more people involved.

Good luck,
Clifford

On Wed, May 6, 2020 at 11:31 PM stevea  wrote:

> If you fancy yourself (or know one!) a political scientist steeped enough
> in US law, history and politics sufficient to discuss subtle, nuanced
> topics like Home Rule and Dillon's law, a Discussion in our wiki could use
> your wisdom and guidance.
>
> As the OSM community in USA discussed boundary=administrative at length in
> 2017, admin_level got "mostly" hashed out, with a "settled" consensus about
> COGs, MPOs, SPDs and their ilk.  (Briefly, admin_level=2 federal, 4 state,
> 6 county and 8 city/town are rough rungs, 7 emerged for townships and 5 is
> the multi-county glom-of-6s New York City, OSM's only 5 in the USA).  But
> COGs/MPOs/SPDs and their ilk stuck in many craws and apparently is
> difficult for some, even many.
>
> The topic is active again at
> https://wiki.osm.org/wiki/Talk:United_States_admin_level#Recently_added_Connecticut_COG_.28Regions.29_as_5_and_CDP_as_10_should_be_deleted
> and seems to need the assistance of seasoned political scientists who can
> say whether a COG in Connecticut, for example, is "a government" or not.
> (I say a COG/MPO is a LIMITED government, like a sewer district, so isn't
> "really" a "full spectrum" government, therefore shouldn't get an
> admin_level value, as this key associates with boundary=administrative).
>
> Some Wikipedia links to "Home Rule in the USA" and "Dillon's Rule" are
> clickable at the end of that long Discussion, then I "run out of
> intellectual gas."  Please help this Discussion if you have this sort of
> knowledge / wisdom to contribute.
>
> Thank you,
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[OSM-talk-fr] Fwd: Evolution des règles pour les plages et la ligne de côte

2020-05-07 Per discussione Yves P.
> J'aimerais bien et j'y pense depuis un bout de temps car effectivement le 
> wiki lui-même (coastline, Beach, bare_rock, mud, tidal, tidalflat, frontieres 
> marines, shoal, etc) manque de ces images. Mais il va falloir s'y coller car 
> ce n'est pas si simple…
Je te fais confiance :)

ça peut-être des liens dans cette discussion vers plusieurs site existants.
ou un "gribouillage" sur une feuille de papier prise en photo :)

Je pensais à un schéma de ce style : 
https://wiki.openstreetmap.org/wiki/DE:Hafen#Musterhafen 


Mais en partant plutôt d'un ou plusieurs exemples réels (comme ça on peut 
comparer avec des vues aériennes, voir différents rendus…)

Plage bretonne sur le site du SHOM (carte marine, + trait de côte + BDOrtho IGN)

https://data.shom.fr/donnees#001=eyJjIjpbLTQ4MTg2MS45NTM4NTM5ODg1LDYyMTk1OTQuODA4NjcyMzAzXSwieiI6MTYuNzg2NjY2NjY2NjY2NjcyLCJyIjowLCJsIjpbeyJ0eXBlIjoiSU5URVJOQUxfTEFZRVIiLCJpZGVudGlmaWVyIjoiRkRDX0dFQkNPX1BZUi1QTkdfMzg1N19XTVRTIiwib3BhY2l0eSI6MSwidmlzaWJpbGl0eSI6dHJ1ZX0seyJ0eXBlIjoiSU5URVJOQUxfTEFZRVIiLCJpZGVudGlmaWVyIjoiUkFTVEVSX01BUklORV81MF9XTVRTXzM4NTciLCJvcGFjaXR5IjowLjMsInZpc2liaWxpdHkiOnRydWV9LHsidHlwZSI6IkVYVEVSTkFMX1dNUyIsInVybCI6Imh0dHBzOi8vd3hzLmlnbi5mci9xbHl0MjE4dXNiam50dnhyOXZnc3Y0dzYvZ2VvcG9ydGFpbC9yL3dtcz8iLCJwYXJhbXMiOnsiTEFZRVJTIjoiT1JUSE9JTUFHRVJZLk9SVEhPUEhPVE9TLkJET1JUSE8iLCJUUkFOU1BBUkVOVCI6dHJ1ZSwiVkVSU0lPTiI6IjEuMy4wIiwiRk9STUFUIjoiaW1hZ2UvanBlZyJ9LCJpZGVudGlmaWVyIjoiT1JUSE9JTUFHRVJZLk9SVEhPUEhPVE9TLkJET1JUSE8iLCJ0aXRsZSI6IkJEIE9ydGhvIiwib3BhY2l0eSI6MSwiZXh0ZXJuYWwiOnRydWUsInZpc2liaWxpdHkiOnRydWV9XX0=
__
Yves


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


Re: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Michael Andersen
Der er en del parkeringskældre i OSM, der kun tillader køretøjer op til 1,9 m. 
Og så er 
der https://www.openstreetmap.org/node/5030243561[1]  ;-)

Mvh Hjart

torsdag den 7. maj 2020 13.48.34 CEST skrev Niels Elgaard Larsen:
> Michael Andersen:
> > Ihvertfald i Osmand kan man taste højden på sit køretøj ind, men hvem
> > kender den og
> > 
> > tænker på taste det ind inden man kører?
> 
> Man skal jo kun taste det ind når man kører i en ny bil.
> Og hvis man nu kører i to lastbiler, der ikke var helt lige høje, så kunne
> man jo taste højden for den laveste ind,
> Og i Osmand kan man lave flere "driving" profiler, så man har en for hver
> lastbil.
> 
> Hvis jeg kørte rundt i en lastbil, der var omkring 3 meter høj, så ville jeg
> helt sikkert taste højden for min lastbil ind i Osmand.
> 
> Hvis man ikke ved hvor høj ens bil er, så hjælper skiltningen jo heller
> ikke.
> 
> Faktisk har jeg engang sat højden til 2 meter for min bil (hvilket er
> rigeligt). Men det var nok mest fordi jeg undersøgte, hvad Osmand kunne.
> 
> Og der findes næppe nogen broer, parkeringskældre, færger osv, der er for
> lave til min bil.
> 
> Desuden så sidder jeg jo med øjnene næsten oppe under taget på min lille
> bil, så jeg kunne nok godt på øjemål vurdere om den gik.
> 
> Men hvis lastbilen er dobbelt så høj, som førerhuset, så er det svært.




[1] https://www.openstreetmap.org/node/5030243561
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk


Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-07 Per discussione Djo_man via Talk-fr
J'aimerais bien et j'y pense depuis un bout de temps car effectivement le wiki 
lui-même (coastline, Beach, bare_rock, mud, tidal, tidalflat, frontieres 
marines, shoal, etc) manque de ces images. Mais il va falloir s'y coller car ce 
n'est pas si simple... 

Djo man 


 Yves P. a écrit 

>Salut,
>
>Votre discussion est assez technique ;)
>
>Pouvez-vous mettre un lien sur un schéma, une photo aérienne, le(s) rendu(s) 
>et si possible une carte marine pour qu'on puisse suivre ?
>(et tant qu'à faire ne pas cartographier n'importe quoi)
>
>Merci,
>
>__
>Yves
>
>> Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus 
>> bas que la ligne de basse mer car avec les belles images aériennes et une 
>> eau claire on en voit tres bien les contours. C'est presque un autre 
>> probleme mais explique bien que l'enchainement de ses zones ressemble à un 
>> geant code barre le long des côtes avec beach et bare_rock qui s'enchaînent.
>un exemple ici stp :)
>
>
>
>___
>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] Ça reste ouvert bientôt intégré sur le site de la ville de Lyon

2020-05-07 Per discussione Sylvain Maillard
Bonjour,

c'est super cool ça !

Par curiosité, qui est votre contact à la mairie de Lyon ? Je vais veiller
à ce qu'il y ai une bonne couverture médiatique ;)

Sylvain


Le mer. 6 mai 2020 à 22:31, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 06/05/2020 à 22:07, François Lacombe a écrit :
> > Dans les semaines à venir nous continuerons de nous impliquer pour
> > faire de "Ça reste ouvert" une solution pertinente durant les nombreux
> > mois du déconfinement mais aussi durant la poursuite du confinement
> > dans d'autres pays.
> > Nous sommes certains de pouvoir compter sur votre soutien pour
> > continuer ensemble à développer ce projet.
> >
> > Florian, François, Adrien et Vincent et Noémie
>
> Nous, nous contribuons modestement à l’œuvre, mais le résultat donne
> beaucoup de plaisir.
> Merci de nous avoir offert ça.
> :-)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Niels Elgaard Larsen
Michael Andersen:
> Ihvertfald i Osmand kan man taste højden på sit køretøj ind, men hvem kender 
> den og
> 
> tænker på taste det ind inden man kører?

Man skal jo kun taste det ind når man kører i en ny bil.
Og hvis man nu kører i to lastbiler, der ikke var helt lige høje, så kunne man 
jo
taste højden for den laveste ind,
Og i Osmand kan man lave flere "driving" profiler, så man har en for hver 
lastbil.

Hvis jeg kørte rundt i en lastbil, der var omkring 3 meter høj, så ville jeg 
helt
sikkert taste højden for min lastbil ind i Osmand.

Hvis man ikke ved hvor høj ens bil er, så hjælper skiltningen jo heller ikke.

Faktisk har jeg engang sat højden til 2 meter for min bil (hvilket er rigeligt).
Men det var nok mest fordi jeg undersøgte, hvad Osmand kunne.

Og der findes næppe nogen broer, parkeringskældre, færger osv, der er for lave 
til
min bil.

Desuden så sidder jeg jo med øjnene næsten oppe under taget på min lille bil, 
så jeg
kunne nok godt på øjemål vurdere om den gik.

Men hvis lastbilen er dobbelt så høj, som førerhuset, så er det svært.


-- 
Niels Elgaard Larsen

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


Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

2020-05-07 Per discussione osm . sanspourriel

Le 07/05/2020 à 11:40, Marc M. - marc_marc_...@hotmail.com a écrit :

Je lui propose de s'inspirer du travail des développeurs de JOSM
qui fonctionne bien (ils utilisent wikidata, mais aussi data items).
Réponse à la con !!:(

il t'a dit "si qlq le fait, je regarderais, mais je ne le code pas".
je trouve cela plutôt ouvert d'esprit pour quelqu'un qui a un
avis totalement opposé à ta demande.
oui c'est con il est bénévole et non ton employé.
Réponse à la con de ma part.

Cordialement,
Marc


Marc, pas une réponse à la con de ta part (ni de celle d'Yves) mais Yves
a l'expérience d'une PR qui est restée trainer 5 ans (!) parce que Tom
je dirais ne daignait regarder les PR existants. Elle a fini par passer
parce que nous deux avons fait pression (nous n'étions pas à l'origine
ni du ticket ni du PR).

Tom a prétendu que le PR était passé en dehors des radars. Ce n'est pas
à exclure, admettons.

Mais du coup quand il dit "fait le boulot et je regarderai ce que j'en
fais", ça passe mal.

Car ça fait bien "gardien du temple". Que ce soit à juste ou titre ou pas.

Jean-Yvon

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


Re: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Uffe Kousgaard
Sæt et kamera op i nærheden og lav din egen youtube-kanal, så kan man 
sikkert tjene lidt penge på det.


Som nogle folk gør her:
https://www.youtube.com/watch?v=9k319Qfm01A

mvh
Uffe Kousgaard

On 07-05-2020 13:09, Allan Gyldendal Frederiksen wrote:

Det ville virkeligt være smart med en sådan app, det sker meget jævnligt på det 
sted, bor selv i nærheden:-)

Venlig hilsen

Allan Gyldendal Frederiksen

-Oprindelig meddelelse-
Fra: Niels Elgaard Larsen [mailto:elga...@agol.dk]
Sendt: 7. maj 2020 13:00
Til: OpenStreetMap Denmark
Emne: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

https://ekstrabladet.dk/112/ups-koerer-ind-i-bro/8113871
https://www.openstreetmap.org/way/38299827/history

Naturligvis ved vi ikke om han fulgte en rute fra et navigationsprogram.

Gad vide om der findes apps, der giver en advarsel for for lav højde, også 
selvom man
ikke følger en rute.




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


Re: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Michael Andersen
Ihvertfald i Osmand kan man taste højden på sit køretøj ind, men hvem kender 
den og 
tænker på taste det ind inden man kører?

Bolderslev Hovedgade[1] 

Mvh Hjart

torsdag den 7. maj 2020 13.09.31 CEST skrev Allan Gyldendal Frederiksen:
> Det ville virkeligt være smart med en sådan app, det sker meget jævnligt på
> det sted, bor selv i nærheden:-)
 
> Venlig hilsen
> 
> Allan Gyldendal Frederiksen
> 
> -Oprindelig meddelelse-
> Fra: Niels Elgaard Larsen [mailto:elga...@agol.dk] 
> Sendt: 7. maj 2020 13:00
> Til: OpenStreetMap Denmark
> Emne: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.
> 
> https://ekstrabladet.dk/112/ups-koerer-ind-i-bro/8113871
> https://www.openstreetmap.org/way/38299827/history
> 
> Naturligvis ved vi ikke om han fulgte en rute fra et navigationsprogram.
> 
> Gad vide om der findes apps, der giver en advarsel for for lav højde, også
> selvom man
 ikke følger en rute.
> 
> -- 
> Niels Elgaard Larsen
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk




[1] File:Bolderslev Hovedgade - max 2.3 m under jernbanen.jpg
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk


Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

2020-05-07 Per discussione Martin Noblecourt

Bonjour,

Pour ceux qui n'en seraient pas membres, le bureau de la Fondation OSM 
vient justement de lancer une consultation sur la question du 
recrutement d'employés pour faire tourner les services essentiels.


Je vous invite à participer à cette discussion (et à adhérer à la 
Fondation si pas déjà fait), cela aura sans doute plus d'impact que d'en 
parler ici ;)


A bientôt,

Martin



Subject:
Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"
From:
"Marc M." 
Date:
07/05/2020, 11:40

To:
talk-fr@openstreetmap.org


Bonjour,

Le 07.05.20 à 11:23, Yves P. a écrit :

Le 5 mai 2020 à 18:35, Florimond Berthoux a écrit :
Je ne comprend pas, il ne t'a pas insulté

comment interpréter "Until then this issue is just so much hot air." ?

4 personnes différentes disent qu'un façon d'avancer est de ne plus
avoir le code en dur pour faire le lien entre clef osm et url
tu es toi-même d'accord.
Tant qu'aucun code n'est écrit, ce ticket tourne dans le vide,


Je lui propose de s'inspirer du travail des développeurs de JOSM
qui fonctionne bien (ils utilisent wikidata, mais aussi data items).
Réponse à la con !!:(

il t'a dit "si qlq le fait, je regarderais, mais je ne le code pas".
je trouve cela plutôt ouvert d'esprit pour quelqu'un qui a un
avis totalement opposé à ta demande.
oui c'est con il est bénévole et non ton employé.
Réponse à la con de ma part.

Cordialement,
Marc


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


Re: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Allan Gyldendal Frederiksen
Det ville virkeligt være smart med en sådan app, det sker meget jævnligt på det 
sted, bor selv i nærheden:-)

Venlig hilsen

Allan Gyldendal Frederiksen

-Oprindelig meddelelse-
Fra: Niels Elgaard Larsen [mailto:elga...@agol.dk] 
Sendt: 7. maj 2020 13:00
Til: OpenStreetMap Denmark
Emne: [Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

https://ekstrabladet.dk/112/ups-koerer-ind-i-bro/8113871
https://www.openstreetmap.org/way/38299827/history

Naturligvis ved vi ikke om han fulgte en rute fra et navigationsprogram.

Gad vide om der findes apps, der giver en advarsel for for lav højde, også 
selvom man
ikke følger en rute.

-- 
Niels Elgaard Larsen

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


[Talk-dk] Det var ikke sket med OpenStreetMap i de sidste 11 år.

2020-05-07 Per discussione Niels Elgaard Larsen
https://ekstrabladet.dk/112/ups-koerer-ind-i-bro/8113871
https://www.openstreetmap.org/way/38299827/history

Naturligvis ved vi ikke om han fulgte en rute fra et navigationsprogram.

Gad vide om der findes apps, der giver en advarsel for for lav højde, også 
selvom man
ikke følger en rute.

-- 
Niels Elgaard Larsen

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


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Nicolas Bétheuil
Pour le point 2, y en a qui ont fait l'exercice de monter ça en atelier en
moins de 3h.
https://github.com/ulrich/devoxx-france-maps-hands-on/
https://cfp.devoxx.fr/2018/talk/WJU-4345/Reconstruire_Google_Maps_en_moins_de_3_heures.html

Serveur de tuile, Calcul d'itinéraire, Recherche full text

Bon, je crois que tous les participants ont pas réussi.



Le jeu. 7 mai 2020 à 11:22, Marc M.  a écrit :

> Le 07.05.20 à 11:00, Axel Listes a écrit :
> > Le 07/05/2020 à 10:48, Marc M. a écrit :
> >> je te conseille fortement de commencer par le point 1 vu
> >> qu'il est de toute facon nécessaire si tu estimes vouloir
> >> faire le point 2
> >
> > En fait, j'ai déjà créé il y a plusieurs années une carto que je mets
> > à jour de temps en temps manuellement, les tuiles étant générées par
> > Maperitive.
> >
> > J'ai l'idée depuis un bon moment de passe à Leaflet pour automatiser les
> > mises à jours, j'ai même sous la main des documentations qui semblent
> > complets, cependant je n'arrive pas à me dégager du temps pour cela.
>
> Leaflet ne s'occupe pas de la maj de la base de donnée ou des tuiles.
> il ne fait qu'aller chercher renseigner l'url des tuiles situées
> "ailleurs" pour afficher le rendu voulu sur la page web qui l'appelle
>
> > La demande concerne surtout le point deux qui répond à un besoin de
> > rapidement référencer les aménagements temporaires, qui doivent en
> > théorie être opérationnels dès le 11 mai.
>
> le 1 est le fait aussi, bcp plus rapide que de faire le point 2 puisque
> le point 2 nécessite *aussi* un leaflet ou équivalent pour l'afficher
> sur ton site.
>
> > J'ai vu qu'il y a des fichiers json dans la forge, du coup il me
> > semblait pas à priori qu'il y a de base de données, possible que je me
> > trompe.
>
> la base de donnée (quasi 1To au niveau mondial) n'est jamais comprise
> dans le style vu sa taille et le fait qu'elle change toutes les minutes
> cyclosm utilise une base monde hébergée par osm-fr
> si tu installes une base limité une agglomération, elle sera
> évidement beaucoup plus petite.
> si tu veux vraiement faire cette solution, il y a aussi un docker
> pour la partie bdd+tuile
>
> > si ce n'est pas simple à mettre en place
>
> la solution 1 minimale consiste à copier le code html de
> https://switch2osm.org/using-tiles/getting-started-with-leaflet/
> et à y rajouter celle de cyclo
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Florimond Berthoux
Bonjour,

Je crois que Marc tu ne réponds pas sur le bon niveau à la question.
Je crois que ce que tu souhaites Axel c'est de répliquer le site
https://carte.velo-iledefrance.fr pour ta métropole et faire un
https://carte.trifouilly-les-oies-avelo.fr ?

Et la réponse est simple : clone
1. crée un compte github, clone le projet
https://github.com/velo-iledefrance/pistes-deconfinement
2. le site est dispo sur https://toncompte.github.io/coronapiste-website/
Oui c'est github qui héberge le site, c'est très léger ça ne pose pas de
soucis.
En fait la page c'est juste une page html qui contient du code javascript
(Leaflet) pour afficher les différents calques.
3. modifier les fichier .geojson à ta convenance (avec UMap ou
http://geojson.io)
4. pointer le nom de domaine carte.trifouilly-les-oies-avelo.fr vers
tontompte.github.io/coronapiste-website/

carte_de_travail_pistes_temporaires.geojson -> calque projet (gris)
existant.geojson -> itinéraire existant (rouge)
pistes_provisoires.geojson -> nouvelles pistes/itinéraires (orange)

Je vais rajouter cette mini doc au projet.

Cordialement.

Le jeu. 7 mai 2020 à 09:11, Axel Listes  a écrit :

> Bonjour Florimond,
>
> Le 06/05/2020 à 23:04, Florimond Berthoux a écrit :
> > L'idée est d'aider le cycliste à trouver son (nouveau) chemin, faire un
> > suivit des réalisation et à encourager le politique.
> > Vous pouvez trouver le code, par ici (rien de fantasque ;)
> > https://github.com/velo-iledefrance/pistes-deconfinement
>
> J'ai un serveur web dédié, maintenant partons du principe que je
> souhaite déployer rapidement une version de ce logiciel sur la métropole
> ou je contribue à l'introduction d’aménagements temporaires.
>
> Je ne sais pas comment mettre en place le logiciel, quels paquets il
> faut installer, quels fichiers doivent être modifié pour viser sur le
> bon endroit, etc.
>
> Est-il possible d'ajouter un petit fichier qui peut permettre de
> facilement installer cet outil localement ?
>
> Merci pour les cartes :)
>
> Axel.
>
> --
>
> "Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
> mérite ni l'une ni l'autre, et finit par perdre les deux."
> Citation de Benjamin Franklin.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

2020-05-07 Per discussione Marc M.
Bonjour,

Le 07.05.20 à 11:23, Yves P. a écrit :
>> Le 5 mai 2020 à 18:35, Florimond Berthoux a écrit :
>> Je ne comprend pas, il ne t'a pas insulté
> comment interpréter "Until then this issue is just so much hot air." ?

4 personnes différentes disent qu'un façon d'avancer est de ne plus
avoir le code en dur pour faire le lien entre clef osm et url
tu es toi-même d'accord.
Tant qu'aucun code n'est écrit, ce ticket tourne dans le vide,

> Je lui propose de s'inspirer du travail des développeurs de JOSM 
> qui fonctionne bien (ils utilisent wikidata, mais aussi data items).
> Réponse à la con !! :(

il t'a dit "si qlq le fait, je regarderais, mais je ne le code pas".
je trouve cela plutôt ouvert d'esprit pour quelqu'un qui a un
avis totalement opposé à ta demande.
oui c'est con il est bénévole et non ton employé.
Réponse à la con de ma part.

Cordialement,
Marc

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


Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

2020-05-07 Per discussione Yves P.

> Le 5 mai 2020 à 18:35, Florimond Berthoux  a 
> écrit :
> 
> Je ne comprend pas, il ne t'a pas insulté
Pas directement heureusement :)

Mais comment interpréter "Until then this issue is just so much hot air." ?
Moi je trouve ça insultant.

> il veut juste pas faire ce que tu veux.
Je ne lui demande pas d'être d'accord avec moi ;)
Mais d'avoir des arguments factuels et de rester ouvert d'esprit. D'autant plus 
que d'autres contributeurs ne vont pas dans son sens (à défaut d'aller dans le 
miens).

Pour les arguments contre, il y avait le fait qu'il faut modifier le code à 
chaque demande de liens automatique à partir des valeurs d'un tag.
Et surtout, ne pas faire de précédent pour ne pas pousser les contributeurs à 
inventer des clés !! :D

On lui a proposé de récupérer les infos dans wikidata : ça n'allait pas, 
wikidata pas OSM !
Je lui propose de s'inspirer du travail des développeurs de JOSM qui fonctionne 
bien (ils utilisent wikidata, mais aussi data items).
Réponse à la con !! :(

Il y a une discussion sur plusieurs années à propos des liens vers mapillary, 
toujours "bloquée".

> C'est des bénévoles ils sont libre de faire ou de ne pas faire, 
Oui.

Ça me rappel le tollé après la gestion unilatérale de brand:wikidata dans iD.
Ce n'était pas acceptable car c'était la décision d'une seule personne mais 
travaillant pour des intérêts privés.

Ici, ça serait acceptable car ça provient d'un bénévole ??

> ils sont libre d'argumenter ou non.
ça serait plus encourageant de ne pas répondre, que de répondre comme il le 
fait (dans ce ticket et dans d'autres).

> Fais une PR si tu veux.
> Et rien n'empêche de créer un nouveau frontend plus mieux à osm.org 
>  si c'est méga bloquant.
Le but n'est pas de remplacer le "dictateur" par un autre ;)

Et il y aurait moins d'énergie perdu à écrire le code par une personne 
expérimentée en Ruby On Rail et "maitrisant" le projet que par un "débutant" 
sur le sujet.

> Après sur le fond, a priori je suis pour qu'une structure OSM embauche et 
> développe un meilleur service pour attirer un public plus large.
On est au moins d'accord sur ce point :)

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


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Marc M.
Le 07.05.20 à 11:00, Axel Listes a écrit :
> Le 07/05/2020 à 10:48, Marc M. a écrit :
>> je te conseille fortement de commencer par le point 1 vu
>> qu'il est de toute facon nécessaire si tu estimes vouloir
>> faire le point 2
> 
> En fait, j'ai déjà créé il y a plusieurs années une carto que je mets 
> à jour de temps en temps manuellement, les tuiles étant générées par
> Maperitive.
> 
> J'ai l'idée depuis un bon moment de passe à Leaflet pour automatiser les
> mises à jours, j'ai même sous la main des documentations qui semblent
> complets, cependant je n'arrive pas à me dégager du temps pour cela.

Leaflet ne s'occupe pas de la maj de la base de donnée ou des tuiles.
il ne fait qu'aller chercher renseigner l'url des tuiles situées
"ailleurs" pour afficher le rendu voulu sur la page web qui l'appelle

> La demande concerne surtout le point deux qui répond à un besoin de
> rapidement référencer les aménagements temporaires, qui doivent en
> théorie être opérationnels dès le 11 mai.

le 1 est le fait aussi, bcp plus rapide que de faire le point 2 puisque
le point 2 nécessite *aussi* un leaflet ou équivalent pour l'afficher
sur ton site.

> J'ai vu qu'il y a des fichiers json dans la forge, du coup il me
> semblait pas à priori qu'il y a de base de données, possible que je me
> trompe.

la base de donnée (quasi 1To au niveau mondial) n'est jamais comprise
dans le style vu sa taille et le fait qu'elle change toutes les minutes
cyclosm utilise une base monde hébergée par osm-fr
si tu installes une base limité une agglomération, elle sera
évidement beaucoup plus petite.
si tu veux vraiement faire cette solution, il y a aussi un docker
pour la partie bdd+tuile

> si ce n'est pas simple à mettre en place

la solution 1 minimale consiste à copier le code html de
https://switch2osm.org/using-tiles/getting-started-with-leaflet/
et à y rajouter celle de cyclo

Cordialement,
Marc

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


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Axel Listes
Bonjour Marc,

Le 07/05/2020 à 10:48, Marc M. a écrit :
> 1) utiliser le rendu produit par cyclosm
> je t'aurais bien dit de consulter
> http://www.openstreetmap.fr/fonds-de-carte/ mais il semble qu'on y ai
> oublier de dire la base :
> pour utiliser un rendu, il te suffit d'une solution comme
> https://leafletjs.com/
> tu mets le code pour charger leaflet sur ton site
> tu met dans la conf leaflet que tu veux le rendu cyclosm
> et c'est out.
> tu as aussi cette explication sur https://switch2osm.org/using-tiles/
> n'hésites pas à faire un retour, ce serrait utile de savoir
> ce que quelqu'un qui ne l'a jamais fait en pense.
> 
> 2) produire son propre rendu
> c'est netement plus long, surtout la première fois
> il te faudra : une base de donnée, la garder à jour, installer le
> logiciel de rendu et finalement il te faudra quand même de quoi
> intégrer ces tuiles sur le site.
> tu as un tutoriel sur https://switch2osm.org/serving-tiles/
> 
> je te conseille fortement de commencer par le point 1 vu
> qu'il est de toute facon nécessaire si tu estimes vouloir
> faire le point 2

En fait, j'ai déjà créé il y a plusieurs années une carto que je mets à
jour de temps en temps manuellement, les tuiles étant générées par
Maperitive.

J'ai l'idée depuis un bon moment de passe à Leaflet pour automatiser les
mises à jours, j'ai même sous la main des documentations qui semblent
complets, cependant je n'arrive pas à me dégager du temps pour cela.

La demande concerne surtout le point deux qui répond à un besoin de
rapidement référencer les aménagements temporaires, qui doivent en
théorie être opérationnels dès le 11 mai.

J'ai vu qu'il y a des fichiers json dans la forge, du coup il me
semblait pas à priori qu'il y a de base de données, possible que je me
trompe.

J’avoue pour le coup je joue un peu au fainéant :) Au pire, si ce n'est
pas simple à mettre en place, on utilisera un Umap ou équivalent.

Bien cordialement.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

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


Re: [OSM-talk-fr] Bano v2

2020-05-07 Per discussione Marc M.
Bonjour,

super nouvelle \o/ merci pour le travail accompli !
en route vers le rendu bano v2 ? :-D

Le 07.05.20 à 08:29, Vincent de Château-Thierry a écrit :
> https://previous.bano.openstreetmap.fr/data/ 
il y avait un petit soucis de certificat, corrigé.

> où ils continuent pour l'instant d'être générés.

mais comme signalé, la veille base dont il dépend ne se met plus à jour
depuis le 11 avril, et donc les fichiers produits ne le sont pas.
Je ne lui prodiguerais pas un acharnement thérapeutique :)

Cordialement,
Marc

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


[Talk-de] PTNA - News: ÖPNV-Analyse

2020-05-07 Per discussione Toni Erdmann

Es gibt eine neue Prüfung.

Ein Fahrzeug in einer PTv2 Relation (route=X) kann nur bestimmte 
Wegtypen benutzen ...


Genaueres im Forum:

https://forum.openstreetmap.org/viewtopic.php?id=69334

https://forum.openstreetmap.org/viewtopic.php?pid=785809#p785809

Gruß
Toni

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


Re: [OSM-talk-fr] Tags multiples dans OSM (API v0.7)

2020-05-07 Per discussione Yves P.
> Mais ça ne résoud pas la question des valeurs réellement trop longues
Pour moi faire sauter la limite des 254 caractères est un prérequis.

> (dont opening_hours, qu'on ne peut toujours pas découper facilement […] alors 
> que opening_hours impose un ordre précis d'interprétation).
Si avec une info dans DataItem qui indique quels tags acceptent les valeurs 
multiples (cf. message sur la limite des 255 caractères).
Dans la concaténation de tag + tag_1 + tag_… l'ordre est respecté :)


> , d'autant que cette proposition pour v0.7 ne concerne QUE les valeurs 
> multiples sans aucun ordre de tri significatif, alors que opening_hours 
> impose un ordre précis d'interprétation).
Il y a effectivement un bief possible : que l'ordre des valeurs ne soit plus 
respecté.

Ce n'est pas gênant si on indique des moyens de paiement (espèces, carte…)
Ça peut-être problématique pour un bar, tabac, restaurant. Quel valeur va 
afficher le rendu ?

> Si on doit respecter un ordre et pouvoir découper les valeurs longues,…
Encore une fois, ce sont deux choses différentes.

Peut-être qu'il faut faire une API v0.6.001 avec seulement la prise en compte 
des valeurs longues ?
Puis une v0.6.002 plus tard pour les valeurs multiples ?

L'article d'Allan a été écrit AVANT le confinement.
Peut-être que maintenant c'est plus facile de réunir virtuellement tous les 
développeurs OSM pour un hack week end ?

Et du coup le passage en v0.7 pourrait s'envisager à nouveau en mode "bourrin" 
(arrêter complètement l'API pendant ce temps de développement) ?

Un mix peut-être envisagé :
faire un hack par visio avec une petite modification à la fois, le tout en mode 
"doux".

Ça permettrait de vérifier la faisabilité de la mise à jour de l'API sans trop 
de casse, et d'avancer… un peu :)

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


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Marc M.
Bonjour,

Le 07.05.20 à 09:05, Axel Listes a écrit :
> Le 06/05/2020 à 23:04, Florimond Berthoux a écrit :
>> L'idée est d'aider le cycliste à trouver son (nouveau) chemin, faire un
>> suivit des réalisation et à encourager le politique.
>> Vous pouvez trouver le code, par ici (rien de fantasque ;)
>> https://github.com/velo-iledefrance/pistes-deconfinement
> 
> J'ai un serveur web dédié, maintenant partons du principe que je
> souhaite déployer rapidement une version de ce logiciel sur la métropole
> ou je contribue à l'introduction d’aménagements temporaires.

il faut d'abord se demander si tu as réelement besoin du logiciel
qui *produit* ce rendu ou si tu n'as besoin que de l'*afficher".

1) utiliser le rendu produit par cyclosm
je t'aurais bien dit de consulter
http://www.openstreetmap.fr/fonds-de-carte/ mais il semble qu'on y ai
oublier de dire la base :
pour utiliser un rendu, il te suffit d'une solution comme
https://leafletjs.com/
tu mets le code pour charger leaflet sur ton site
tu met dans la conf leaflet que tu veux le rendu cyclosm
et c'est out.
tu as aussi cette explication sur https://switch2osm.org/using-tiles/
n'hésites pas à faire un retour, ce serrait utile de savoir
ce que quelqu'un qui ne l'a jamais fait en pense.

2) produire son propre rendu
c'est netement plus long, surtout la première fois
il te faudra : une base de donnée, la garder à jour, installer le
logiciel de rendu et finalement il te faudra quand même de quoi
intégrer ces tuiles sur le site.
tu as un tutoriel sur https://switch2osm.org/serving-tiles/

je te conseille fortement de commencer par le point 1 vu
qu'il est de toute facon nécessaire si tu estimes vouloir
faire le point 2

Cordialement,
Marc

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


Re: [OSM-talk-fr] Limite de 255 caractères dans les tags OSM

2020-05-07 Per discussione Yves P.
> Cela ne dit pas comment les clés _1, _2 seront assemblées en une seule: en 
> séparant les valeurs par des point-virgules, des virgules, des espaces ou 
> rien du tout (concaténation simple).
Pour moi c'était évident : concaténation simple :)

> 
> L'usage actuel serait que des valeurs multiples sont dans des _1, _2, etc. 
> séparés et que leur séparation par défaut serait alors le point-virgule (ce 
> que fait déjà iD et certains éditeurs pour des valeurs multiples ou 
> différentes après une fusion de deux objets: ces _2 sont plutôt l'indication 
> d'une erreur ou ambiguïté à traiter manuellement, l'éditeur ayant été 
> incapable de choisir entre des valeurs potentiellement incompatibles)…
Je dois avoué que je n'ai pas regardé depuis un moment ce que produit iD :|

> Mais alors cela ne résoud toujours pas le problème des valeurs longues où ce 
> point-virgule "'implicite" sera faux (par exemple les balises "opening_hours" 
> qui ont des règles spécifiques de séparation).
Les DataItems peuvent (déjà ?) indiquer si le tag accepte des valeurs multiples.
Si oui, la concaténation se fait avec un point virgule, sinon c'est une 
concaténation simple.

Pour le cas de "opening_hours", ça ne fonctionne pas actuellement de toute 
façon.

> Si OSM doit évoluer, c'est pour permettre des valeurs de balises 
> "structurées". 
Andy Allan parle d'évolution de l'API en "douceur" ;)
Ceci n'est donc pas probable pour la v0.7, peut-être la v2.0 ?

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


Re: [OSM-talk-fr] Workflow pour opendata

2020-05-07 Per discussione Yves P.

> J'ai oublié de dire que j'ai commencé à travailler sur la possibilité 
> d'utiliser le backend Osmose avec Jupyter. Un sorte de shell python dans un 
> navigateur web. Au début ça va être en local,
C'est une grande avancée, merci :)

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


Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-07 Per discussione Yves P.
Salut,

Votre discussion est assez technique ;)

Pouvez-vous mettre un lien sur un schéma, une photo aérienne, le(s) rendu(s) et 
si possible une carte marine pour qu'on puisse suivre ?
(et tant qu'à faire ne pas cartographier n'importe quoi)

Merci,

__
Yves

> Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus bas 
> que la ligne de basse mer car avec les belles images aériennes et une eau 
> claire on en voit tres bien les contours. C'est presque un autre probleme 
> mais explique bien que l'enchainement de ses zones ressemble à un geant code 
> barre le long des côtes avec beach et bare_rock qui s'enchaînent.
un exemple ici stp :)



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


Re: [OSM-talk-fr] Ça ouvre des pistes cyclable et calque CyclOSM infra vélo

2020-05-07 Per discussione Axel Listes
Bonjour Florimond,

Le 06/05/2020 à 23:04, Florimond Berthoux a écrit :
> L'idée est d'aider le cycliste à trouver son (nouveau) chemin, faire un
> suivit des réalisation et à encourager le politique.
> Vous pouvez trouver le code, par ici (rien de fantasque ;)
> https://github.com/velo-iledefrance/pistes-deconfinement

J'ai un serveur web dédié, maintenant partons du principe que je
souhaite déployer rapidement une version de ce logiciel sur la métropole
ou je contribue à l'introduction d’aménagements temporaires.

Je ne sais pas comment mettre en place le logiciel, quels paquets il
faut installer, quels fichiers doivent être modifié pour viser sur le
bon endroit, etc.

Est-il possible d'ajouter un petit fichier qui peut permettre de
facilement installer cet outil localement ?

Merci pour les cartes :)

Axel.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

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


[Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

2020-05-07 Per discussione stevea
If you fancy yourself (or know one!) a political scientist steeped enough in US 
law, history and politics sufficient to discuss subtle, nuanced topics like 
Home Rule and Dillon's law, a Discussion in our wiki could use your wisdom and 
guidance.

As the OSM community in USA discussed boundary=administrative at length in 
2017, admin_level got "mostly" hashed out, with a "settled" consensus about 
COGs, MPOs, SPDs and their ilk.  (Briefly, admin_level=2 federal, 4 state, 6 
county and 8 city/town are rough rungs, 7 emerged for townships and 5 is the 
multi-county glom-of-6s New York City, OSM's only 5 in the USA).  But 
COGs/MPOs/SPDs and their ilk stuck in many craws and apparently is difficult 
for some, even many.

The topic is active again at 
https://wiki.osm.org/wiki/Talk:United_States_admin_level#Recently_added_Connecticut_COG_.28Regions.29_as_5_and_CDP_as_10_should_be_deleted
 and seems to need the assistance of seasoned political scientists who can say 
whether a COG in Connecticut, for example, is "a government" or not.  (I say a 
COG/MPO is a LIMITED government, like a sewer district, so isn't "really" a 
"full spectrum" government, therefore shouldn't get an admin_level value, as 
this key associates with boundary=administrative).

Some Wikipedia links to "Home Rule in the USA" and "Dillon's Rule" are 
clickable at the end of that long Discussion, then I "run out of intellectual 
gas."  Please help this Discussion if you have this sort of knowledge / wisdom 
to contribute.

Thank you,
SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[OSM-talk-fr] Bano v2

2020-05-07 Per discussione Vincent de Château-Thierry
Bonjour 

On a coutume avec Christian de dater la naissance de Bano au 8 mai 2014, le 
jour férié nous ayant permis de mettre au point, au cours d'un mini hackathon, 
les scripts de collectes d'adresses [1]. 

7 mai 2020... c'est donc à la veille du 6e anniversaire de Bano que je vous 
annonce enfin l'arrivée de Bano v2. 

L'annonce indique surtout un changement pour les consommateurs des données 
Bano. Les fichiers quotidiens auparavant téléchargeables à 
https://bano.openstreetmap.fr/data/ ont été déplacés vers 
https://previous.bano.openstreetmap.fr/data/ où ils continuent pour l'instant 
d'être générés.
Ceux qu'on trouve maintenant à https://bano.openstreetmap.fr/data/ sont 
directement issus de la base où atterrissent les contributions faites sur 
http://dev.cadastre.openstreetmap.fr/fantoir, base avec notamment la source 
FANTOIR maintenue à jour et la source Cadastre puisée chez Etalab. 

Dans les faits, rien ne change pour contribuer. Les pages d'analyse fantoir 
restent accessibles à https://dev.cadastre.openstreetmap.fr. Mais désormais 
vous pouvez aussi y accéder via l'adresse https://bano.openstreetmap.fr/fantoir 
Cette URL me paraissait plus intuitive pour décrire le service. Elle remplacera 
bientôt dev.cadastre, on en reparlera. Vous pouvez dès à présent mettre vos 
marque-pages à jour. 

Incidemment la page d'accueil https://bano.openstreetmap.fr émerge. Elle se 
veut le point d'aiguillage vers les données, les outils de contribution et le 
wiki. L'idée n'est pas d'y paraphraser le wiki mais de rester une page 
synthétique. Elle est perfectible et notoirement moche, les propositions 
d'amélioration sont bienvenues ici : https://github.com/osm-fr/bano-website.

Voilà, désolé pour la longueur du message, qui est aussi pour moi l'occasion de 
vous remercier pour toutes les contributions faites sur ce projet. 

Continuons ;) 

vincent

[1] https://lists.openstreetmap.org/pipermail/dev-fr/2014-May/002229.html

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


Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-07 Per discussione Djo_man via Talk-fr
Pour préciser mon point de vue. 

Au sujet de l'autonomie du trait de côte par rapport à la plage, je l'estime 
nécessaire car
toute la longueur des cotes mappées sera à terme constituée de zones de 
rochers, de zone de sables, beach ou natural=sand, de zone de natural=mud. Ses 
zones vont, pour les roches et les sables, le plus couramment du natural=heath 
ou grass qui ne voient jamais aucunes marées en haut jusqu'au plus bas de la 
plus basse mer. 

Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus bas 
que la ligne de basse mer car avec les belles images aériennes et une eau 
claire on en voit tres bien les contours. C'est presque un autre probleme mais 
explique bien que l'enchainement de ses zones ressemble à un geant code barre 
le long des côtes avec beach et bare_rock qui s'enchaînent. 

Il serait donc pour moi  illogique que par extension du modèle de tag (qui 
paliait d'abord à des problèmes de rendu)  l'on cherche à répercuter le 
découpage horizontal des plages (pour reprendre la logique de l'orientation du 
code barre donc Nord sud des plages) sur les 2 autres type de zones naturelles. 
On risque de se retrouver avec 6 zones differentes au lieu de 3. 

Donc pour moi l'estran qui va jusqu'à la coastline (on pourrait aussi remettre 
ça en cause ) doit être une grande zone qui recouvre toutes les zones 
naturelles du bord de mer. 

Djo man

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