[talk-cz] (no subject)

[Jiri Vlasak]

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

[talk-cz] (no subject)

[Jiri Vlasak]

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

Re: [talk-cz] (no subject) - mazání nepohodlných dat

[Tonda]

Já bych řekl, že si trefil hřebíček na hlavičku, to bylo první co mě 
napadlo jako důvod Edovy snahy ty traily tak vehementně ututlat. 
Největší křik ohledně profláknutí ilegálního trailu je právě od těch co 
to jezdí a kopou. Čím míň lidí to bude znát tím míň jich tam bude jezdit 
a tím menší je riziko, že se někdo naštve natolik že to začne řešit, 
čili tvůrci se to snaží utajit jak před cizími jezdci tak před 
ochranáři, policií atp. Ochránci přírody a odpůrci sice taky nadávají, 
ale ti se nesnaží to utajit, ti to chtějí prostě zrušit nebo co 
nejviditelněji zakázat.


Takže pokud to Edovi opravdu vadí, tak ať veme motyku a ty traily 
fyzicky zboří či zneprůjezdní, klidně po domluvě s majitelem.


T.

On 26.10.2020 11:32, Marián Kyral wrote:
A mimochodem. Nechci nikoho obviňovat, ale co když je pravým účelem 
mazání právě "zakrytí" nelegální činnosti? Tedy ne, aby se tam náhodou 
neobjevil nějaký cizí zájemce o svezení, ale naopak, aby se tam 
neobjevil někdo, kdo by to chtěl pokutovat? Silně totiž pochybuji, že 
si zájemci naslepo hledají "traily" na mapách. Spíše bych to viděl na 
nějaké diskusní fórum/FB stránku, kde se tihle lidí sdružují a 
vyměňují si informace mezi sebou.


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

Re: [talk-cz] (no subject) - mazání nepohodlných dat

[Marián Kyral]

Zdravím,

Kdo určuje, které pěšiny tam mají být a které ne? Jak poznám, které pěšiny
tam byly už před tím, než je tihle cyklisté zneužili?





Na druhou stranu, z pohledu chodce. Když v mapě uvidím podezřelou směsici
pěšin, tak vím, že bych si měl dávat pozor, že by mě tam mohl nějaký šílenec
srazit. Jednu takovou oblast jsem nedávno objevil a zatím stále přemýšlím,
zda ji má cenu mapovat.





A mimochodem. Nechci nikoho obviňovat, ale co když je pravým účelem mazání
právě "zakrytí" nelegální činnosti? Tedy ne, aby se tam náhodou neobjevil
nějaký cizí zájemce o svezení, ale naopak, aby se tam neobjevil někdo, kdo
by to chtěl pokutovat? Silně totiž pochybuji, že si zájemci naslepo hledají
"traily" na mapách. Spíše bych to viděl na nějaké diskusní fórum/FB stránku,
kde se tihle lidí sdružují a vyměňují si informace mezi sebou.




Marián




-- Původní e-mail --
Od: Eduard Šešulka 
Komu: OpenStreetMap Czech Republic 
Datum: 26. 10. 2020 11:09:07
Předmět: Re: [talk-cz] (no subject) - mazání nepohodlných dat
"

Zdravím,




já to všechno chápu.

Ale mícháte trochu jablka s hruškama.

Nepřidávám ani nemažu oficiální cesty, silnice, nebo dálnice.

Stejně tak nemažu žádné nemovitosti.

Tyto traily jsou ilegální a pokud v mapách nebudou, bude o nich vědět méně
lidí, kterým se případně může stát nějaký vážný úraz.

A když se stane takový úraz, může to dojít až do fáze, kdy začne policie
vyšetřovat, jak to tam je dlouho, odkud se o tom dozvěděl atd.

Je to prostě bezpečnostní pojistka.

Chápu, že vy to vidíte jinak, ale s neznalostí místní problematiky je to asi
stejné, jako bych já z Brna pouze přes internet diskutoval o tom, jak je
nebo není vhodné postavit nějakou silnici v západních Čechách.

Nemažu všechny stezky, jen určité, které by tam neměly být.

Stejně tak jsem se snažil tam nechat cesty, které jsou lesní a které nejsou
problematické.

Ale mám takový pocit, že Vaše rozhodnutí stejně nemám šanci změnit.

Díky alespoň za pochopení, proč to chci smazat.





po 26. 10. 2020 v 10:47 odesílatel Jan Martinec mailto:j...@martinec.name)> napsal:

"

Dobrý den,



Mapa odráží svět, jak existuje; rozbitím zrcadla se svět neopraví.




Jakmile začneme mapovat svět, jaký by se nám líbil, velmi rychle ta mapa
přestane fungovat. "Tenhle barák smazat, je načerno! Tady namalujeme
dálnici, mně by se líbila! Co není most přes Nové Mlýny, jezdí sem moc aut,
smažeme silnici! Tuhle křižovatku smažeme, každý měsíc je tu aspoň jeden
smrťák! Kdo netestuje, nemůže mít pozitivní výsledky, a je to!" Ani jedno
neopravuje problém, všechno ho to jen zametá pod koberec.




Pokud je tam cesta, na kterou nemá být přístup, měla by být označená access=
private . Pokud někdo zanese trasu, která neexistuje, to je TAKY špatně.




OpenStreetMap se řídí principem "mapujeme podle reálného stavu v terénu":
existuje to, budiž to v mapě; neexistuje to, nebudiž to v mapě. Všimněte si:
žádné hloubání nad tím, jestli to může, má a smí existovat.




Pokud je nesprávně ten reálný stav, je třeba to opravit v reálu, a ne
vyhrožovat policií.




Mapování zdar,

Honza "Piškvor" Martinec




Dne po 26. 10. 2020 9:25 uživatel Eduard Šešulka mailto:edasesu...@gmail.com)> napsal:

"

Zdravím,




Nejsem si jistý, jestli se mi podaří odpovědět do správné skupiny, ale
zkusím to.

Pokud jsou trasy ilegální, neměly by v mapě být.

Propisuje se to kdo ví kde a z toho pak plyne nekontrolované šíření tras.

Na tyto trasy se pak dostanou lidé, kteří by o tom jinak nikdy nevěděli a
může se stát průšvih, jako jsem již psal.

Jakmile se v tom začne vrtat Polici při vyšetřování, je z toho průšvih.

Jsou určité věci, které by se prostě  neměly dostat na internet.

Myslím si, že to není nic nepochopitelného.

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

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

Re: [talk-cz] (no subject) - mazání nepohodlných dat

[<0174]

Zdravím,
nejde o nějaký náš názor na diskusi, jde o oficiální stanovisko
OpenStreetMaps. Pokud se legální stav liší od stavu "fyzicky na zemi",
mapuje se, co je fyzicky na zemi.
Nehledě k tomu, že ježdění po stezkách ilegální pravděpodobně není
(narozdíl od jejich vytváření). Lesní zákon 289/95 paragraf 53 odst.
1 říká: „Přestupku se dopustí ten, kdo jezdí mimo cesty a vyznačené trasy
na kole, na koni, na lyžích nebo na saních.“  Co je to cesta, o tom se
můžou dohadovat právníci.
Všichni asi chápou, proč to chcete smazat, ale je to proti pravidlům
Openstreetmaps a stojí to mnoho lidí práci na revertech a vysvětlování. Tak
v tom prosím nepokračujte, než to bude stát ještě více práce.
Mimochodem, v Brně jsem bydlel a traily nad Svratkou znám.

<0174

po 26. 10. 2020 v 11:02 odesílatel Eduard Šešulka 
napsal:

> Zdravím,
>
> já to všechno chápu.
> Ale mícháte trochu jablka s hruškama.
> Nepřidávám ani nemažu oficiální cesty, silnice, nebo dálnice.
> Stejně tak nemažu žádné nemovitosti.
> Tyto traily jsou ilegální a pokud v mapách nebudou, bude o nich vědět méně
> lidí, kterým se případně může stát nějaký vážný úraz.
> A když se stane takový úraz, může to dojít až do fáze, kdy začne policie
> vyšetřovat, jak to tam je dlouho, odkud se o tom dozvěděl atd.
> Je to prostě bezpečnostní pojistka.
> Chápu, že vy to vidíte jinak, ale s neznalostí místní problematiky je to
> asi stejné, jako bych já z Brna pouze přes internet diskutoval o tom, jak
> je nebo není vhodné postavit nějakou silnici v západních Čechách.
> Nemažu všechny stezky, jen určité, které by tam neměly být.
> Stejně tak jsem se snažil tam nechat cesty, které jsou lesní a které
> nejsou problematické.
> Ale mám takový pocit, že Vaše rozhodnutí stejně nemám šanci změnit.
> Díky alespoň za pochopení, proč to chci smazat.
>
> po 26. 10. 2020 v 10:47 odesílatel Jan Martinec 
> napsal:
>
>> Dobrý den,
>>
>> Mapa odráží svět, jak existuje; rozbitím zrcadla se svět neopraví.
>>
>> Jakmile začneme mapovat svět, jaký by se nám líbil, velmi rychle ta mapa
>> přestane fungovat. "Tenhle barák smazat, je načerno! Tady namalujeme
>> dálnici, mně by se líbila! Co není most přes Nové Mlýny, jezdí sem moc aut,
>> smažeme silnici! Tuhle křižovatku smažeme, každý měsíc je tu aspoň jeden
>> smrťák! Kdo netestuje, nemůže mít pozitivní výsledky, a je to!" Ani jedno
>> neopravuje problém, všechno ho to jen zametá pod koberec.
>>
>> Pokud je tam cesta, na kterou nemá být přístup, měla by být označená
>> access=private . Pokud někdo zanese trasu, která neexistuje, to je TAKY
>> špatně.
>>
>> OpenStreetMap se řídí principem "mapujeme podle reálného stavu v terénu":
>> existuje to, budiž to v mapě; neexistuje to, nebudiž to v mapě. Všimněte
>> si: žádné hloubání nad tím, jestli to může, má a smí existovat.
>>
>> Pokud je nesprávně ten reálný stav, je třeba to opravit v reálu, a ne
>> vyhrožovat policií.
>>
>> Mapování zdar,
>> Honza "Piškvor" Martinec
>>
>> Dne po 26. 10. 2020 9:25 uživatel Eduard Šešulka 
>> napsal:
>>
>>> Zdravím,
>>>
>>> Nejsem si jistý, jestli se mi podaří odpovědět do správné skupiny, ale
>>> zkusím to.
>>> Pokud jsou trasy ilegální, neměly by v mapě být.
>>> Propisuje se to kdo ví kde a z toho pak plyne nekontrolované šíření tras.
>>> Na tyto trasy se pak dostanou lidé, kteří by o tom jinak nikdy nevěděli
>>> a může se stát průšvih, jako jsem již psal.
>>> Jakmile se v tom začne vrtat Polici při vyšetřování, je z toho průšvih.
>>> Jsou určité věci, které by se prostě  neměly dostat na internet.
>>> Myslím si, že to není nic nepochopitelného.
>>> ___
>>> talk-cz mailing list
>>> talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> https://openstreetmap.cz/talkcz
>>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] (no subject) - mazání nepohodlných dat

[Eduard Šešulka]

Zdravím,

já to všechno chápu.
Ale mícháte trochu jablka s hruškama.
Nepřidávám ani nemažu oficiální cesty, silnice, nebo dálnice.
Stejně tak nemažu žádné nemovitosti.
Tyto traily jsou ilegální a pokud v mapách nebudou, bude o nich vědět méně
lidí, kterým se případně může stát nějaký vážný úraz.
A když se stane takový úraz, může to dojít až do fáze, kdy začne policie
vyšetřovat, jak to tam je dlouho, odkud se o tom dozvěděl atd.
Je to prostě bezpečnostní pojistka.
Chápu, že vy to vidíte jinak, ale s neznalostí místní problematiky je to
asi stejné, jako bych já z Brna pouze přes internet diskutoval o tom, jak
je nebo není vhodné postavit nějakou silnici v západních Čechách.
Nemažu všechny stezky, jen určité, které by tam neměly být.
Stejně tak jsem se snažil tam nechat cesty, které jsou lesní a které nejsou
problematické.
Ale mám takový pocit, že Vaše rozhodnutí stejně nemám šanci změnit.
Díky alespoň za pochopení, proč to chci smazat.

po 26. 10. 2020 v 10:47 odesílatel Jan Martinec  napsal:

> Dobrý den,
>
> Mapa odráží svět, jak existuje; rozbitím zrcadla se svět neopraví.
>
> Jakmile začneme mapovat svět, jaký by se nám líbil, velmi rychle ta mapa
> přestane fungovat. "Tenhle barák smazat, je načerno! Tady namalujeme
> dálnici, mně by se líbila! Co není most přes Nové Mlýny, jezdí sem moc aut,
> smažeme silnici! Tuhle křižovatku smažeme, každý měsíc je tu aspoň jeden
> smrťák! Kdo netestuje, nemůže mít pozitivní výsledky, a je to!" Ani jedno
> neopravuje problém, všechno ho to jen zametá pod koberec.
>
> Pokud je tam cesta, na kterou nemá být přístup, měla by být označená
> access=private . Pokud někdo zanese trasu, která neexistuje, to je TAKY
> špatně.
>
> OpenStreetMap se řídí principem "mapujeme podle reálného stavu v terénu":
> existuje to, budiž to v mapě; neexistuje to, nebudiž to v mapě. Všimněte
> si: žádné hloubání nad tím, jestli to může, má a smí existovat.
>
> Pokud je nesprávně ten reálný stav, je třeba to opravit v reálu, a ne
> vyhrožovat policií.
>
> Mapování zdar,
> Honza "Piškvor" Martinec
>
> Dne po 26. 10. 2020 9:25 uživatel Eduard Šešulka 
> napsal:
>
>> Zdravím,
>>
>> Nejsem si jistý, jestli se mi podaří odpovědět do správné skupiny, ale
>> zkusím to.
>> Pokud jsou trasy ilegální, neměly by v mapě být.
>> Propisuje se to kdo ví kde a z toho pak plyne nekontrolované šíření tras.
>> Na tyto trasy se pak dostanou lidé, kteří by o tom jinak nikdy nevěděli a
>> může se stát průšvih, jako jsem již psal.
>> Jakmile se v tom začne vrtat Polici při vyšetřování, je z toho průšvih.
>> Jsou určité věci, které by se prostě  neměly dostat na internet.
>> Myslím si, že to není nic nepochopitelného.
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] (no subject) - mazání nepohodlných dat

[Jan Martinec]

Dobrý den,

Mapa odráží svět, jak existuje; rozbitím zrcadla se svět neopraví.

Jakmile začneme mapovat svět, jaký by se nám líbil, velmi rychle ta mapa
přestane fungovat. "Tenhle barák smazat, je načerno! Tady namalujeme
dálnici, mně by se líbila! Co není most přes Nové Mlýny, jezdí sem moc aut,
smažeme silnici! Tuhle křižovatku smažeme, každý měsíc je tu aspoň jeden
smrťák! Kdo netestuje, nemůže mít pozitivní výsledky, a je to!" Ani jedno
neopravuje problém, všechno ho to jen zametá pod koberec.

Pokud je tam cesta, na kterou nemá být přístup, měla by být označená
access=private . Pokud někdo zanese trasu, která neexistuje, to je TAKY
špatně.

OpenStreetMap se řídí principem "mapujeme podle reálného stavu v terénu":
existuje to, budiž to v mapě; neexistuje to, nebudiž to v mapě. Všimněte
si: žádné hloubání nad tím, jestli to může, má a smí existovat.

Pokud je nesprávně ten reálný stav, je třeba to opravit v reálu, a ne
vyhrožovat policií.

Mapování zdar,
Honza "Piškvor" Martinec

Dne po 26. 10. 2020 9:25 uživatel Eduard Šešulka 
napsal:

> Zdravím,
>
> Nejsem si jistý, jestli se mi podaří odpovědět do správné skupiny, ale
> zkusím to.
> Pokud jsou trasy ilegální, neměly by v mapě být.
> Propisuje se to kdo ví kde a z toho pak plyne nekontrolované šíření tras.
> Na tyto trasy se pak dostanou lidé, kteří by o tom jinak nikdy nevěděli a
> může se stát průšvih, jako jsem již psal.
> Jakmile se v tom začne vrtat Polici při vyšetřování, je z toho průšvih.
> Jsou určité věci, které by se prostě  neměly dostat na internet.
> Myslím si, že to není nic nepochopitelného.
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] (no subject)

[Eduard Šešulka]

Zdravím,

Nejsem si jistý, jestli se mi podaří odpovědět do správné skupiny, ale
zkusím to.
Pokud jsou trasy ilegální, neměly by v mapě být.
Propisuje se to kdo ví kde a z toho pak plyne nekontrolované šíření tras.
Na tyto trasy se pak dostanou lidé, kteří by o tom jinak nikdy nevěděli a
může se stát průšvih, jako jsem již psal.
Jakmile se v tom začne vrtat Polici při vyšetřování, je z toho průšvih.
Jsou určité věci, které by se prostě  neměly dostat na internet.
Myslím si, že to není nic nepochopitelného.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] (no subject)

[Cj Malone]

Passenger does a lot of good stuff. There down stream customers use
OSM, and credit it [0]. They release more up to date NaPTAN formatted
data that NaPTAN its self [1]. Honestly it's a bit of a shame the OSM
bus stop data is so neglected.


Cj

[0] https://www.islandbuses.info/explore
[1] https://www.islandbuses.info/open-data



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

[Talk-GB] (no subject)

[Andy Mabbett]

OSM gets a mention:

   "As the Department for Transport begins its journey to
review and redesign NaPTAN, we’re open sourcing
our Bus Stop Checker tool to help build back greener."

   
https://www.discoverpassenger.com/2020/07/13/passengers-bus-stop-checker-data-quality-tools-now-open-source/

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

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

Re: [Talk-ca] (no subject)

[James]

If it becomes over 2000 nodes in a single "way" or shape, it's recommended
to make it a multipolygon. The reason NRCan does this is probably because
it's on the edge of what they call "NTS Tiles" which is a grid that
organizes the data (see forests in Canada
https://wiki.openstreetmap.org/wiki/Canada#What.27s_with_the_forests_in_Canada.3F).
Importers just didnt join them back in the day, that's all

On Tue, Jul 7, 2020 at 5:02 AM Hannes Röst  wrote:

> Hello
>
> I am a contributor from Toronto and I have a question regarding how to
> treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
> I came across this lake here:
>
> https://www.openstreetmap.org/way/69275451
> https://www.openstreetmap.org/way/69277932
> https://www.openstreetmap.org/way/69745752
>
> Which is strangely split up into 3 parts and I wonder how to proceed:
> should we fix this and create a single way out of these 3 parts or is
> it beneficial (for comparison to future NRCan database entries) to
> keep them that way and create a relation out of the three? Also, does
> somebody know why the NRCan dataset does this, is this an import
> artefact (splitting into tiles?) or is it part of the original
> dataset?
>
> Best
>
> Hannes Rost
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] (no subject)

[Hannes Röst]

Hello

I am a contributor from Toronto and I have a question regarding how to
treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
I came across this lake here:

https://www.openstreetmap.org/way/69275451
https://www.openstreetmap.org/way/69277932
https://www.openstreetmap.org/way/69745752

Which is strangely split up into 3 parts and I wonder how to proceed:
should we fix this and create a single way out of these 3 parts or is
it beneficial (for comparison to future NRCan database entries) to
keep them that way and create a relation out of the three? Also, does
somebody know why the NRCan dataset does this, is this an import
artefact (splitting into tiles?) or is it part of the original
dataset?

Best

Hannes Rost

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

[talk-ph] (no subject)

[Eugene Alvin Villar]

Hello all,

There is an ongoing email thread on the OSM tagging mailing list about a
proposal to add the tag amenity=motorcycle_taxi to mark the station where
one can hire motorcycle-based taxis (very similar to our tricycles). (Note:
we are not talking about Angkas-like services which is what we expect the
phrase "motorcycle taxis" to be.)

Email thread:
https://lists.openstreetmap.org/pipermail/tagging/2020-February/051211.html

Tag proposal wiki page:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity=motorcycle_taxi

Your thoughts and comments are welcome! I can forward them to the tag
proposer if you cannot participate directly in the tagging mailing list nor
add comments to the proposal wiki talk page.

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

[talk-cz] (no subject)

[Jiri Vlasak]

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

Re: [talk-au] (no subject)

[David Wales]

Hello James,

Are you new here?
Welcome to Australia's OpenStreetMap mailing list!

Regards,
David

On 14 January 2020 11:18:31 pm AEDT, James Oliver 
 wrote:
>Hello
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] (no subject)

[James Oliver]

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

[Talk-GB] (no subject)

[Jez Nicholson]

I just updated the
https://wiki.openstreetmap.org/wiki/United_Kingdom_Tagging_Guidelines#Copyright_Infringement
 section.

Your input (on the wiki) to assist new and existing UK mappers would be
greatly appreciated.

It does seem heavily Ordnance Survey dominated. I'm sure that other data
sources have been ratified as usable.

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

[Talk-GB] (no subject)

[Rob Nickerson]

Hi all,

The following from Dorothea at OSMF. We'll see what scope there is for OSM
UK to answer (likely just re-iterating our aims and membership size). I
encourage individuals to respond too.

Best wishes
Rob

Hello,

The following survey on global and local communities in OpenStreetMap
was developed by board members. The survey is not quantitative and its
aim is to stimulate  discussions in local communities and at the Local
Chapters Congress at SotM.
https://osmf.limequery.org/428835

~ The survey will run for two weeks.
~ Only one question is mandatory: "How can we share your answers?".

There is more information on the scope of the survey and approach on the
opening page.

warm greetings,

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

[Talk-Kosovo] (no subject)

[Arianit Dobroshi]

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

[Talk-GB] (no subject)

[Jez Nicholson]

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

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

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

Re: [Talk-ca] (no subject)

[OSM Volunteer stevea]

On Jan 19, 2019, at 10:48 AM, john whelan  wrote:
> There was an earlier discussion on talk-ca about how to handle this project.

There were MANY.  Speaking for myself only, I urged a very cautious, go-slow 
approach, to edit the data into "improvement / harmony-with-OSM" as much as 
possible BEFORE they upload to be imported, (or document in the wiki HOW this 
was to happen), to use talk-ca, Tasking Manager and especially to develop and 
use a freshly-rewritten (and undergoing continuous improvement) wiki (this part 
was a/the major failing, imo) to communicate.  But that is looking in the 
rear-view mirror, and I don't like to hear "told you so," let alone say it.

> It is similar to CANVEC in the original data sources are municipal data 
> CANVEC uses a few other sources as well and it is released under exactly the 
> same license but by a different federal government department.

CANVEC data are roundly criticized.  And it doesn't matter where those data 
came from (CANVEC), nor where the present data come from (Stats Canada).  They 
are now "in the wild" and from an OSM perspective (what matters here and now), 
their source is essentially meaningless, except for historical context.

> There are 3,700 municipalities in Canada. How do you deal with that?

With good planning, using the tenets of OSM (e.g. the Import process, gaining 
consensus, good communication and appropriate tools like wiki, Tasking Manager 
and JOSM plug-ins where they make sense).  You DON'T try to short-circuit that 
by wholesale re-writing a re-write of the seed project wiki (now well-vetted, 
as if it were it were, and I tried, would have widely been seen as lacking), 
posting notice on talk-ca and waiting two weeks independent of their being very 
little feedback on so gigantic a process (a massive red flag).  In short, this 
was a huge "failure of consensus."  Look at the posts now which say "I woke up 
to a mess."  That simply shouldn't happen.

> A suggestion was made on talk-ca we have one import plan that way it would at 
> least be consistent and that's what we did.

This import plan, coming from the BC2020 wiki, which as written by Julia left a 
LOT to be desired as to technical specifics. I characterized this as 
"cheerleading and buzzword-compliant," sorry Julia, but it was and hence was 
ineffective as a wiki for its intended purposes, which is to answer questions 
of those who need technical guidance in an endeavor to have their "how?" 
questions appropriately answered.  That's what wikis do, they are good at it, 
OSM expects this, so when a wiki fails to deliver, the project experiences 
failures.  That absolutely should not surprise.

> Mentally I'd split the project into getting an import plan that met all the 
> requirements and the actual importing.

Um, yeah.

> To me the importing would be done by local mappers or mappers with a local 
> connection after a local discussion which is what happened in Kingston.  For 
> locations that did not have such mappers then over time they could be tackled 
> at a distance. One comment I recall was this was more of a marathon and to be 
> honest we expected it to take place over a fair length of time.  A lot of 
> buildings have gone in much faster than I expected.

So, plan for that.  Manage that.  If it isn't happening, make it happen with 
outreach and OSM's usual tactics of "developing community."  OSM has been doing 
this for over 15 years (and gets better at it), but it isn't "a hope and a 
prayer," it is continual engagement, effort (technical and social) and 
mid-course correction when necessary, all while keeping a hawkish eye on the 
finish line.

> For the pilot project with Ottawa the local Ottawa mappers were heavily 
> involved.  We learnt a fair bit on the way and that's why we basically cloned 
> the Ottawa import plan.  We noticed a lot of additional tags being added to 
> the building=yes and that to be was a good thing in that it drew more people 
> into OSM. I'm much more interested in those additional tags than anything 
> else.

Crowdsourced projects often yield unexpected positive results.  This is what 
our project means when we say our data get used "in creative, productive, or 
unexpected ways."  It happens (a lot), this is one of the best things about OSM.

> As far as I am aware there is no list of local OSM communities in Canada and 
> to be honest many mappers simply map and do not gather once a month at OSM 
> meetings.

So?  We don't need no stinkin' meetings, though all are welcome at meetings.

> I don't think we do an import plan every time we bring something across from 
> CANVEC.

Shame on whoever does this, it is wrong (from OSM's perspective, and this is 
OSM).

> Unfortunately there really is a demand for this sort of information.  The 
> initial 2020 meeting that took place at Stats Canada during the HOT summit in 
> Ottawa had many people from government departments who were very interested 
> in the data and especially what I call 

[Talk-ca] (no subject)

[john whelan]

 There was an earlier discussion on talk-ca about how to handle this
project.

It is similar to CANVEC in the original data sources are municipal data
CANVEC uses a few other sources as well and it is released under exactly
the same license but by a different federal government department.

There are 3,700 municipalities in Canada. How do you deal with that?  A
suggestion was made on talk-ca we have one import plan that way it would at
least be consistent and that's what we did.

Mentally I'd split the project into getting an import plan that met all the
requirements and the actual importing.  To me the importing would be done
by local mappers or mappers with a local connection after a local
discussion which is what happened in Kingston.  For locations that did not
have such mappers then over time they could be tackled at a distance. One
comment I recall was this was more of a marathon and to be honest we
expected it to take place over a fair length of time.  A lot of buildings
have gone in much faster than I expected.

For the pilot project with Ottawa the local Ottawa mappers were heavily
involved.  We learnt a fair bit on the way and that's why we basically
cloned the Ottawa import plan.  We noticed a lot of additional tags being
added to the building=yes and that to be was a good thing in that it drew
more people into OSM. I'm much more interested in those additional tags
than anything else.

As far as I am aware there is no list of local OSM communities in Canada
and to be honest many mappers simply map and do not gather once a month at
OSM meetings.

I don't think we do an import plan every time we bring something across
from CANVEC.

Unfortunately there really is a demand for this sort of information.  The
initial 2020 meeting that took place at Stats Canada during the HOT summit
in Ottawa had many people from government departments who were very
interested in the data and especially what I call enriched data, ie
buildings with addresses and other tags.  Smaller school boards have
expressed an interest in routing school buses using this sort of data.
There is an app for the blind that guides you to the building but the
building and address have to be on the map.

Should we care what end users are interested in?  I think that is a
separate discussion.

There always has been a range of views within OpenStreetMap.  I have
certainly been taken to task for changing a tag from traffic_lights to
traffic_signals.  "I mapped it and I tagged it traffic_lights and it should
remain that way."  Toronto was almost certainly going to be troublesome.  I
recall someone saying once if you gather five book classifiers together
they will find six ways to classify a book. The Ottawa community is
reasonably small and many meet up from time to time.  In a city such as
Toronto my expectation would be a much wider range of opinions. This makes
it very difficult to identify if something is approved or not. It also
means that my expectation that the importing mapper will use a bit of
common sense and we shouldn't need to spell out things like "replace
geometry tool" other mappers will have other expectations.

My understanding of importing or drawing a building outline from imagery is
it gets tagged building=yes and you can do no better from imagery.
Occasionally you might see a building in a residential area that has two
drives, I might just tag that semi.

Then we throw in the 2020 project. Stats initial idea was to simply have
every building mapped in Canada with iD and mapathons were a wonderful
idea.  Technically it is possible to accurately map a building from imagery
with iD I've seen it done.  You may wish to talk to Pierre about data
quality from those mapathons.

I had talked to Stats about getting the building outlines released under a
suitable license.  It only took a year to persuade the City of Ottawa to
change their Open Data license to one that worked with OpenStreetMap.

Stats came back some time later by releasing some building outline data
under the federal government Open Data license and that's where this bit
started.

The 2020 project has a lot of interest from GIS departments, High Schools
are thinking of how to get involved with their students.  Adding tags is a
lot safer and less error prone than drawing buildings in iD.  Education is
one area that Stats gets brownie points for so they like to promote it.

Microsoft has been running the same algorithms on Canada as it has in the
US.  We can expect their building outlines to be released shortly.

Data quality, by the time its been converted from one format to another and
comes form a variety of systems some municipal data will be better than
others. The data I've looked at looks reasonable however my expectations
and your expectations maybe different.

You might like to add a step or two into the wiki.

We could do a table in the wiki with a list of communities that feel
comfortable with the import. That might be troublesome, two high school
students 

[talk-ph] (no subject)

[Eugene Alvin Villar]

Hello all,

I'm forwarding this message posted by the Grab OSM team. You can see the
referred document in the message on GitHub here:
https://github.com/GRABOSM/Grab-Data/issues/19#issuecomment-410603506

~Eugene


> Good Morning All,
>
> Firstly, we would like to sincerly thank Erwin and Rally for the detailed
> explanation on how to use offset database.
>
> A quick clarification of the objects we mentioned in our github issue
> page. Before we started to work on Metro Manila, a note was posted in PH
> facebook page in the intent to get help from local community on any specifc
> policies to be followed, offset distance to be maintained etc. Alvin from
> the community made a point that there was a significant contribution made
> by Kaart team in the same area, so, we wanted to evaluate the city and
> understand if we want to continue working on Metro Manila or not.
>
> Two categories of objects were mentioned in the page -
> - missing roads - way id or node id mentioned here are the ids of roads
> nearby to the missing roads.
> - classification gaps - example objects with incorrect classifications.
>
> Hence these objects posted in our github page are only examples of missing
> roads and classification gaps we found in the sample areas we investigated
> and does not comprise the entire work we intend to do in the city.
>
> As suggested by Erwin, to further clarify what do we mean by
> classification gaps we tried to explain a handful of instances so that we
> can explain our project to the community better.
>
> Here is the document with examples.
>
> Local mappers have been of great help and support and we will ensure to
> continue producing high quality maps within our scope.
>
> Thanks
> Lavanya
> Grab Team
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-in] (no subject)

[PC creation Presents]

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

Re: [talk-latam] (no subject)

[Miguel Sevilla-Callejo]

En OSM lo tenemos implementado desde hace un año: Riot+IRC+Telegram

Cada uno decide en qué plataforma se conecta.


--
 Miguel Sevilla-Callejo
from my mobile 

El 11/1/2018 19:08, "Felix Delattre"  escribió:

> On 01/11/2018 06:39 PM, Leo Arias wrote:
> > On Thu, Jan 11, 2018 at 03:52:23PM +0100, Felix Delattre wrote:
> >> Es una lastima que el grupo comunica primeramente sobre medios cerrados
> >> de software propietario y centralizado :( Eso me ha impedido a
> >> participar en el grupo desde que se fueron para allá.
> > En el JáquerEspeis estamos experimentando con el puente que une telegram
> > con matrix, en ambas direcciones, a ver si algún día nos logramos mover
> de
> > telegram por completo.
> >
> > A veces se queda pegado, pero está bueno para ayudar a probaro también.
> Si les
> > interesa me avisan y lo configuramos.
> >
> > pura vida.
>
> Buena onda, sí, Leo, un puente con Matrix sería maravilloso. A mí me
> interesaría mucho.
>
> Por si alguien no lo conoce, aquí hay mas información:
> https://matrix.org/docs/projects/try-matrix-now.html
> Y por si quieren probar y/o contactarme no duden en agregarme:
> @xamanu:matrix.org
>
> Abrazos,
> Felix
>
> ___
> talk-latam mailing list
> talk-latam@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-latam
>
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [talk-latam] (no subject)

[Felix Delattre]

Es una lastima que el grupo comunica primeramente sobre medios cerrados
de software propietario y centralizado :( Eso me ha impedido a
participar en el grupo desde que se fueron para allá.

Saludos,
Felix

On 01/04/2018 12:44 AM, Miguel Sevilla-Callejo wrote:
> Genial,
>
> Yo me di de alta en esta lista hoy mismo para mandar el mensaje pues
> creo que solo Marco Antonio (de Cochabamba, Bolivia) escribe de vez en
> cuando y, no tiene mucha actividad (no como el grupo de Telegram).
>
> Supongo que él puede decirte más recursos comunes de la comunidad
> latina e hispanohablante.
>
> Saludos
>
> --
>  Miguel Sevilla-Callejo
> from my mobile 
>
> El 3/1/2018 20:13, "Javier Sánchez Portero"  > escribió:
>
> Hola
>
> Me llamo Javier y llevo un tiempo contribuyendo al mapa
> principalmente en las Islas Canarias.
>
> Miguel cuenta conmigo si puedo ayudar. Los contenidos que sean
> comunes se pueden trasladar a plantillas y cada comunidad puede
> crear sus páginas incluyendo la parte común con la plantilla y a
> continuación el contenido específico.
>
> Cuando busque contactar con la comunidad hispanohablante en la
> Wiki no encontré enlaces a esta lista y al grupo de Telegram
>
> https://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana
> 
>
> La edito y actualizo.
>
> Saludos a todos,
> Javier Sánchez
>
>
> ___
> talk-latam mailing list
> talk-latam@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-latam
> 
>
>
>
> ___
> talk-latam mailing list
> talk-latam@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-latam


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

Re: [talk-latam] (no subject)

[Miguel Sevilla-Callejo]

Genial,

Yo me di de alta en esta lista hoy mismo para mandar el mensaje pues creo
que solo Marco Antonio (de Cochabamba, Bolivia) escribe de vez en cuando y,
no tiene mucha actividad (no como el grupo de Telegram).

Supongo que él puede decirte más recursos comunes de la comunidad latina e
hispanohablante.

Saludos

--
 Miguel Sevilla-Callejo
from my mobile 

El 3/1/2018 20:13, "Javier Sánchez Portero"  escribió:

> Hola
>
> Me llamo Javier y llevo un tiempo contribuyendo al mapa principalmente en
> las Islas Canarias.
>
> Miguel cuenta conmigo si puedo ayudar. Los contenidos que sean comunes se
> pueden trasladar a plantillas y cada comunidad puede crear sus páginas
> incluyendo la parte común con la plantilla y a continuación el contenido
> específico.
>
> Cuando busque contactar con la comunidad hispanohablante en la Wiki no
> encontré enlaces a esta lista y al grupo de Telegram
>
> https://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana
>
> La edito y actualizo.
>
> Saludos a todos,
> Javier Sánchez
>
>
> ___
> talk-latam mailing list
> talk-latam@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-latam
>
>
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[talk-latam] (no subject)

[Javier Sánchez Portero]

Hola

Me llamo Javier y llevo un tiempo contribuyendo al mapa principalmente en
las Islas Canarias.

Miguel cuenta conmigo si puedo ayudar. Los contenidos que sean comunes se
pueden trasladar a plantillas y cada comunidad puede crear sus páginas
incluyendo la parte común con la plantilla y a continuación el contenido
específico.

Cuando busque contactar con la comunidad hispanohablante en la Wiki no
encontré enlaces a esta lista y al grupo de Telegram

https://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana

La edito y actualizo.

Saludos a todos,
Javier Sánchez
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-it] (no subject)

[Infoweblan di Roberto Vito Gerardo]

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[lenny]

Le 27/07/2017 à 08:26, Christian Quest a écrit :

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec 
addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à 
l'adresse...


On a du coup des positions d'adresses souvent peu homogènes lorsqu'on 
abuse des addr:*


Ensuite ça s'aggrave quand on doublonne en un vrai point définissant 
l'adresse et un addr:* rajouté à un POI proche.


Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de 
multiples addr:* pour une même adresse, pour éliminer ceux qui 
potentiellement devraient être un contact:*, en regardant si il y a 
d'autres tags (shop, etc)... mais c'est un pis aller.


le problème quand on fait porter les addr: sur un POI, c'est (comme je 
viens de voir un exemple) un magasin (correspondant au POI) a fermé et 
un contributeur a supprimé le node qui portait le POI et les addr: 
résultat : le node adresse a disparu



Le 26 juillet 2017 à 20:34, lenny.libre > a écrit :


Par contre dans les remarques qui leur sont faites, je ne vois pas
pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir
que le "2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
inutile. Si vous ne comprenez pas, allez sur place et regardez les
numéros de rue : y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on
met la rue en tant que addr:street ou relation

:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses



Dans le cas que tu as cité, il faisait partie d'une relation (donc
on pouvait supprimer le addr:street) mais s'il n'y a pas de
relation, il ne faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand il
n'y a pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils
pourraient mettre contact:housenumber, ...

https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema




cordialement

Leni


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Et l'associatedStreet n'a aucun de ces inconvénients (j'aurai 
effectivement dû dire à SeFaireConnaitre de mettre le POI dans 
l'associatedStreet.


Jean-Yvon


Le 28/07/2017 à 09:47, Leni - lenny.li...@orange.fr a écrit :


Le 27/07/2017 à 08:26, Christian Quest a écrit :

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec 
addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à 
l'adresse...


On a du coup des positions d'adresses souvent peu homogènes lorsqu'on 
abuse des addr:*


Ensuite ça s'aggrave quand on doublonne en un vrai point définissant 
l'adresse et un addr:* rajouté à un POI proche.


Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de 
multiples addr:* pour une même adresse, pour éliminer ceux qui 
potentiellement devraient être un contact:*, en regardant si il y a 
d'autres tags (shop, etc)... mais c'est un pis aller.


le problème quand on fait porter les addr: sur un POI, c'est (comme je 
viens de voir un exemple) un magasin (correspondant au POI) a fermé et 
un contributeur a supprimé le node qui portait le POI et les addr: 
résultat : le node adresse a disparu



Le 26 juillet 2017 à 20:34, lenny.libre > a écrit :


Par contre dans les remarques qui leur sont faites, je ne vois
pas pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir
que le "2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
inutile. Si vous ne comprenez pas, allez sur place et regardez
les numéros de rue : y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on
met la rue en tant que addr:street ou relation

:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses



Dans le cas que tu as cité, il faisait partie d'une relation
(donc on pouvait supprimer le addr:street) mais s'il n'y a pas de
relation, il ne faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand
il n'y a pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils
pourraient mettre contact:housenumber, ...

https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema




cordialement

Leni





___
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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Leni]

Le 27/07/2017 à 08:26, Christian Quest a écrit :

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec 
addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à 
l'adresse...


On a du coup des positions d'adresses souvent peu homogènes lorsqu'on 
abuse des addr:*


Ensuite ça s'aggrave quand on doublonne en un vrai point définissant 
l'adresse et un addr:* rajouté à un POI proche.


Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de 
multiples addr:* pour une même adresse, pour éliminer ceux qui 
potentiellement devraient être un contact:*, en regardant si il y a 
d'autres tags (shop, etc)... mais c'est un pis aller.


le problème quand on fait porter les addr: sur un POI, c'est (comme je 
viens de voir un exemple) un magasin (correspondant au POI) a fermé et 
un contributeur a supprimé le node qui portait le POI et les addr: 
résultat : le node adresse a disparu



Le 26 juillet 2017 à 20:34, lenny.libre > a écrit :


Par contre dans les remarques qui leur sont faites, je ne vois pas
pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir
que le "2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
inutile. Si vous ne comprenez pas, allez sur place et regardez les
numéros de rue : y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on
met la rue en tant que addr:street ou relation

:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses



Dans le cas que tu as cité, il faisait partie d'une relation (donc
on pouvait supprimer le addr:street) mais s'il n'y a pas de
relation, il ne faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand il
n'y a pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils
pourraient mettre contact:housenumber, ...

https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema




cordialement

Leni


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

"contact:*" n'est pas nécessairement "à" l'adresse du point, ce qui est
indiqué est une adresse de contact postal qui peut être complètement
ailleurs et même pas géolocalisée (par exemple une boite postale ou un
CEDEX), ou l'adresse d'un service tiers de gestion de relations client, ou
l'adresse du siège social gérant tout une série d'établissements.
On aura donc besoin de "contact:*" et "addr:*". Je suis juste d'accord sur
le fait que "addr:*" doit être géolocalisé au POI, et ne désigner alors
qu'un unique établissement.

Le 27 juillet 2017 à 08:26, Christian Quest  a
écrit :

> Oui, pas très malin comme remarque...
>
> Le problème pour moi est plutôt indiquer l'adresse d'un POI avec addr:*
> plutôt que contact:* car le POI n'est pas "l'adresse", mais à l'adresse...
>
> On a du coup des positions d'adresses souvent peu homogènes lorsqu'on
> abuse des addr:*
>
> Ensuite ça s'aggrave quand on doublonne en un vrai point définissant
> l'adresse et un addr:* rajouté à un POI proche.
>
> Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de
> multiples addr:* pour une même adresse, pour éliminer ceux qui
> potentiellement devraient être un contact:*, en regardant si il y a
> d'autres tags (shop, etc)... mais c'est un pis aller.
>
>
>
> Le 26 juillet 2017 à 20:34, lenny.libre  a écrit :
>
>> Par contre dans les remarques qui leur sont faites, je ne vois pas
>> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
>>
>> Le commentaire :  "Le positionnement géographique permet de savoir que
>> le "2" fait référence à la Place de la Nuit du 6 Août 1944".
>> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
>> vous ne comprenez pas, allez sur place et regardez les numéros de rue : y
>> figurent juste un nombre, sans nom de rue. "
>>
>> me parait un brin radical, car ce n'est pas toujours le cas, on met la
>> rue en tant que addr:street ou relation :https://wiki.openstreetmap.or
>> g/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
>>
>> Dans le cas que tu as cité, il faisait partie d'une relation (donc on
>> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
>> faut pas le supprimer.
>>
>> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
>> pas de relation https://www.openstreetmap.org/
>> node/507550316#map=19/44.63221/-1.14615
>>
>>
>> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
>> mettre contact:housenumber, ... https://wiki.openstreetmap.org
>> /wiki/Proposed_features/House_numbers/Bremen_Schema
>>
>>
>> cordialement
>>
>> Leni
>>
>>
>>
>> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>>
>> Ce n'est pas une question de motivation, c'est juste que via l'outil
>> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
>> regarde donc les contributions qui les concernent. S'agissant des
>> contributions de SeFaireConnaitre, mes corrections ne concernent que ces
>> zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
>> Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
>> retirer les tags en trop.
>>
>> Ils ont à nouveau commenté en nous remerciant des remarques faites et
>> disent qu'ils mettront à jour les données.
>>
>> Romain
>>
>> Le 22 juillet 2017 à 11:58, marc marc  a
>> écrit :
>>
>>> Tu es motivé Romain !
>>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>>> désirer.
>>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>>> Le plus utile me semble être soit un copier/coller d'un message
>>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>>> erroné) si possible par email à la direction, à défaut à l'email
>>> générale + copie dans le chanset.
>>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>>> prévenir qu'ils payent pour un service ce mauvaise qualité
>>> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
>>> s'améliorer
>>> On peux aussi se "partager" l'envois de message. si plusieurs personnes
>>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>>> qu'il y a un problème chez eux.
>>> On peux aussi leur montrer cette conversation
>>> Dernière solution : leur proposer une formation (payante) ou un contrôle
>>> qualité :-)
>>>
>>> mes 2 cents..
>>>
>>
>>
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> 

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Christian Quest]

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec addr:*
plutôt que contact:* car le POI n'est pas "l'adresse", mais à l'adresse...

On a du coup des positions d'adresses souvent peu homogènes lorsqu'on abuse
des addr:*

Ensuite ça s'aggrave quand on doublonne en un vrai point définissant
l'adresse et un addr:* rajouté à un POI proche.

Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de
multiples addr:* pour une même adresse, pour éliminer ceux qui
potentiellement devraient être un contact:*, en regardant si il y a
d'autres tags (shop, etc)... mais c'est un pis aller.



Le 26 juillet 2017 à 20:34, lenny.libre  a écrit :

> Par contre dans les remarques qui leur sont faites, je ne vois pas
> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
>
> Le commentaire :  "Le positionnement géographique permet de savoir que le
> "2" fait référence à la Place de la Nuit du 6 Août 1944".
> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
> vous ne comprenez pas, allez sur place et regardez les numéros de rue : y
> figurent juste un nombre, sans nom de rue. "
>
> me parait un brin radical, car ce n'est pas toujours le cas, on met la rue
> en tant que addr:street ou relation :https://wiki.openstreetmap.
> org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
>
> Dans le cas que tu as cité, il faisait partie d'une relation (donc on
> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
> faut pas le supprimer.
>
> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
> pas de relation https://www.openstreetmap.org/node/507550316#map=19/44.
> 63221/-1.14615
>
>
> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
> mettre contact:housenumber, ... https://wiki.openstreetmap.
> org/wiki/Proposed_features/House_numbers/Bremen_Schema
>
>
> cordialement
>
> Leni
>
>
>
> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>
> Ce n'est pas une question de motivation, c'est juste que via l'outil
> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
> regarde donc les contributions qui les concernent. S'agissant des
> contributions de SeFaireConnaitre, mes corrections ne concernent que ces
> zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
> Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
> retirer les tags en trop.
>
> Ils ont à nouveau commenté en nous remerciant des remarques faites et
> disent qu'ils mettront à jour les données.
>
> Romain
>
> Le 22 juillet 2017 à 11:58, marc marc  a écrit
> :
>
>> Tu es motivé Romain !
>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>> désirer.
>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>> Le plus utile me semble être soit un copier/coller d'un message
>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>> erroné) si possible par email à la direction, à défaut à l'email
>> générale + copie dans le chanset.
>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>> prévenir qu'ils payent pour un service ce mauvaise qualité
>> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
>> s'améliorer
>> On peux aussi se "partager" l'envois de message. si plusieurs personnes
>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>> qu'il y a un problème chez eux.
>> On peux aussi leur montrer cette conversation
>> Dernière solution : leur proposer une formation (payante) ou un contrôle
>> qualité :-)
>>
>> mes 2 cents..
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonsoir,

Il a déjà été dit sur cette liste qu'une adresse est un objet en soi qui ne
doit pas être répété. Donc oui les tags contact:housenumber et
contact:street ont toute leur place pour malgré tout préciser l'adresse
d'un objet.

Je viens de finir "le ménage" sur tous les CMB en Bretagne et j'ai
effectivement retiré des addr:street là où l'orthographe de la voie était
incorrect. Pour le reste, j'ai laissé mais il y a peut être bien des
conversions à faire en contact: pour ne pas avoir un doublon avec une
adresse existante par ailleurs.

Romain

Le 26 juillet 2017 à 20:34, lenny.libre  a écrit :

> Par contre dans les remarques qui leur sont faites, je ne vois pas
> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
>
> Le commentaire :  "Le positionnement géographique permet de savoir que le
> "2" fait référence à la Place de la Nuit du 6 Août 1944".
> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
> vous ne comprenez pas, allez sur place et regardez les numéros de rue : y
> figurent juste un nombre, sans nom de rue. "
>
> me parait un brin radical, car ce n'est pas toujours le cas, on met la rue
> en tant que addr:street ou relation :https://wiki.openstreetmap.or
> g/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
>
> Dans le cas que tu as cité, il faisait partie d'une relation (donc on
> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
> faut pas le supprimer.
>
> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
> pas de relation https://www.openstreetmap.org/
> node/507550316#map=19/44.63221/-1.14615
>
>
> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
> mettre contact:housenumber, ... https://wiki.openstreetmap.org
> /wiki/Proposed_features/House_numbers/Bremen_Schema
>
>
> cordialement
>
> Leni
>
>
>
> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>
> Ce n'est pas une question de motivation, c'est juste que via l'outil
> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
> regarde donc les contributions qui les concernent. S'agissant des
> contributions de SeFaireConnaitre, mes corrections ne concernent que ces
> zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
> Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
> retirer les tags en trop.
>
> Ils ont à nouveau commenté en nous remerciant des remarques faites et
> disent qu'ils mettront à jour les données.
>
> Romain
>
> Le 22 juillet 2017 à 11:58, marc marc  a écrit
> :
>
>> Tu es motivé Romain !
>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>> désirer.
>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>> Le plus utile me semble être soit un copier/coller d'un message
>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>> erroné) si possible par email à la direction, à défaut à l'email
>> générale + copie dans le chanset.
>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>> prévenir qu'ils payent pour un service ce mauvaise qualité
>> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
>> s'améliorer
>> On peux aussi se "partager" l'envois de message. si plusieurs personnes
>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>> qu'il y a un problème chez eux.
>> On peux aussi leur montrer cette conversation
>> Dernière solution : leur proposer une formation (payante) ou un contrôle
>> qualité :-)
>>
>> mes 2 cents..
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[lenny.libre]

Par contre dans les remarques qui leur sont faites, je ne vois pas 
pourquoi on devrait supprimer le addr:street, c'est nouveau ?


Le commentaire : "Le positionnement géographique permet de savoir que le 
"2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si 
vous ne comprenez pas, allez sur place et regardez les numéros de rue : 
y figurent juste un nombre, sans nom de rue. "


me parait un brin radical, car ce n'est pas toujours le cas, on met la 
rue en tant que addr:street ou relation 
:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses


Dans le cas que tu as cité, il faisait partie d'une relation (donc on 
pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne 
faut pas le supprimer.


Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a 
pas de relation 
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils pourraient 
mettre contact:housenumber, ... 
https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema



cordialement

Leni



Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
Ce n'est pas une question de motivation, c'est juste que via l'outil 
WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je 
regarde donc les contributions qui les concernent. S'agissant des 
contributions de SeFaireConnaitre, mes corrections ne concernent que 
ces zones et donc c'est très loin d'être exhaustif. Dans le cas 
présent des Crédit Mutuel de Bretagne, il faudrait tous les passer en 
revue... pour retirer les tags en trop.


Ils ont à nouveau commenté en nous remerciant des remarques faites et 
disent qu'ils mettront à jour les données.


Romain

Le 22 juillet 2017 à 11:58, marc marc > a écrit :


Tu es motivé Romain !
J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
désirer.
Par contre je pense pas qu'un "je surveille" trimestre va les faire
s'améliorer même s'ils se sont déjà pris 3 blocages.
Le plus utile me semble être soit un copier/coller d'un message
explicatif (genre vos modifs sont en grande partie inutilisable voir
erroné) si possible par email à la direction, à défaut à l'email
générale + copie dans le chanset.
Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
prévenir qu'ils payent pour un service ce mauvaise qualité
Si l'un d'eux demande des comptes à son prestataire, les choses
peuvent
s'améliorer
On peux aussi se "partager" l'envois de message. si plusieurs
personnes
écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
qu'il y a un problème chez eux.
On peux aussi leur montrer cette conversation
Dernière solution : leur proposer une formation (payante) ou un
contrôle
qualité :-)

mes 2 cents..




___
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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Ce n'est pas une question de motivation, c'est juste que via l'outil
WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
regarde donc les contributions qui les concernent. S'agissant des
contributions de SeFaireConnaitre, mes corrections ne concernent que ces
zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
retirer les tags en trop.

Ils ont à nouveau commenté en nous remerciant des remarques faites et
disent qu'ils mettront à jour les données.

Romain

Le 22 juillet 2017 à 11:58, marc marc  a écrit :

> Tu es motivé Romain !
> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
> désirer.
> Par contre je pense pas qu'un "je surveille" trimestre va les faire
> s'améliorer même s'ils se sont déjà pris 3 blocages.
> Le plus utile me semble être soit un copier/coller d'un message
> explicatif (genre vos modifs sont en grande partie inutilisable voir
> erroné) si possible par email à la direction, à défaut à l'email
> générale + copie dans le chanset.
> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
> prévenir qu'ils payent pour un service ce mauvaise qualité
> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
> s'améliorer
> On peux aussi se "partager" l'envois de message. si plusieurs personnes
> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
> qu'il y a un problème chez eux.
> On peux aussi leur montrer cette conversation
> Dernière solution : leur proposer une formation (payante) ou un contrôle
> qualité :-)
>
> mes 2 cents..
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Ok pour "contact:phone", c'est le revert qui est du coup revenu sur "phone".

Le 22 juillet 2017 à 08:15, Stéphane Péneau  a
écrit :

> contact:phone n'était pas incorrect.
>
> Pour le reste.hum.
>
> Stf
>
>
> Le 21/07/2017 à 23:04, Romain MEHUT a écrit :
>
> Bonsoir,
>
> Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272
>
> Romain
>
> Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre
>> continuent cf. https://www.openstreetmap.org/changeset/46490928
>>
>> Romain
>>
>>
>> Le 15 octobre 2015 à 12:04, Romain MEHUT  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>>> https://www.openstreetmap.org/changeset/34586502 et
>>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à
>>> ce jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>>
>>> Romain
>>>
>>> Le 14 octobre 2015 23:35,  a écrit :
>>>
 Bien, merci d'améliorer votre processus de production/validation de
 données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
 en voiture selon OSRM).
 Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
 tram doit faire tiquer.
 Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
 Les deux premiers points c'est votre problème.
 Le troisième aussi mais c'est surtout celui qui nous concerne.

 Pour votre pénitence, vous leur proposerez une alternative à ceci :
 http://juvignac.apef-services.fr/contact.html#map
 ;-).

 Jean-Yvon

 Le 14/10/2015 09:23, Support Sefaireconnaitre -
 supp...@sefaireconnaitre.com a écrit :

 Bonjour,
 Merci pour le signalement, j'ai bien repositionné le point de vente.

 Amandine Nicolas - Ubiflow



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


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[marc marc]

Tu es motivé Romain !
J'ai regaré au hazard quelques changet.. la qualité laisse en effet à 
désirer.
Par contre je pense pas qu'un "je surveille" trimestre va les faire 
s'améliorer même s'ils se sont déjà pris 3 blocages.
Le plus utile me semble être soit un copier/coller d'un message 
explicatif (genre vos modifs sont en grande partie inutilisable voir 
erroné) si possible par email à la direction, à défaut à l'email 
générale + copie dans le chanset.
Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les 
prévenir qu'ils payent pour un service ce mauvaise qualité
Si l'un d'eux demande des comptes à son prestataire, les choses peuvent 
s'améliorer
On peux aussi se "partager" l'envois de message. si plusieurs personnes 
écrivent, cela montre que ce n'est pas juste Romain qui chipote mais 
qu'il y a un problème chez eux.
On peux aussi leur montrer cette conversation
Dernière solution : leur proposer une formation (payante) ou un contrôle 
qualité :-)

mes 2 cents..

Le 22. 07. 17 à 11:15, osm.sanspourr...@spamgourmet.com a écrit :
> Exact, mais si on ne fait que corriger leurs conneries, ils s'y 
> retrouvent : sauf erreur, Romain n'est pas payé par Ubiflow pour faire 
> ce contrôle qualité.
> 
> J'allais même dire twitter:facebook et contact:facebook aussi.
> 
> Car la page facebook permet bien de contacter mais non le CMB de Plouhay 
> mais le CMB en général.
> 
> Donc contact:facebook n'a rien à faire ici.
> 
> Y a-t-il des outil de contrôle qualité qui vérifient si certaines infos 
> sont uniques ?
> 
> Je pense à tous les contact:*, web et wikidata. Il peut y avoir des 
> exceptions, comme un restaurant ayant deux lieux mais un seul numéro de 
> réservation.
> 
> Par contre ici les "informations" ne portaient pas sur le CMB de Plouhay 
> mais sur le CMB.
> 
> Peut-être qu'un jour on essayera de travailler sur les brand/operator 
> qui peuvent comme ici offrir des services communs qui sont à mettre sur 
> ces objets (qui n'existent pas dans OSM sauf à faire une relation avec 
> tous les problèmes associés).
> 
> En fait les brand/operator portent sur des relations ou des points, les 
> ways sont rares et peu susceptibles aux problèmes des cassages de 
> relations styles frontières administratives. Je me trompe ?
> 
> Jean-Yvon
> 
> 
> Le 22/07/2017 à 08:15, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
> écrit :
>> contact:phone n'était pas incorrect.
>>
>> Pour le reste.hum.
>>
>> Stf
>>
>> Le 21/07/2017 à 23:04, Romain MEHUT a écrit :
>>> Bonsoir,
>>>
>>> Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272
>>>
>>> Romain
> 
> 
> 
> ___
> 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Exact, mais si on ne fait que corriger leurs conneries, ils s'y 
retrouvent : sauf erreur, Romain n'est pas payé par Ubiflow pour faire 
ce contrôle qualité.


J'allais même dire twitter:facebook et contact:facebook aussi.

Car la page facebook permet bien de contacter mais non le CMB de Plouhay 
mais le CMB en général.


Donc contact:facebook n'a rien à faire ici.

Y a-t-il des outil de contrôle qualité qui vérifient si certaines infos 
sont uniques ?


Je pense à tous les contact:*, web et wikidata. Il peut y avoir des 
exceptions, comme un restaurant ayant deux lieux mais un seul numéro de 
réservation.


Par contre ici les "informations" ne portaient pas sur le CMB de Plouhay 
mais sur le CMB.


Peut-être qu'un jour on essayera de travailler sur les brand/operator 
qui peuvent comme ici offrir des services communs qui sont à mettre sur 
ces objets (qui n'existent pas dans OSM sauf à faire une relation avec 
tous les problèmes associés).


En fait les brand/operator portent sur des relations ou des points, les 
ways sont rares et peu susceptibles aux problèmes des cassages de 
relations styles frontières administratives. Je me trompe ?


Jean-Yvon


Le 22/07/2017 à 08:15, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :

contact:phone n'était pas incorrect.

Pour le reste.hum.

Stf

Le 21/07/2017 à 23:04, Romain MEHUT a écrit :

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Stéphane Péneau]

contact:phone n'était pas incorrect.

Pour le reste.hum.

Stf

Le 21/07/2017 à 23:04, Romain MEHUT a écrit :

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain

Le 1 mars 2017 à 16:44, Romain MEHUT > a écrit :


Bonjour,

Pour info, les échanges (plus "mordants") avec SeFaireConnaitre
continuent cf. https://www.openstreetmap.org/changeset/46490928


Romain


Le 15 octobre 2015 à 12:04, Romain MEHUT > a écrit :

Bonjour,

J'ai pointé l'ajout de deux doublons (magasins Decathlon)
https://www.openstreetmap.org/changeset/34586502
 et
http://www.openstreetmap.org/changeset/34632382
 restés non
corrigés à ce jour. Et vu l'historique du compte
http://www.openstreetmap.org/user/SeFaireConnaitre
, il y a
ailleurs d'autres doublons similaires.

Romain

Le 14 octobre 2015 23:35, > a écrit :

Bien, merci d'améliorer votre processus de
production/validation de données afin d'éviter de placer
un lieu à 1,3 km de son lieu réel (distance en voiture
selon OSRM).
Ici par exemple comme déjà dit un lien sur un emplacement
d'arrêt de tram doit faire tiquer.
Ce n'est bon ni pour votre client, ni pour vous ni pour
OpenStreetMap.
Les deux premiers points c'est votre problème.
Le troisième aussi mais c'est surtout celui qui nous concerne.

Pour votre pénitence, vous leur proposerez une alternative
à ceci :
http://juvignac.apef-services.fr/contact.html#map

;-).

Jean-Yvon

Le 14/10/2015 09:23, Support Sefaireconnaitre -
supp...@sefaireconnaitre.com
 a écrit :

Bonjour,
Merci pour le signalement, j'ai bien repositionné le
point de vente.

Amandine Nicolas - Ubiflow




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







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



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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain

Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :

> Bonjour,
>
> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
> cf. https://www.openstreetmap.org/changeset/46490928
>
> Romain
>
>
> Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit
> :
>
>> Bonjour,
>>
>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>> https://www.openstreetmap.org/changeset/34586502 et
>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
>> jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>
>> Romain
>>
>> Le 14 octobre 2015 23:35,  a écrit :
>>
>>> Bien, merci d'améliorer votre processus de production/validation de
>>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>>> en voiture selon OSRM).
>>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
>>> tram doit faire tiquer.
>>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>>> Les deux premiers points c'est votre problème.
>>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>>
>>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>>> http://juvignac.apef-services.fr/contact.html#map
>>> ;-).
>>>
>>> Jean-Yvon
>>>
>>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>>> supp...@sefaireconnaitre.com a écrit :
>>>
>>> Bonjour,
>>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>>
>>> Amandine Nicolas - Ubiflow
>>>
>>>
>>>
>>> ___
>>> 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-be] (no subject)

[guy vanvuchelen]

In Tienen op de Zuidelijke ring mag je op een stuk richting Leuven 90 km
rijden want er staat een rood bord met 90. In de andere richting staat een
bord met 70 en daar een streep door, dus 70!!, I" ben nog geen enkel bord
met 70 tegen gekomen dat verwijderd werd...en dat na meer dan 4 maanden!

Guy Vanvuchelen

Op 15-mei-2017 16:00 schreef "Marc Gemis" :

welke van de tientallen ? :-)  http://www.openstreetmap.org/
user/Ilona_S/history
N16 is al gecorrigeerd, tenminste waar ik zeker weet dat het nog 90 is.

Via Joost te weten gekomen dat dit BeMobile is die AWV data gebruikt.
We hebben nu rechtstreeks contact opgenomen met hen.

Er is hier ook wat op de mailing list gepasseerd bij de vorige 90->70
discussie

m.

2017-05-15 15:53 GMT+02:00 Glenn Plas :
> changeset ID ?
>
> Dit is altijd zo frustrerend... doe-maar-op-mappers met
> ik-heb-mijn-eigen-regels voor OSM
>
> Glenn
>
>
> On 15-05-17 12:24, Marc Gemis wrote:
>> Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
>> km/h gebracht.
>> Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
>> vervangen zonder lokale kennis.
>> Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
>> wat wijzigingen gedaan
>>
>> Op mijn Nederlandstalige changeset comment, reageerde ze in het Engels.
>>
>> mvg
>>
>> m
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] (no subject)

[Marc Gemis]

welke van de tientallen ? :-)  http://www.openstreetmap.org/user/Ilona_S/history
N16 is al gecorrigeerd, tenminste waar ik zeker weet dat het nog 90 is.

Via Joost te weten gekomen dat dit BeMobile is die AWV data gebruikt.
We hebben nu rechtstreeks contact opgenomen met hen.

Er is hier ook wat op de mailing list gepasseerd bij de vorige 90->70 discussie

m.

2017-05-15 15:53 GMT+02:00 Glenn Plas :
> changeset ID ?
>
> Dit is altijd zo frustrerend... doe-maar-op-mappers met
> ik-heb-mijn-eigen-regels voor OSM
>
> Glenn
>
>
> On 15-05-17 12:24, Marc Gemis wrote:
>> Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
>> km/h gebracht.
>> Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
>> vervangen zonder lokale kennis.
>> Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
>> wat wijzigingen gedaan
>>
>> Op mijn Nederlandstalige changeset comment, reageerde ze in het Engels.
>>
>> mvg
>>
>> m
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[Talk-kosovo] (no subject)

[Arianit Dobroshi]

hi, so who's still reading this?

Digital Globe released hi res imagery, including for Kosovo.

http://blog.digitalglobe.com/news/digitalglobe-satellite-imagery-launch-for-openstreetmap/
___
Talk-kosovo mailing list
Talk-kosovo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-kosovo

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

En effet ils continuent d'ajouter des tas de noeuds, même en doublon de
ceux qui existent, ou de modifier des noeuds existants en mettant dessus
des tags incorrects ou inutiles noms de rue par exemple quand le noeud est
déjà référencé sur une relation suffisante et quand la rue est déjà validée
pour BANO.
Mais cette fois SeFaireConnaitre (ou son employé) demande qu'on ne les
dérange plus. Visibilement il manque un interlocuteur crédible chez ce
prestataire, capable de faire respecter chez lui les engagements pris, y
compris chez les nouveaux employés (à lui de les former, c'est tout de même
son domaine de compétence, qu'il vend aussi comme tel à ses clients en leur
"garantissant" un référencement non seulement exact mais péreine).
De plus ce service semble déjà prêt à supprimer d'OSM certains anciens
clients qui ne voudraient plus continuer avec ce service ou supprimer les
tags utiles permettant de les trouver dans des recherches ciblées sur OSM.
Il pourrait même modifier les infos saisies ou corrigées par ce client
lui-même dans OSM, histoire de faire rebondir leurs ventes.

Ils ne font pas dans le détail: si leur client leur donne un fichier
d'adresses, il les ajoutent toutes sans distinction, et modifient des
données existantes pourtant plus exactes. Et au besoin il remplacera des
tags précis par des tags plus génériques dont il sait qu'ils sont mieux
rendus et plus visibles que d'autres. Et ils ne semblent pas suivre les
évolutions des recommandations et usages (visiblement ils n'utilisent pas
pour cela nos outils open source, qui contiennent divers vérificateurs,
mais leur propre outil créé par Ubiflow.net qui ne connait que ce qui est
dans leur base ou les fichiers plus ou moins précis fournis par leurs
clients, pour lesquels les clients payent justement une prestation vissant
à nettoyer ou affiner ces fichiers, et l'outil et ne s'intéresse pas du
tout au reste.

A ce stade, cet outil ne devrait servir qu'à créer des fichiers .osm à
valider ensuite dans un de nos éditeurs ouverts pour faire le travail de
fusion. Mais leurs employés ne sont pas formés pour apprendre à utiliser
JOSM par exemple et traiter les lots en attente de validation (ou bien les
publier sur un service à part en Open Data, par exemple sur Umap ou
Framacarte). C'est sûr cela leur demande une personne de plus ou délégeur
un temps sufffisant consacré à ça et ils sont plus perturbés par la volonté
de faire vite pour répondre aux client: le travail est fait, maintenant
payez et vous aurez les lots suivants... Mais il n'y a apparemment aucun
système de veille et service après-vente pour régler les problèmes: ils
considèrent que c'est aux contributeurs bénévoles non payés de le faire à
leur place.



Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :

> Bonjour,
>
> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
> cf. https://www.openstreetmap.org/changeset/46490928
>
> Romain
>
>
> Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit
> :
>
>> Bonjour,
>>
>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>> https://www.openstreetmap.org/changeset/34586502 et
>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
>> jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>
>> Romain
>>
>> Le 14 octobre 2015 23:35,  a écrit :
>>
>>> Bien, merci d'améliorer votre processus de production/validation de
>>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>>> en voiture selon OSRM).
>>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
>>> tram doit faire tiquer.
>>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>>> Les deux premiers points c'est votre problème.
>>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>>
>>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>>> http://juvignac.apef-services.fr/contact.html#map
>>> ;-).
>>>
>>> Jean-Yvon
>>>
>>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>>> supp...@sefaireconnaitre.com a écrit :
>>>
>>> Bonjour,
>>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>>
>>> Amandine Nicolas - Ubiflow
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonjour,

Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
cf. https://www.openstreetmap.org/changeset/46490928

Romain

Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit :

> Bonjour,
>
> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
> https://www.openstreetmap.org/changeset/34586502 et
> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
> jour. Et vu l'historique du compte http://www.openstreetmap.org/
> user/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>
> Romain
>
> Le 14 octobre 2015 23:35,  a écrit :
>
>> Bien, merci d'améliorer votre processus de production/validation de
>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>> en voiture selon OSRM).
>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de tram
>> doit faire tiquer.
>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>> Les deux premiers points c'est votre problème.
>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>
>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>> http://juvignac.apef-services.fr/contact.html#map
>> ;-).
>>
>> Jean-Yvon
>>
>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>> supp...@sefaireconnaitre.com a écrit :
>>
>> Bonjour,
>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>
>> Amandine Nicolas - Ubiflow
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] (no subject)

[Marián Kyral]

Ahoj, už by to mělo fungovat.

A budu se muset podívat na tu vrstvu chybných rozcestníku. Taky to je nějaké  
rozbité :-(

Ale k tomu se dostanu asi až zítra večer.

Marian

18. února 2017 7:55:56 SEČ, "Marián Kyral"  napsal:
>Dne 18.2.2017 v 07:10 Zdeněk Pražák napsal(a):
>> zkusil jsem na adrese 
>> http://rawgit.com/osmcz/osmcz/improve-layer-switcher/#
>> přesunout rozcestník PA055
>> Přesouvání však nefunguje, po stisku tlačítka přesunout se nic neděje
>>
>
>Díky. Jsem to chtěl sjednotit, ale asi jsem to přehnal a rozbil to více
>
>než je zdrávo. Zkusím to nějak opravit.
>
>Marián
>
>
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz

-- 
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] (no subject)

[Marián Kyral]

Dne 18.2.2017 v 07:10 Zdeněk Pražák napsal(a):
zkusil jsem na adrese 
http://rawgit.com/osmcz/osmcz/improve-layer-switcher/#

přesunout rozcestník PA055
Přesouvání však nefunguje, po stisku tlačítka přesunout se nic neděje



Díky. Jsem to chtěl sjednotit, ale asi jsem to přehnal a rozbil to více 
než je zdrávo. Zkusím to nějak opravit.


Marián



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

[Talk-cz] (no subject)

[Zdeněk Pražák]

zkusil jsem na adrese http://rawgit.com/osmcz/osmcz/improve-layer-switcher/#
přesunout rozcestník PA055
Přesouvání však nefunguje, po stisku tlačítka přesunout se nic neděje

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

Re: [OSM-talk-be] (no subject)

[Guy Vanvuchelen]

Fijne leerrijke discussie. Daar kun je wat van opsteken. 


Guy Vanvuchelen

-Oorspronkelijk bericht-
Van: Glenn Plas [mailto:gl...@byte-consult.be] 
Verzonden: vrijdag 13 januari 2017 18:16
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] (no subject)

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes 
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik 
> toch iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is nogaltijd een 
auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. 
> Indien dit wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien 
> we masaal landuse vervangen door landcover zal de kaart al maar witter 
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet 
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om 
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies gaan 
mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we gewoon niet 
doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven <sus...@gmail.com
> <mailto:sus...@gmail.com>>:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent
> <mailto:seppe.sant...@stad.gent>>:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
>     <mailto:marc.ge...@gmail.com>]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerec

Re: [OSM-talk-be] (no subject)

[Glenn Plas]

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
> iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is
nogaltijd een auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit
> wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien
> we masaal landuse vervangen door landcover zal de kaart al maar witter
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies
gaan mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we
gewoon niet doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven <sus...@gmail.com
> <mailto:sus...@gmail.com>>:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent
> <mailto:seppe.sant...@stad.gent>>:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
>     <mailto:marc.ge...@gmail.com>]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
> landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat
> landuse=grass niet echt juist is, misschien enkel voor gebieden
> waar graszodes geteeld worden. Maar omda

Re: [OSM-talk-be] (no subject)

[Jasper Michels]

Dank voor je antwoord Marc!

-Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
tussen de autostrades met zwerfvuil.
 Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
iets mooiere landschappen te zien.

-Ik ben zo iemand die momenteel elk rijtje bomen als forest map. Indien de
maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit wel
moet zal ik vrees ik snel de zin om dit te mappen verliezen. (resultaat
naar werk is bij mij nodig)
 Van zodra men ook de landcover zou renderen, is dit een ander verhaal.

-Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
 Zolang men de landcover niet rendert is dit echter onmogelijk. Indien we
masaal landuse vervangen door landcover zal de kaart al maar witter worden.
(ik weet dat we niet mogen mappen voor de kaart, maar niet iedereen is  een
medogenloze databese-addict...)

Op 13 januari 2017 om 17:39 schreef Sus Verhoeven <sus...@gmail.com>:

> Of niet meer durven mappen. ;-)
>
> Sus
>
>
> 2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent>:
>
>> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
>> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog alles
>> verbeteren wat we ooit verkeerd gemapt hebben :-)
>>
>> Seppe
>>
>> -Oorspronkelijk bericht-
>> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
>> Verzonden: vrijdag 13 januari 2017 14:14
>> Aan: OpenStreetMap Belgium
>> Onderwerp: [OSM-talk-be] (no subject)
>>
>> Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat om
>> te lezen :-)
>>
>> Jasper,
>>
>> De oorspronkelijke betekenis van landuse=forest was een bosgebied waarvan
>> het hout gekapt wordt voor industriële doeleinden (bosbouw).
>> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
>> Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
>> onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel niet
>> elk onderhouden bos echt voor bosbouw is.
>>
>> Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op
>> een groepje bomen lijkt als landuse=forest. Er is geen echte tag voor een
>> groepje bomen.
>>
>> Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar met
>> grote struiken via luchtfoto's als landuse=forest worden gemapped.
>>
>> Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
>> struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje grond
>> dat jij aangeeft. scrub wordt ook wel als struikgewas of kreupelhout
>> vertaalt (google translate). Dus dat pas wel.
>>
>> Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest , toch
>> als er meer struiken zijn dan bomen. Maar wat als er dan toch wat onderhoud
>> aan te pas komt ?
>>
>> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
>> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
>> bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het zij zo.
>> Als er genoeg landcover tags gebruikt worden, gaan ze die ook wel tonen.
>>
>> Over het verschil tussen landcover=grass en landuse=grass Landuse zou het
>> gebruik van het land moeten aangeven. Hier wonen mensen, hier werken ze,
>> hier wordt gerecreëerd, hier wordt aan landbouw of veeteelt gedaan, enz.
>> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass niet
>> echt juist is, misschien enkel voor gebieden waar graszodes geteeld worden.
>> Maar omdat het op de kaart getoond wordt, zie je landuse=grass overal
>> verschijnen. (ipv het correctere landcover=grass)
>>
>> Landcover slaat op wat je op de grond vindt.
>>
>> Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
>> polygonen behoren:
>> eentje met een landuse tag een eentje met een landcover tag. De ene geeft
>> de bestemming aan, de andere wat je op de grond vindt. En dan kan je ook
>> nog in sommige gevallen het type recreatie (leisure) of faciliteiten
>> (amenity), etc. daarboven op gaan mappen.
>>
>> Dus voor een park
>> - leisure=park (doen we nu al)
>> - landuse=xxx (nog te definiëren)
>> - dan voor verschillende delen landcover=trees of grass of bushes of
>> sand, rocks, etc.
>> -
>> Momenteel mappen we meestal enkel leisure=park, en misschien al eens een
>> landuse=grass of forest.
>>
>>
>> Bij een woning met tuin
>> - landuse=residential
>> - landcover (zoals bij park) voor de tuin, misschien voor oprit, de plek
>> van het huis, terras

Re: [OSM-talk-be] (no subject)

[Sus Verhoeven]

Of niet meer durven mappen. ;-)

Sus

2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent>:

> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog alles
> verbeteren wat we ooit verkeerd gemapt hebben :-)
>
> Seppe
>
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
>
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat om
> te lezen :-)
>
> Jasper,
>
> De oorspronkelijke betekenis van landuse=forest was een bosgebied waarvan
> het hout gekapt wordt voor industriële doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
> onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel niet
> elk onderhouden bos echt voor bosbouw is.
>
> Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op een
> groepje bomen lijkt als landuse=forest. Er is geen echte tag voor een
> groepje bomen.
>
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar met
> grote struiken via luchtfoto's als landuse=forest worden gemapped.
>
> Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
> struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje grond
> dat jij aangeeft. scrub wordt ook wel als struikgewas of kreupelhout
> vertaalt (google translate). Dus dat pas wel.
>
> Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest , toch
> als er meer struiken zijn dan bomen. Maar wat als er dan toch wat onderhoud
> aan te pas komt ?
>
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
> bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het zij zo.
> Als er genoeg landcover tags gebruikt worden, gaan ze die ook wel tonen.
>
> Over het verschil tussen landcover=grass en landuse=grass Landuse zou het
> gebruik van het land moeten aangeven. Hier wonen mensen, hier werken ze,
> hier wordt gerecreëerd, hier wordt aan landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass niet
> echt juist is, misschien enkel voor gebieden waar graszodes geteeld worden.
> Maar omdat het op de kaart getoond wordt, zie je landuse=grass overal
> verschijnen. (ipv het correctere landcover=grass)
>
> Landcover slaat op wat je op de grond vindt.
>
> Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
> polygonen behoren:
> eentje met een landuse tag een eentje met een landcover tag. De ene geeft
> de bestemming aan, de andere wat je op de grond vindt. En dan kan je ook
> nog in sommige gevallen het type recreatie (leisure) of faciliteiten
> (amenity), etc. daarboven op gaan mappen.
>
> Dus voor een park
> - leisure=park (doen we nu al)
> - landuse=xxx (nog te definiëren)
> - dan voor verschillende delen landcover=trees of grass of bushes of sand,
> rocks, etc.
> -
> Momenteel mappen we meestal enkel leisure=park, en misschien al eens een
> landuse=grass of forest.
>
>
> Bij een woning met tuin
> - landuse=residential
> - landcover (zoals bij park) voor de tuin, misschien voor oprit, de plek
> van het huis, terras, e.d. nog andere landcovers Dus hier geen
> landuse=forest om de tuin aan te duiden. Er is geen bosbouw, er is ook geen
> bos om te recreëren, dus waarom landuse=forest ? Dat is taggen voor de
> renderer [1].
>
> Dat is volgens mij het doel van de landcover, om los van het gebruik
> bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest terug
> voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt worden voor
> bossen met een recreatieve of natuurbeschermende bestemming.
>
> Landcovers kunnen nooit overlappen. Ik heb nog niet hard genoeg nagedacht
> over landuses.
>
> Maar daar zijn we nog helemaal niet. En is het nu een zootje :-)
>
> m
>
> p.s.  Een van de problemen waar ik regelmatig mee worstel is dat je goed
> moet nadenken over de betekenis van een woord voor je het kan mappen. Wat
> is een park ? Wat is een tuin ? (of iets heel anders: ) wat is een
> parking/parkeerterrein ? (dit is niet hetzelfde als een
> parkeerplaats)
> p.s.  Ik ben al een half jaar aan het nadenken over dit thema, ik had me
> er vroeger nooit zo bezig gehouden met het mappen van
> landuse/landcover/natural, maar ik zag teveel fouten of gewijzgde
> situtaties en wou weten hoe ik ze kon verbeteren. Dan begin je te lezen
> over het thema, vr

[OSM-talk-be] (no subject)

[Marc Gemis]

Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat
om te lezen :-)

Jasper,

De oorspronkelijke betekenis van landuse=forest was een bosgebied
waarvan het hout gekapt wordt voor industriële doeleinden (bosbouw).
Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel
niet elk onderhouden bos echt voor bosbouw is.

Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op
een groepje bomen lijkt als landuse=forest. Er is geen echte tag voor
een groepje bomen.

Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar
met grote struiken via luchtfoto's als landuse=forest worden gemapped.

Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje
grond dat jij aangeeft. scrub wordt ook wel als struikgewas of
kreupelhout vertaalt (google translate). Dus dat pas wel.

Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest ,
toch als er meer struiken zijn dan bomen. Maar wat als er dan toch wat
onderhoud aan te pas komt ?

Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het
zij zo. Als er genoeg landcover tags gebruikt worden, gaan ze die ook
wel tonen.

Over het verschil tussen landcover=grass en landuse=grass
Landuse zou het gebruik van het land moeten aangeven. Hier wonen
mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
landbouw of veeteelt gedaan, enz.
Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass
niet echt juist is, misschien enkel voor gebieden waar graszodes
geteeld worden. Maar omdat het op de kaart getoond wordt, zie je
landuse=grass overal verschijnen. (ipv het correctere landcover=grass)

Landcover slaat op wat je op de grond vindt.

Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
polygonen behoren:
eentje met een landuse tag een eentje met een landcover tag. De ene
geeft de bestemming aan, de andere wat je op de grond vindt. En dan
kan je ook nog in sommige gevallen het type recreatie (leisure) of
faciliteiten (amenity), etc. daarboven op gaan mappen.

Dus voor een park
- leisure=park (doen we nu al)
- landuse=xxx (nog te definiëren)
- dan voor verschillende delen landcover=trees of grass of bushes of
sand, rocks, etc.
-
Momenteel mappen we meestal enkel leisure=park, en misschien al eens
een landuse=grass of forest.


Bij een woning met tuin
- landuse=residential
- landcover (zoals bij park) voor de tuin, misschien voor oprit, de
plek van het huis, terras, e.d. nog andere landcovers
Dus hier geen landuse=forest om de tuin aan te duiden. Er is geen
bosbouw, er is ook geen bos om te recreëren, dus waarom landuse=forest
? Dat is taggen voor de renderer [1].

Dat is volgens mij het doel van de landcover, om los van het gebruik
bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest
terug voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt
worden voor bossen met een recreatieve of natuurbeschermende
bestemming.

Landcovers kunnen nooit overlappen. Ik heb nog niet hard genoeg
nagedacht over landuses.

Maar daar zijn we nog helemaal niet. En is het nu een zootje :-)

m

p.s.  Een van de problemen waar ik regelmatig mee worstel is dat je
goed moet nadenken over de betekenis van een woord voor je het kan
mappen. Wat is een park ? Wat is een tuin ? (of iets heel anders: )
wat is een parking/parkeerterrein ? (dit is niet hetzelfde als een
parkeerplaats)
p.s.  Ik ben al een half jaar aan het nadenken over dit thema, ik had
me er vroeger nooit zo bezig gehouden met het mappen van
landuse/landcover/natural, maar ik zag teveel fouten of gewijzgde
situtaties en wou weten hoe ik ze kon verbeteren. Dan begin je te
lezen over het thema, vragen op mailing lists te volgen,  en dan ben
je nog niet wijzer.
p.s. Joost, je schreef ooit dat het gemakkelijker wordt als je meer
weet over OSM, maar dat is niet waar, zie de vorige p.s. :-)

[1] toch in de bewoonde wereld, op Antartica is landuse misschien niet nodig
[2] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

2017-01-13 13:24 GMT+01:00 Jasper Michels :
> De discussie ook gelezen.
> Wat voor mij echter niet duidelijk is.
> Hoe tag je niet onderhoud bermen met struiken en enkele kleine boompjes
> (struiken die tot bomen uitgroeien) langs de straat.
> Zoals je nogal veel ziet langs grote wegen, of op het platteland.
> https://www.openstreetmap.org/#map=18/50.84018/3.60314
>
> Momenteel gebruik ik hier: Landuse=forest
> Maar volgens de wiki is dit enkel voor echte bossen.
> Dienen we dan landcover=bushes te gebruiken?
>
> de tag garden vindt ik hiervoor echt niet kunnen.
> Een garden beschouw ik een aangelegd stuk grond, dat 

Re: [Talk-cz] (no subject)

[majka]

Tak je to nový uživatel (07.01.2017) a jedná se o jeho první editace. Jména
zatím dává všude. Není problém si to poznamenat a případně časem opravit.

Beru to tak, že tohle jsou první (a možná i poslední) pokusy, dejme mu
šanci a čas se ozvat... Moje první editace taky nebyla žádná sláva :)

2017-01-11 8:55 GMT+01:00 Marián Kyral :

> Ahoj,
> tak jsem si do RSS čtečky přidal potenciálně podezřelé changesety (
> http://resultmaps.neis-one.org/osm-suspicious-feed?country=190=48;
> mappingdays=10==%3E=10=d=n )
>
> a hned na mne vyskočilo toto:
>
> http://overpass-api.de/achavi/?changeset=44975232
>
> Z louky se stal park. Další pole smazal a udělal tam "Park u domu". V Týně
> nad Vltavou zakreslil "Park u vody". Na komentář k changesetu zatím
> nereagoval.
>
> Co si o tom myslíte?
> Marián
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] (no subject)

[Mikoláš Štrajt]

Pokud skutečně u toho břehu v Týně nevznilkl park (což možné je), tak bych 
to tipoval na Pokemon GO.
(Jsou spekulace, že přidáním parku na mapu v OSM jde přidat místo kde se 
pokémoni spawnují)

-- 
Mikoláš Štrajt / Severák / http://severak.svita.cz/

-- Původní zpráva --
Od: Marián Kyral <mky...@email.cz>
Komu: talk-cz@openstreetmap.org
Datum: 11. 1. 2017 8:56:54
Předmět: [Talk-cz] (no subject)

"Ahoj,
tak jsem si do RSS čtečky přidal potenciálně podezřelé changesety ( http://
resultmaps.neis-one.org/osm-suspicious-feed?country=190=48
=10==%3E=10=d=n )

a hned na mne vyskočilo toto:

http://overpass-api.de/achavi/?changeset=44975232

Z louky se stal park. Další pole smazal a udělal tam "Park u domu". V Týně 
nad Vltavou zakreslil "Park u vody". Na komentář k changesetu zatím 
nereagoval.

Co si o tom myslíte?
Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] (no subject)

[Marián Kyral]

Ahoj,
tak jsem si do RSS čtečky přidal potenciálně podezřelé changesety ( http://
resultmaps.neis-one.org/osm-suspicious-feed?country=190=48
=10==%3E=10=d=n )

a hned na mne vyskočilo toto:

http://overpass-api.de/achavi/?changeset=44975232

Z louky se stal park. Další pole smazal a udělal tam "Park u domu". V Týně 
nad Vltavou zakreslil "Park u vody". Na komentář k changesetu zatím 
nereagoval.

Co si o tom myslíte?
Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-it] (no subject)

[Fabrizio Tambussa]

La raccolta settimanale delle notizie OSM, edizione #332, è adesso
disponibile online in Italiano, come sempre fornisce un riassunto di tutte
le cose che accadono nel mondo Openstreetmap:

http://www.weeklyosm.eu/it/archives/8390

Godetevelo!

Il notiziario settimanale OSM vi è fornito da 
https://wiki.openstreetmap.org/wiki/WeeklyOSM#Languages
e vi ricordiamo che è confezionato senza olio di palma.

Sbiri

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

[Talk-it] (no subject)

[Simone Cortesi]

Ciao,
come già annunciato, Wikimedia Italia ha trasferito i propri uffici a
BASE, in via Bergognone 34.

La nuova sede si trova in uno spazio nato dall'unione di cinque
operatori culturali con lo scopo di sviluppare iniziative orientate
alla cultura, anche secondo i principi open su cui la nostra
associazione si fonda.

Per inaugurare la nuova sede stiamo organizzando un grande evento
aperto a tutti, della durata di due giorni con molti momenti di
incontro, all'interno dei quali si inserisce anche OSMIT.

Venerdì 20 maggio l'intera giornata sarà dedicata all'incontro tra
OpenStreetMap e la pubblica amministrazione.

Sabato 21 maggio la giornata sarà divisa in tre momenti:

 * raduno nazionale di OpenStreetMap Italia, presso BASE Milano
 * presentazione del lavoro svolto dai “wikipediani in residenza”
presso alcuni musei italiani e, a seguire, un mapping party e
un'editathon presso il Museo Leonardo da Vinci di Milano
 * un party, di nuovo a BASE, di inaugurazione della nuova sede, con
buffet aperto a tutti

Vi invito quindi a non perdere questo importante momento di
condivisione e divertimento, durante il quale potrete immergervi nel
mondo di Wikimedia, avvicinarvi a Wikipedia e ai progetti fratelli.

Per segnalare la vostra presenza compilate il modulo a questo link:
https://docs.google.com/forms/d/1A6zacjPQ64wZa5c2jWiEtVhxhbexIaJj_USprmKPbi0/viewform

Consultate il programma e indicate a quali momenti della giornata parteciperete.

-S

PS Qui il programma completo:
http://www.wikimedia.it/wp-content/uploads/2016/05/Wikimedia_OpenContent_programma_rev20160502-1.pdf

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

Re: [Talk-GB] (no subject)

[Gregory]

Could I float the idea of individuals & corporates being distinguished more
in name. Members (individuals) & corporate supporters/partners.

>From Newcastle,
Gregory.
On Mar 6, 2016 7:00 PM, "Brian Prangle"  wrote:

> Hi everyone
>
> I'll be scheduling a concall shortly where we can progress the Articles of
> Association and also hopefully finalise the objectives and name of the
> chapter.
>
> Membership options: the following is offered as a summary of what we might
> do:
>
> 1.Standard membership £5 per year
> Pros: affordable and inclusive
> Cons: doesn't give us a lot of revenue to do things
> 2.Discounts for multiple years purchase e.g. £40 for 12 years
> Pros: front loads income
> Cons: Accounting years complications
> 3. Life Membership  £100
> Pros and cons as for 2 above
> 4. Corporate membership
> SMEs with turnover <£1m, charities and public organisations £25
> Businesses with turnover > £1m  £250
> Pros: gives us revenue and a network of contacts.
> Cons: None I can think of except the amounts might be wrong; and there is
> some opinion we should wait before we invite corporate membership
>
> The controversial question is whether corporate members get a vote - still
> to be decided
>
> Regards
>
> Brian
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] (no subject)

[Brian Prangle]

Hi everyone

I'll be scheduling a concall shortly where we can progress the Articles of
Association and also hopefully finalise the objectives and name of the
chapter.

Membership options: the following is offered as a summary of what we might
do:

1.Standard membership £5 per year
Pros: affordable and inclusive
Cons: doesn't give us a lot of revenue to do things
2.Discounts for multiple years purchase e.g. £40 for 12 years
Pros: front loads income
Cons: Accounting years complications
3. Life Membership  £100
Pros and cons as for 2 above
4. Corporate membership
SMEs with turnover <£1m, charities and public organisations £25
Businesses with turnover > £1m  £250
Pros: gives us revenue and a network of contacts.
Cons: None I can think of except the amounts might be wrong; and there is
some opinion we should wait before we invite corporate membership

The controversial question is whether corporate members get a vote - still
to be decided

Regards

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

Re: [Talk-it] (no subject)

[Maurizio Napolitano]

mmm
Mi sono cancellato il subject e forse si è perso il thread.
Questo va sotto "OpenStreetMap Italia"

2016-02-01 13:39 GMT+01:00 Maurizio Napolitano :
>> Sin dalla sua nascita OSM ha adottato una licenza che non impediva di fare 
>> business sui dati e sui servizi derivati. Negli ultimi anni anche il Governo 
>> Italiano con la IODL ne ha riconosciuto la possibilità con i propri.
>
> Frase un po' forte :)
> Più che la IODL direi di parlare del cad - codice dell'amministrazione
> digitale dove lì è scritto cosa si intende con dati aperti ed è
> espressamente scritto che devono avere una licenza che ne permetta
> l'uso commerciale
>
> La IODL nasce prima della seconda riforma del cad (quella dove si
> parla di open data) e la sua primissima versione poneva il limite al
> riuso commerciale oltre ad un altra serie di punti discutibili
> Nel tempo, grazie alla pressione degli attivisti open data in Italia,
> ha preso una buona direzione.
> Allo stato attuale mi sembra rimanda un ottimo strumento per
> combattere il FUD [1] di alcuni burosauri ma già nelle iniziative a
> livello di PA centrale la scelta è verso la cc-by 4.0
>
> [1] https://it.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt
>
>> Che Wikimedia abbia pensato tutto questo per guadagnarci lo escluderei, al 
>> massimo potrebbe sperare di partecipare con alcune consulenze rientrando in 
>> piccola parte dei costi.
>
> mmm ... su questo avrei qualche dubbio
> Preferirei vedere una spinta verso il riuso aziendale e/o di freelance
> piuttosto che creare un player competitivo sul mercato
> Non mi risulta, ma potrei sbagliare, che OSMF e WMF fanno queste attività
>
>> L'aspetto del business rientra in una visione pù ampia: si cerca di ampliare 
>> la base di chi conosce ed utilizza OSM, tra gli utilizzatori ci saranno 
>> anche aziende e P.A. (l'esperienza dice che c'è una ricaduta positiva per 
>> OSM). Ad oggi la maggior parte dei servizi basati su dati OSM vengono 
>> forniti dall'estero, perchè non desiderare di sviluppare un mercato italiano 
>> dei fornitori di servizi? In questo modo verrebbero creati posti di lavoro e 
>> anche la bilancia commerciale ne avrebbe un piccolissimo beneficio (il 
>> denaro rimarrebbero in Italia).
>
> Certo, ma perchè WMI?
> Ammetto che WMF offre rendering via tile e vector-tiles
> https://www.mediawiki.org/wiki/Maps
>
> Mi concentrerei di più nel affiancare ai coordinatori regionali di WMI
> esperti OSM (magari provinciali vista la particolarità di conoscere il
> territorio).
> Al momento mi sembra che WMI sia più sbilanciata verso Wikipedia e
> progetti fratelli.
> Noto però, come molto piacere, molta energia anche sul tema osm.
>
> Forse cominciare con della formazione interna potrebbe portare a
> maggior risultato.
> Chiaramente sono ipotesi, a far bene dovrei proporli dentro l'associazione.
>
>> [...]
>> Il problema è *come* creare una comunità locale. Mettiamo il caso 
>> riuscissimo a fare un paio di mapping party in zone scoperte, io penserei a 
>> cercare contatti partendo dalla Università, ma comunque ci vuole un minimo 
>> di base, altrimenti fai centinaia di km e incontri 5 persone :-(
>> Di questo sono io il primo a dire: parliamone.
>
> Il lavoro di Marco Minghini secondo me è da replicare almeno a livello 
> regionale
>
>
>> [...]
>> Quando si tratta di P.A. i tempi sono sempre lunghi. Ad esempio dove siamo 
>> stati insieme hanno appena cambiato il dirigente quando eravamo vicini ad un 
>> accordo (ma si tratta solo di attendere qualche settimana in più)
>
> A me non spiacerebbe proporre l'alter-ego del wikipediano in residenza
> agli uffici cartografici comunali.
> Si tratta di una figura tutta da inventare, ma sarebbe di valore
> aggiunto nell'apertura dei dati, e nella relazione con la comunità di
> openstreetmap.
> Rimando ancora a questo articolo su cui mi sono imbattuto questa mattina
> http://onlinelibrary.wiley.com/doi/10./tgis.12189/full
>
>> [...]
>> Cosa intendi per carenze strutturali? Intanto vedo che mancano strade 
>> provinciali.
>
> ... spesso mancano i nomi delle strade



-- 
Maurizio "Napo" Napolitano
http://de.straba.us

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

[Talk-it] (no subject)

[Maurizio Napolitano]

> Sin dalla sua nascita OSM ha adottato una licenza che non impediva di fare 
> business sui dati e sui servizi derivati. Negli ultimi anni anche il Governo 
> Italiano con la IODL ne ha riconosciuto la possibilità con i propri.

Frase un po' forte :)
Più che la IODL direi di parlare del cad - codice dell'amministrazione
digitale dove lì è scritto cosa si intende con dati aperti ed è
espressamente scritto che devono avere una licenza che ne permetta
l'uso commerciale

La IODL nasce prima della seconda riforma del cad (quella dove si
parla di open data) e la sua primissima versione poneva il limite al
riuso commerciale oltre ad un altra serie di punti discutibili
Nel tempo, grazie alla pressione degli attivisti open data in Italia,
ha preso una buona direzione.
Allo stato attuale mi sembra rimanda un ottimo strumento per
combattere il FUD [1] di alcuni burosauri ma già nelle iniziative a
livello di PA centrale la scelta è verso la cc-by 4.0

[1] https://it.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt

> Che Wikimedia abbia pensato tutto questo per guadagnarci lo escluderei, al 
> massimo potrebbe sperare di partecipare con alcune consulenze rientrando in 
> piccola parte dei costi.

mmm ... su questo avrei qualche dubbio
Preferirei vedere una spinta verso il riuso aziendale e/o di freelance
piuttosto che creare un player competitivo sul mercato
Non mi risulta, ma potrei sbagliare, che OSMF e WMF fanno queste attività

> L'aspetto del business rientra in una visione pù ampia: si cerca di ampliare 
> la base di chi conosce ed utilizza OSM, tra gli utilizzatori ci saranno anche 
> aziende e P.A. (l'esperienza dice che c'è una ricaduta positiva per OSM). Ad 
> oggi la maggior parte dei servizi basati su dati OSM vengono forniti 
> dall'estero, perchè non desiderare di sviluppare un mercato italiano dei 
> fornitori di servizi? In questo modo verrebbero creati posti di lavoro e 
> anche la bilancia commerciale ne avrebbe un piccolissimo beneficio (il denaro 
> rimarrebbero in Italia).

Certo, ma perchè WMI?
Ammetto che WMF offre rendering via tile e vector-tiles
https://www.mediawiki.org/wiki/Maps

Mi concentrerei di più nel affiancare ai coordinatori regionali di WMI
esperti OSM (magari provinciali vista la particolarità di conoscere il
territorio).
Al momento mi sembra che WMI sia più sbilanciata verso Wikipedia e
progetti fratelli.
Noto però, come molto piacere, molta energia anche sul tema osm.

Forse cominciare con della formazione interna potrebbe portare a
maggior risultato.
Chiaramente sono ipotesi, a far bene dovrei proporli dentro l'associazione.

> [...]
> Il problema è *come* creare una comunità locale. Mettiamo il caso riuscissimo 
> a fare un paio di mapping party in zone scoperte, io penserei a cercare 
> contatti partendo dalla Università, ma comunque ci vuole un minimo di base, 
> altrimenti fai centinaia di km e incontri 5 persone :-(
> Di questo sono io il primo a dire: parliamone.

Il lavoro di Marco Minghini secondo me è da replicare almeno a livello regionale


> [...]
> Quando si tratta di P.A. i tempi sono sempre lunghi. Ad esempio dove siamo 
> stati insieme hanno appena cambiato il dirigente quando eravamo vicini ad un 
> accordo (ma si tratta solo di attendere qualche settimana in più)

A me non spiacerebbe proporre l'alter-ego del wikipediano in residenza
agli uffici cartografici comunali.
Si tratta di una figura tutta da inventare, ma sarebbe di valore
aggiunto nell'apertura dei dati, e nella relazione con la comunità di
openstreetmap.
Rimando ancora a questo articolo su cui mi sono imbattuto questa mattina
http://onlinelibrary.wiley.com/doi/10./tgis.12189/full

> [...]
> Cosa intendi per carenze strutturali? Intanto vedo che mancano strade 
> provinciali.

... spesso mancano i nomi delle strade

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

Re: [talk-au] (no subject)

[Andrew Harvey]

Thanks for letting us know.

I checked out one particular changeset, 35907472, looking at the
geometry changes at
http://osmhv.openstreetmap.de/changeset.jsp?id=35907472.

It appears like there is some missing data which they have added
(which is great).

But it also appears that they have removed finer details (which seem
legitimate when comparing against the aerial imagery) of other
existing geometry (which is bad, and in my opinion we need to revert
back).

I don't know what we should do about this since some parts of the
changeset appear to be constructive some appear slightly destructive
(no loss of features, just some slight loss of detail).

On 13 December 2015 at 18:24, Marc Gemis  wrote:
> Hallo,
>
> It seems like some Australian mapper (stweb) [1] is reaching out for
> help on the forum [2]. One of his complaints is the number of nodes
> used to trace lakes, beaches, etc. He did several "simplifications" in
> his last changesets [3]. I don't know how the Australian community
> thinks about this.
>
> Perhaps it is worthwhile to reach out to him.
>
>
> regards
>
> m
> (from Belgium)
>
>
>
>
> [1] http://www.openstreetmap.org/user/stweb
> [2] http://forum.openstreetmap.org/viewtopic.php?pid=566043#p566043
> [3] http://www.openstreetmap.org/user/stweb/history#map=6/-33.591/151.597
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] (no subject)

[Warin]

I have left a comment on his last change set .. suggesting not to reduce detail.

And that the new LPI information is good for park boundaries too.


On 13/12/2015 8:23 PM, Andrew Harvey wrote:

Thanks for letting us know.

I checked out one particular changeset, 35907472, looking at the
geometry changes at
http://osmhv.openstreetmap.de/changeset.jsp?id=35907472.

It appears like there is some missing data which they have added
(which is great).

But it also appears that they have removed finer details (which seem
legitimate when comparing against the aerial imagery) of other
existing geometry (which is bad, and in my opinion we need to revert
back).

I don't know what we should do about this since some parts of the
changeset appear to be constructive some appear slightly destructive
(no loss of features, just some slight loss of detail).

On 13 December 2015 at 18:24, Marc Gemis  wrote:

Hallo,

It seems like some Australian mapper (stweb) [1] is reaching out for
help on the forum [2]. One of his complaints is the number of nodes
used to trace lakes, beaches, etc. He did several "simplifications" in
his last changesets [3]. I don't know how the Australian community
thinks about this.

Perhaps it is worthwhile to reach out to him.


regards

m
(from Belgium)




[1] http://www.openstreetmap.org/user/stweb
[2] http://forum.openstreetmap.org/viewtopic.php?pid=566043#p566043
[3] http://www.openstreetmap.org/user/stweb/history#map=6/-33.591/151.597

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

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



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

[talk-au] (no subject)

[Marc Gemis]

Hallo,

It seems like some Australian mapper (stweb) [1] is reaching out for
help on the forum [2]. One of his complaints is the number of nodes
used to trace lakes, beaches, etc. He did several "simplifications" in
his last changesets [3]. I don't know how the Australian community
thinks about this.

Perhaps it is worthwhile to reach out to him.


regards

m
(from Belgium)




[1] http://www.openstreetmap.org/user/stweb
[2] http://forum.openstreetmap.org/viewtopic.php?pid=566043#p566043
[3] http://www.openstreetmap.org/user/stweb/history#map=6/-33.591/151.597

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonjour,

J'ai pointé l'ajout de deux doublons (magasins Decathlon)
https://www.openstreetmap.org/changeset/34586502 et
http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
jour. Et vu l'historique du compte
http://www.openstreetmap.org/user/SeFaireConnaitre, il y a ailleurs
d'autres doublons similaires.

Romain

Le 14 octobre 2015 23:35,  a écrit :

> Bien, merci d'améliorer votre processus de production/validation de
> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
> en voiture selon OSRM).
> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de tram
> doit faire tiquer.
> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
> Les deux premiers points c'est votre problème.
> Le troisième aussi mais c'est surtout celui qui nous concerne.
>
> Pour votre pénitence, vous leur proposerez une alternative à ceci :
> http://juvignac.apef-services.fr/contact.html#map
> ;-).
>
> Jean-Yvon
>
> Le 14/10/2015 09:23, Support Sefaireconnaitre -
> supp...@sefaireconnaitre.com a écrit :
>
> Bonjour,
> Merci pour le signalement, j'ai bien repositionné le point de vente.
>
> Amandine Nicolas - Ubiflow
>
>
>
> ___
> 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Support Sefaireconnaitre]

Bonjour,
Merci pour le signalement, j'ai bien repositionné le point de vente.

Amandine Nicolas - Ubiflow

Le 10 octobre 2015 20:52, Jérôme Seigneuret  a
écrit :

> Bonjour j'ai laissé un commentaire sur l'un des changeset.
>
> https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009
>
> Le 31 août 2015 15:30, Support Sefaireconnaitre <
> supp...@sefaireconnaitre.com> a écrit :
>
>> Bonjour,
>>
>> Suite aux différents éléments que vous avez remontés, nous avons lancé
>> des travaux traiter les différents points d'amélioration.
>>
>> Ces travaux visent dans un premier temps à :
>>
>> - nous permettre de traiter les localisations en amont de l'envoi sur OSM.
>> - faibiliser ces localisations et les synchroniser avec BANO (via
>> l'API quand c'est possible et/ou manuellement avec le layer BANO)
>>
>> Nous avons intégré ces travaux à nos différents outils, et nous avons
>> traité une centaine de points de vente, à vocation de test.
>> Nous allons publier ces 100 POI cette semaine et refaire un point
>> suite à cela pour mesurer les progrès et voir les éventuels autres
>> points à traiter.
>>
>> N'hésitez pas à nous faire des retours, on les prendra en compte !
>>
>> bonne journée,
>>
>> Le 17 août 2015 21:40,   a écrit :
>> > Effectivement.
>> > En espérant voir les mêmes progrès sur les autres points soulevés.
>> > Cordialement,
>> >
>> > Jean-Yvon
>> >
>> > Le 17/08/2015 11:59, Support Sefaireconnaitre -
>> supp...@sefaireconnaitre.com
>> > a écrit :
>> >
>> > OK.
>> > c'est fait.
>> > on a retiré les éléments de tracling situés dans les URL.
>> >
>> > Le 14 août 2015 21:30,   a écrit :
>> >
>> > Je prends acte du mea culpa (merci).
>> > Pour la prise en compte, j'attends encore de voir.
>> > À ce jour encore 101 liens pistants "Ubiflow".
>> > Mon critère :
>> > node["website"~"ubiflow"]["website"!~"source=ubiflow"];
>> >
>> > Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
>> > pistes et le travail des fourmis ne servira plus à ce que d'autres
>> soient
>> > pistés à leur insu.
>> >
>> > Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
>> >
>> > Jean-Yvon
>> >
>> > Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
>> >
>> > Bonjour,
>> >
>> > Merci de vos explications sur cette liste quant à la prise en compte des
>> > remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre
>> :) au
>> > sein de celle-ci.
>> >
>> > Brice
>> >
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

Et pas corrigé le format de "website=*" qui doit être une URL complète,
avec le protocole http:// ou https:// approprié ; certes, les navigateurs
masquent le protocole dans la barre d'adresse quand c'est http ou https
(pour le second il utilise une icône de sécurité cliquable pour afficher
l'état du certificat), mais normalement il le conserve quand on copie-colle
depuis la barre d'adresse et il le rend visible en édition.



Autres remarques sur les liens utilisables (pour la sécurité, le respect de
la vie privée, l'accessibilité générale, et les performances à
l'utilisation avec un minimum d'échanges réseau à l'utilisation dans un
navigateur) :

(1) Ne pas oublier non plus "www." dans les noms de domaine canoniques,
s'il est nécessaire pour éviter une redirection immédiate ou une
non-validation d'un certificat de sécurité pour HTTPS (ce n'est pas le cas
ici)

Cela peut paraître redondant pour l'utilisateur, mais pas pour les outils
automatisés de vérification qui risquent d'ignorer le lien totalement en
cas de non-validation. Dans un rendu cartographique avec des icones
cliquables donnant un panneau d'information, cela n'empêche pas du tout ces
panneaux de faire le même traitement que les navigateurs pour **afficher**
un lien simplifié mais malgré tout rendre la cible du lien avec l'URL
complète (comme le font aussi les moteurs de recherche, bien que ceux-ci
utilisent une cible de lien modifiée pour transiter par un redirecteur,
hébergé par le moteur de recherche lui-même et destiné au comptage des
liens suivis et au profilage).

(2) Sur OSM on doit aussi s'interdire d'utiliser des adresses transitant
par des redirecteurs de profilage (y compris les "URL raccourcies" / tiny
URL, hébergés sur des domaines ouverts redirigeant vers des tas de sites
dont des sites malveillants avec des niveaux de sécurité différents : le
nom de domaine final après redirection doit être identifiable directedment
depuis le lien indiqué, et nombre de ces redirecteurs ont une durée de vie
faible, ou peuvent au final ne plus rediriger vers le site voulu) :

Donc merci de vérifier tous les liens avant de les mettre et ne garder que
la cible finale (seule exception : le nom de la page d'accueil par défaut
du site tel que "index.html" ou "index.asp" ou home.html" peut être omis
tant que la page par défaut "/" pour HTTP(S) reste sur le même domaine). En
cas de présence de paramètres de requête (après un "?"), ôter les
paramètres opionnels non indispensables qui ont des valeurs codées
spécifiques au suivi d'une session ou d'un droit d'accès, ne garder que les
paramètres identifiant une page sur le site.

(3) Si le lien final obtenu est seulement temporaire et spécifique à une
session ou à un utilisateur connecté au site, ce lien n'est pas utilisable,
on ne le met pas du tout (exemple, les liens vers des articles de presse
lisibles uniquement par les abonnés : on ne peut mettre que le lien vers la
page publique de résumé ne nécessitant aucune identification préalable).
Même chose sir le lien n'est utilisable qu'après avoir d'abord visité une
autre page du même site.

(4) Ne pas mettre le lien non plus vers une page s'il y a une indication
technique "no robots" demandant de ne pas indexer une page dans un moteur
de recherche, chercher plutôt une page indexable (cela interdit notamment
de mentionner les liens vers des pages d'annuaires de sites, très souvent
publicitaires). Cette vérification peut être automatisée, de tels liens
pourraient être supprimés automatiquement d'OSM s'ils sont présents dans la
base.

(5) Et sur les sites HTTPS, vérifier la validité des certificats utilisés :
un navigateur moderne ne devrait afficher aucune alerte de sécurité
demandant à l'utilisateur de vérifier manuellement l'émetteur ou d'accepter
un founisseur PKI non reconnu comme stable et sûr, ou d'accepter une
certificat expiré ou limité à un autre sous-domaine que celui pour lequel
le certificat a été signé (exemple lien avec "www2." alors que le
certificat ne signe que le sous-domaine "www." et aucun autre
sous-domaine). Sinon demander à l'administrateur du site de corriger en
installant de nouveaux certificats sur le site pour inclure les
sous-domaines manquants ou renouveler la signature chez son prestataire
PKI, ou corriger le sous-domaine approprié dans le lien public.

Ce genre de choses devrait être documenté sur le wiki d'OSM en tant que
règles de bonne conduite pour les liens acceptables.

Le 14 octobre 2015 09:23, Support Sefaireconnaitre <
supp...@sefaireconnaitre.com> a écrit :

> Bonjour,
> Merci pour le signalement, j'ai bien repositionné le point de vente.
>
> Amandine Nicolas - Ubiflow
>
> Le 10 octobre 2015 20:52, Jérôme Seigneuret  a
> écrit :
>
>> Bonjour j'ai laissé un commentaire sur l'un des changeset.
>>
>> https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009
>>
>> Le 31 août 2015 15:30, Support Sefaireconnaitre <
>> supp...@sefaireconnaitre.com> a écrit :
>>
>>> Bonjour,
>>>
>>> 

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Bien, merci d'améliorer votre processus de production/validation de 
données afin d'éviter de placer un lieu à 1,3 km de son lieu réel 
(distance en voiture selon OSRM).
Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de 
tram doit faire tiquer.

Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
Les deux premiers points c'est votre problème.
Le troisième aussi mais c'est surtout celui qui nous concerne.

Pour votre pénitence, vous leur proposerez une alternative à ceci :
http://juvignac.apef-services.fr/contact.html#map
;-).

Jean-Yvon

Le 14/10/2015 09:23, Support Sefaireconnaitre - 
supp...@sefaireconnaitre.com a écrit :

Bonjour,
Merci pour le signalement, j'ai bien repositionné le point de vente.

Amandine Nicolas - Ubiflow



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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

Au passage, les tags ne sont pas bons. Dans l'état c'est juste un
"office=company" avec un nom (mais aucune indication de l'activité réelle,
même pas une description à défaut de trouver un tag approprié), un
téléphone une page Facebook et un compte twitter.

Mais là le website n'est pas valide (ce n'est pas une URL sans le préfixe
"http(s)://").

Il est fort probable que le client n'a pasz indiqué son adresse exacte et
qu'il s'est situé "à peu près" sur cette station de RER, mais il n'y a eu
aucune rélle validation de l'adresse qui reste à chercher parmi les rues
autour, ce qui est complètement à côté de l'objectif d'une géolocalisation.
Polluer ainsi une station RER, c'est manifestement une tenative de se
positionner dessus pour faire de la publicité gratuite et cacher en fait
cette gare. Si son client ne veut pas donner d'adresse précise (même s'il
indique téléphone ou des sites web de contact), il n'a rien à faire dans
OSM où les éléments sont obligatoirement géolocalisés.

Il ne manquerait plus que "SeFaireConnaitre" prenne un contrat avec McDo ou
Quick ou autres pour mettre des noeuds dans toutes les gares des villes où
ils ont des restaurants, même s'ils ne sont pas présents dans ces gares
mais ont louent juste des panneaux publicitaires indiquant la direction à
300 mètres de là et 5 rues plus loin.

Mais là, SeFaireConnaitre n'a eu rien d'autre comme indication que
"Juvignac" et a choisi de se mettre à l'emplacement trouvé dans OSM pour la
gare et son parking. S'il n'a pas d'adresse précise, il doit savoir
***qu'il ne doit RIEN mettre dans OSM***, même si son client l'a payé pour
son  référencement (sans doute pas d'ailleurs pour être présent directement
dans OSM mais dans des annuaires de sites internet, mais SeFaireConnaitre
vend un "pack" et ne fait pas le détail : il lui crée des pages Facebook et
Twitter, lui crée ou héberge une page de site web. A-t-il seulement fait
une inscription de son client dans les pages jaunes sans indiquer
d'adresse? Il n'a même rien demandé à son client pour avoir des précisions.
Une société sans adresse physique est forcément un peu douteuse (le minimum
étant de chercher s'il y a une inscription au RCS pour avoir l'adresse
légale du siège et celle de son établissement principal).


Le 10 octobre 2015 20:52, Jérôme Seigneuret  a
écrit :

> Bonjour j'ai laissé un commentaire sur l'un des changeset.
>
> https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009
>
> Le 31 août 2015 15:30, Support Sefaireconnaitre <
> supp...@sefaireconnaitre.com> a écrit :
>
>> Bonjour,
>>
>> Suite aux différents éléments que vous avez remontés, nous avons lancé
>> des travaux traiter les différents points d'amélioration.
>>
>> Ces travaux visent dans un premier temps à :
>>
>> - nous permettre de traiter les localisations en amont de l'envoi sur OSM.
>> - faibiliser ces localisations et les synchroniser avec BANO (via
>> l'API quand c'est possible et/ou manuellement avec le layer BANO)
>>
>> Nous avons intégré ces travaux à nos différents outils, et nous avons
>> traité une centaine de points de vente, à vocation de test.
>> Nous allons publier ces 100 POI cette semaine et refaire un point
>> suite à cela pour mesurer les progrès et voir les éventuels autres
>> points à traiter.
>>
>> N'hésitez pas à nous faire des retours, on les prendra en compte !
>>
>> bonne journée,
>>
>> Le 17 août 2015 21:40,   a écrit :
>> > Effectivement.
>> > En espérant voir les mêmes progrès sur les autres points soulevés.
>> > Cordialement,
>> >
>> > Jean-Yvon
>> >
>> > Le 17/08/2015 11:59, Support Sefaireconnaitre -
>> supp...@sefaireconnaitre.com
>> > a écrit :
>> >
>> > OK.
>> > c'est fait.
>> > on a retiré les éléments de tracling situés dans les URL.
>> >
>> > Le 14 août 2015 21:30,   a écrit :
>> >
>> > Je prends acte du mea culpa (merci).
>> > Pour la prise en compte, j'attends encore de voir.
>> > À ce jour encore 101 liens pistants "Ubiflow".
>> > Mon critère :
>> > node["website"~"ubiflow"]["website"!~"source=ubiflow"];
>> >
>> > Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
>> > pistes et le travail des fourmis ne servira plus à ce que d'autres
>> soient
>> > pistés à leur insu.
>> >
>> > Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
>> >
>> > Jean-Yvon
>> >
>> > Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
>> >
>> > Bonjour,
>> >
>> > Merci de vos explications sur cette liste quant à la prise en compte des
>> > remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre
>> :) au
>> > sein de celle-ci.
>> >
>> > Brice
>> >
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Jérôme Seigneuret]

Bonjour j'ai laissé un commentaire sur l'un des changeset.

https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009

Le 31 août 2015 15:30, Support Sefaireconnaitre <
supp...@sefaireconnaitre.com> a écrit :

> Bonjour,
>
> Suite aux différents éléments que vous avez remontés, nous avons lancé
> des travaux traiter les différents points d'amélioration.
>
> Ces travaux visent dans un premier temps à :
>
> - nous permettre de traiter les localisations en amont de l'envoi sur OSM.
> - faibiliser ces localisations et les synchroniser avec BANO (via
> l'API quand c'est possible et/ou manuellement avec le layer BANO)
>
> Nous avons intégré ces travaux à nos différents outils, et nous avons
> traité une centaine de points de vente, à vocation de test.
> Nous allons publier ces 100 POI cette semaine et refaire un point
> suite à cela pour mesurer les progrès et voir les éventuels autres
> points à traiter.
>
> N'hésitez pas à nous faire des retours, on les prendra en compte !
>
> bonne journée,
>
> Le 17 août 2015 21:40,   a écrit :
> > Effectivement.
> > En espérant voir les mêmes progrès sur les autres points soulevés.
> > Cordialement,
> >
> > Jean-Yvon
> >
> > Le 17/08/2015 11:59, Support Sefaireconnaitre -
> supp...@sefaireconnaitre.com
> > a écrit :
> >
> > OK.
> > c'est fait.
> > on a retiré les éléments de tracling situés dans les URL.
> >
> > Le 14 août 2015 21:30,   a écrit :
> >
> > Je prends acte du mea culpa (merci).
> > Pour la prise en compte, j'attends encore de voir.
> > À ce jour encore 101 liens pistants "Ubiflow".
> > Mon critère :
> > node["website"~"ubiflow"]["website"!~"source=ubiflow"];
> >
> > Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
> > pistes et le travail des fourmis ne servira plus à ce que d'autres soient
> > pistés à leur insu.
> >
> > Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
> >
> > Jean-Yvon
> >
> > Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
> >
> > Bonjour,
> >
> > Merci de vos explications sur cette liste quant à la prise en compte des
> > remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre
> :) au
> > sein de celle-ci.
> >
> > Brice
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] (no subject)

[Manfred A. Reiter]

The weekly round-up of OSM news, issue # 268, is now available online in
English, giving as always a summary of all things happening in the
openstreetmap world: http://www.weeklyosm.eu Enjoy! weeklyOSM is brought to
you by ... https://wiki.openstreetmap.org/wiki/WeeklyOSM

-- 
## Manfred Reiter - -
## www.weeklyOSM.eu
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-be] Fwd: [Talk-GB] (no subject)

[Marc Gemis]

-- Forwarded message --
From: Manfred A. Reiter <ma.rei...@gmail.com>
Date: Mon, Sep 14, 2015 at 6:21 PM
Subject: [Talk-GB] (no subject)
To: OpenStreetMap Ecuador <talk...@openstreetmap.org>, "
talk...@openstreetmap.org" <talk...@openstreetmap.org>,
talk...@openstreetmap.org


The weekly round-up of OSM news, issue # 268, is now available online in
English, giving as always a summary of all things happening in the
openstreetmap world: http://www.weeklyosm.eu Enjoy! weeklyOSM is brought to
you by ... https://wiki.openstreetmap.org/wiki/WeeklyOSM

-- 
## Manfred Reiter - -
## www.weeklyOSM.eu

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Support Sefaireconnaitre]

Bonjour,

Suite aux différents éléments que vous avez remontés, nous avons lancé
des travaux traiter les différents points d'amélioration.

Ces travaux visent dans un premier temps à :

- nous permettre de traiter les localisations en amont de l'envoi sur OSM.
- faibiliser ces localisations et les synchroniser avec BANO (via
l'API quand c'est possible et/ou manuellement avec le layer BANO)

Nous avons intégré ces travaux à nos différents outils, et nous avons
traité une centaine de points de vente, à vocation de test.
Nous allons publier ces 100 POI cette semaine et refaire un point
suite à cela pour mesurer les progrès et voir les éventuels autres
points à traiter.

N'hésitez pas à nous faire des retours, on les prendra en compte !

bonne journée,

Le 17 août 2015 21:40,   a écrit :
> Effectivement.
> En espérant voir les mêmes progrès sur les autres points soulevés.
> Cordialement,
>
> Jean-Yvon
>
> Le 17/08/2015 11:59, Support Sefaireconnaitre - supp...@sefaireconnaitre.com
> a écrit :
>
> OK.
> c'est fait.
> on a retiré les éléments de tracling situés dans les URL.
>
> Le 14 août 2015 21:30,   a écrit :
>
> Je prends acte du mea culpa (merci).
> Pour la prise en compte, j'attends encore de voir.
> À ce jour encore 101 liens pistants "Ubiflow".
> Mon critère :
> node["website"~"ubiflow"]["website"!~"source=ubiflow"];
>
> Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
> pistes et le travail des fourmis ne servira plus à ce que d'autres soient
> pistés à leur insu.
>
> Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
>
> Jean-Yvon
>
> Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
>
> Bonjour,
>
> Merci de vos explications sur cette liste quant à la prise en compte des
> remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre :) au
> sein de celle-ci.
>
> Brice
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :(, devient SeFaireConnaitre :|

[Support Sefaireconnaitre]

OK.
c'est fait.
on a retiré les éléments de tracling situés dans les URL.

Le 14 août 2015 21:30,  osm.sanspourr...@spamgourmet.com a écrit :
 Je prends acte du mea culpa (merci).
 Pour la prise en compte, j'attends encore de voir.
 À ce jour encore 101 liens pistants Ubiflow.
 Mon critère :
 node[website~ubiflow][website!~source=ubiflow];

 Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
 pistes et le travail des fourmis ne servira plus à ce que d'autres soient
 pistés à leur insu.

 Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.

 Jean-Yvon

 Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :

 Bonjour,

 Merci de vos explications sur cette liste quant à la prise en compte des
 remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre :) au
 sein de celle-ci.

 Brice



 ___
 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Effectivement.
En espérant voir les mêmes progrès sur les autres points soulevés.
Cordialement,

Jean-Yvon

Le 17/08/2015 11:59, Support Sefaireconnaitre - 
supp...@sefaireconnaitre.com a écrit :

OK.
c'est fait.
on a retiré les éléments de tracling situés dans les URL.

Le 14 août 2015 21:30,  osm.sanspourr...@spamgourmet.com a écrit :

Je prends acte du mea culpa (merci).
Pour la prise en compte, j'attends encore de voir.
À ce jour encore 101 liens pistants Ubiflow.
Mon critère :
node[website~ubiflow][website!~source=ubiflow];

Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
pistes et le travail des fourmis ne servira plus à ce que d'autres soient
pistés à leur insu.

Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.

Jean-Yvon

Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :

Bonjour,

Merci de vos explications sur cette liste quant à la prise en compte des
remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre :) au
sein de celle-ci.

Brice



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


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


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :(, devient SeFaireConnaitre :)

[Brice MALLET]

Bonjour,

Merci de vos explications sur cette liste quant à la prise en compte des 
remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre 
:) au sein de celle-ci.


Brice

Le 13/08/2015 17:35, Support Sefaireconnaitre a écrit :

Bonjour,

Comme convenu avec Christian, nous avons lancé des développements sur
les différents points que vous avez listés, pour améliorer la qualité
de nos publications, et vous éviter les différents problèmes qu'elles
ont pu causer.

Nous allons désormais traiter les géolocalisation en amont, pour ne
pas avoir à publier un POI et le déplacer ensuite.
Dans la mesure du possible, les POI seront synchronisés avec la base BAN.
Les doublons seront traités, en suppression ou en fusion.

Il y a du passif concernant les publications que nous avons faites
jusqu'ici, nous allons traiter ces différents POI pour les corriger.

Vous trouverez ci dessous le message que nous avons transmis à
Christian suite à son alerte, et evidemment nous serons plus attentifs
à la liste de diffusion pour mieux traiter les anomalies.
Nous sommes à l'écoute de vos retours et suggestions.
bonne journée

L'équipe SFC

Bonjour Christian,

je prends connaissance de votre mail, et de la liste de discussion,
avec de nouveaux messages depuis le mois de mai.
Des messages et des échanges qui ne sont pas satisfaisant, ni pour la
communauté, et évidemment pas pour nous, c'est un euphémisme.
Très clairement notre souhait n'est pas de nous appuyer sur la
communauté pour faire notre travail, nous voulons être autonomes et
corriger nos erreurs lorsque nous en faisons, quand à polluer les
bases, n'en parlons même pas c'est à l'opposé de notre volonté.

Je prends note d'un certain nombre de points, qui sont à traiter de
notre côté car ils correspondent à la réalité de nos process :
- nous utilisons une référence GPS et pas une référence adresse, à ce
stade, nous ne faisons pas le rapprochement strict, mais a minima,
nous vérifions manuellement la cohérence des données soit avec OSM,
soit avec le cadastre, et positionnons le POI sur le batiment.
je note la sortie de la base BAN qui devrait permettre le faire ce
rapprochement automatique sur une partie des POI.
- le fait que nous créions un POI, pour le corriger immédiatement est
vrai, c'est actuellement notre process, nous allons donc le revoir, et
nous créer des outils pour traiter cela en amont
- la vérification des doublons est intégrée dans nos process, si des
doublons sont créés ce sont des erreurs, et donc je vais faire en
sorte que nous soyons plus attentifs sur ce point.

Nous avons fait beaucoup de modifications suite à vos précédents
retours sur nos process (novembre), pour prendre en compte les
éléments que vous aviez remontés.
Nous avons fait des repasses sur les points que nous avions créés pour
améliorer la géolocalisation lorsqu'elle était mauvaise, cette repasse
est toujours en cours étant donné le volume, à date nous avons 3000
POI, nous sommes repassés sur 1500, 500 restent à traiter, et nous
avons 1000 POI qui n'ont pas été publiés.
Le process auparavant automatique est désormais passé en
semi-automatique, pour intégrer les vérifications, permettre une
géolocalisation de meilleure qualité, et ne pas créer de doublons.
Nous allons continuer à travailler dans ce sens et prendre en compte
vos retours dans nos process.

Par rapport aux retours de la mailing list je retiens les points suivants :
- Des personnes remontent que la qualité de la géolocalisation est
meilleure qu'auparavant, sans éluder les autres problèmes ou les
anomalies restantes, je prends cela plutôt positivement car nous avons
travaillé sur ce point.
- Il y a un problème de process, que nous allons revoir, pour ne pas
créer un point mal geolocalisé et le relocaliser ensuite, afin de vous
éviter le bruit que cela génère.
- les points ne sont pas croisés avec les bases d'adresses, nous
allons travailler sur ce point, notamment avec BAN, pour les adresses
qui ne seraient pas accessibles ou vérifiables via ces bases nous
continuerons sur la géolocalisation GPS, et si nous ne pouvons pas
localiser précisément alors nous ne publierons pas.
- nous avons taggué les url de certains POI sur demande d'un de notre
client qui voulait intégrer le tracking dans ses outils, nous ne le
ferons plus

Voila à date ce que je peux vous dire en termes d'action de notre côté.
Effectivement nous n'avons pas été attentifs aux messages de la
mailing list, nous allons faire en sorte de la surveiller plus
attentivement pour être plus réactifs en cas de probleme, et en tout
cas plus constructifs.
Je vais faire en sorte de lancer le dev de ces outils de notre côté,
sur BANO et sur les traitements amont de géolocalisation, en l'attente
de ces outils je vais suspendre les nouvelles publications.
Nous continuerons à traiter les 500 points sur lesquels nous ne sommes
pas encore repassés.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :(, devient SeFaireConnaitre :|

[osm . sanspourriel]

Je prends acte du mea culpa (merci).
Pour la prise en compte, j'attends encore de voir.
À ce jour encore 101 liens pistants Ubiflow.
Mon critère :
node[website~ubiflow][website!~source=ubiflow];

Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les 
pistes et le travail des fourmis ne servira plus à ce que d'autres 
soient pistés à leur insu.


Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.

Jean-Yvon

Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :

Bonjour,

Merci de vos explications sur cette liste quant à la prise en compte 
des remarques de la communauté des fourmis et ainsi 
VousFaire(re)Connaitre :) au sein de celle-ci.


Brice


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

[OSM-talk-ie] (no subject)

[Martin Costello]

Could I have sheet 23/11NW please.  Murt
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-at] (no subject)

[Martin Raifer]

Falls noch jemand Schwierigkeiten mit dem File hat: Ich habe es
schlussendlich hinbekommen, indem ich im GeoTIFF manuell die
Lambert-Projektion (EPSG:31287) eingestellt habe. Das geht z.B. mit
folgendem gdal_translate Befehl:

  gdal_translate -a_srs EPSG:31287 -co TILED=YES -co
BLOCKXSIZE=128 -co BLOCKYSIZE=128 -co COMPRESS=LZW
dhm_lamb_10m.tif dhm_lamb_10m.fixed.tif

Grüße
Martin

2015-03-19 10:18 GMT+01:00 Martin Raifer tyr@gmail.com:
 z.B. liefert gdallocationinfo dhm_lamb_10m.tif -valonly -wgs84
 15.43753 47.07655
 bei mir eine Höhe von 366m, sie sollte aber eigentlich bei 475 liegen
 (Grazer Schloßberg). Der selbe Befehl mit den Koordinaten 15.43344
 47.07655 (eigentlich mitten in der Mur) liefert dann die gesuchten
 470m.

 Martin

 2015-03-18 19:56 GMT+01:00 Martin Raifer tyr@gmail.com:
 Version 2.8.1. Als verwendete Projektion wird bei mir folgendes
 angezeigt: Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5
 +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel
 +units=m +no_defs). Abweichungen stelle ich auch fest, wenn ich mit
 gdallocationinfo (v1.11.0) Höhen auf dem File abfrage.

 2015-03-18 19:30 GMT+01:00 Werner Macho werner.ma...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi!

 Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und
 entdecke keinen Versatz.

 Grüße
 Werner

 On 03/18/2015 06:51 PM, Martin Raifer wrote:
 10x10m Geländemodell

 wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in
 QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m
 zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas
 falsch? Benutzt QGIS eine inkorrekte Projektion?

 Martin

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)

 iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO
 PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY=
 =RiLC
 -END PGP SIGNATURE-

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

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

Re: [Talk-at] (no subject)

[Martin Raifer]

z.B. liefert gdallocationinfo dhm_lamb_10m.tif -valonly -wgs84
15.43753 47.07655
bei mir eine Höhe von 366m, sie sollte aber eigentlich bei 475 liegen
(Grazer Schloßberg). Der selbe Befehl mit den Koordinaten 15.43344
47.07655 (eigentlich mitten in der Mur) liefert dann die gesuchten
470m.

Martin

2015-03-18 19:56 GMT+01:00 Martin Raifer tyr@gmail.com:
 Version 2.8.1. Als verwendete Projektion wird bei mir folgendes
 angezeigt: Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5
 +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel
 +units=m +no_defs). Abweichungen stelle ich auch fest, wenn ich mit
 gdallocationinfo (v1.11.0) Höhen auf dem File abfrage.

 2015-03-18 19:30 GMT+01:00 Werner Macho werner.ma...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi!

 Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und
 entdecke keinen Versatz.

 Grüße
 Werner

 On 03/18/2015 06:51 PM, Martin Raifer wrote:
 10x10m Geländemodell

 wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in
 QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m
 zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas
 falsch? Benutzt QGIS eine inkorrekte Projektion?

 Martin

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)

 iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO
 PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY=
 =RiLC
 -END PGP SIGNATURE-

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

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

[Talk-at] (no subject)

[Thomas Rupprecht]

Hallo,

Seit gestern gibt es unter data.gv.at ein 10x10m Geländemodell und
Gemeindegrenzen.
Geländemodell:
https://www.data.gv.at/katalog/dataset/d88a1246-9684-480b-a480-ff63286b35b7
Gemeindegrenzen:
https://www.data.gv.at/katalog/dataset/4a9c8052-9986-4a77-849e-d37cb3d73209

Die Gemeindegrenzen sehen verdammt gut aus von der Qualität. Es steht zwar
das es generalisierte Daten sind, jedoch wohl nur zur bereinigung von
unterschieden zwischen den Behörden.

Zitat vom ViennaGIS Koordinator nach Rücksprache:
 „Generalisierung“ ist deshalb angeführt, da wir eine Bereinigung von
Sliver-Polygonen an vorrangig Vermessungsbezirks- und Landesgrenzen
vorgenommen haben.

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

Re: [Talk-at] (no subject)

[Martin Raifer]

 10x10m Geländemodell

wow, das ist nicht schlecht!
Allerdings: Wenn ich das tif-File in QGIS öffne, sehe ich einen
(horizontalen) Offset von ca. 30-50m zwischen Höhenmodell und anderen
Vergleichsdaten. Mache ich etwas falsch? Benutzt QGIS eine inkorrekte
Projektion?

Martin

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

Re: [Talk-at] (no subject)

[Martin Raifer]

Version 2.8.1. Als verwendete Projektion wird bei mir folgendes
angezeigt: Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5
+lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel
+units=m +no_defs). Abweichungen stelle ich auch fest, wenn ich mit
gdallocationinfo (v1.11.0) Höhen auf dem File abfrage.

2015-03-18 19:30 GMT+01:00 Werner Macho werner.ma...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi!

 Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und
 entdecke keinen Versatz.

 Grüße
 Werner

 On 03/18/2015 06:51 PM, Martin Raifer wrote:
 10x10m Geländemodell

 wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in
 QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m
 zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas
 falsch? Benutzt QGIS eine inkorrekte Projektion?

 Martin

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)

 iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO
 PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY=
 =RiLC
 -END PGP SIGNATURE-

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

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

Re: [OSM-talk-ie] (no subject)

[Donal Diamond]

On 19 November 2014 17:51, Brian Prangle bpran...@gmail.com wrote:

 Hi

 Can I request sheets 26/25 NW and SW?


Uploaded all 4 in that set.

http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-26-25show_warped=0


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

[OSM-talk-ie] (no subject)

[Brian Prangle]

Hi

Can I request sheets 26/25 NW and SW?

Thanks

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

[Talk-ca] (no subject)

[Ga Delap]

Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure
couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les
importations CanVec mais ne progressent plus depuis un certain temps. Le
présent article propose une façon de réaliser la forêt sans utiliser les abus
de la méthode CanVec.

Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou
visionnez:
http://www.openstreetmap.org/#map=16/46.1875/-74.3750
Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de
type natural:wood. Un simple rectangle de 4 points qu'on peut créer
facilement. Cette tuile peut être vue simplement avec:
http://openstreetmap.org/way/307466266


Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre
éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut
constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette
ligne avec:
http://openstreetmap.org/way/307466267
Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle
utilise l'approche everything but the kitchen sink. La tuile définit non
seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire
encore, ce chemin de 1600 points fait partie d'une relation qui contient
plusieurs dizaines de tels chemins.
Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de
chargement de la page.

Revenons au premier exemple:
http://www.openstreetmap.org/#map=14/46.1875/-74.3750
La forêt est un simple rectangle mais les lacs, les rivières et les chemins se
superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt
suive le contour des lacs et des rivières. Il y a un gain énorme en
simplicité.

Voyons un autre problème des tuiles CanVec:
http://www.openstreetmap.org/#map=17/46.25047/-73.24885
Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur:
http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885
Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités
natual:water, chacune avec le nom Lac Laporte. Pas fort!
Sur la même image, remarquez que le chemin Montée Ouest est fait de 2
segments de couleur différente. C'est parce que ce chemin a été défini de 2
façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments
ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle
rigueur!
C'est un non-sens qu'une entité soit séparée en plusieurs parties parce
qu'elle est à cheval sur une tuile.

Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile
CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer
par des humains.
Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non.
Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous
sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu
d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais
est-ce bien  la bonne façon?
Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en
blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou
autre) pour représenter cette clairière? Une clairière n'est pas un trou dans
une forêt, tout comme une île n'est pas un trou dans un lac.

J'aimerais qu'il y ait une discussion sur les points suivants:
1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la
forêt?
2) si non, peut-on définir une stratégie pour les remplacer (à long terme)
3) Pour les tuiles forêt, devrait-on utiliser un rectangle avec clairière
explicite?
4) Pour les tuiles forêt, devrait-on utiliser un multi-polygone avec trous?

J'espère que cette discussion nous fera progresser vers une carte de meilleure
qualité et une meilleure performance.

dega

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

Re: [OSM-talk-ie] (no subject)

[Donal Diamond]

Uploaded:

http://mapwarper.net/maps/4903

Good luck!

D


On 30 October 2014 17:47, Ian Spillane iantheteac...@gmail.com wrote:

 Can I request map 14/11/SE for townland mapping here?
 ___
 Talk-ie mailing list
 Talk-ie@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ie

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

[Talk-us] (no subject)

[Steven Johnson]

Hello list,

Here’s a quick update on plans for this year’s Geography Awareness Week[1],
which kicks off on 17 Nov. This year’s theme is ‘The Future of Food’ and
we’re targeting colleges/university communities across the country to host
events. If you have an affiliation with a college/university and are
willing to serve as local coordinator for an event, please use the wiki
page[2] to

   1. Add yourself as coordinator, and
   2. Describe plans for your event.

This is a great opportunity for the OpenStreetMap community to foster
greater connections in the academic community to increase awareness of
OpenStreetMap both as a tool for geographic education, as well as social
science and community service.

Suggested activities include mapping groceries, farmers markets, community
gardens, food distribution centers, identification of food deserts. There
may also be things we can digitize for Humanitarian OpenStreetMap Team or
US State Dept’s Mapgive. Your suggestions warmly welcomed.

Also, NGS has granted liberal use of their logos[3] for the event, so
please use them alongside OpenStreetMap logos in your promotional
materials.

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

There are two types of people in the world. Those that can extrapolate from
incomplete data.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-GB] (no subject)

[Lee Galea]

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

[talk-ph] (no subject)

[Pierre Béland]

Following the WHO appeal, I published a new HOT update. 
http://hot.openstreetmap.org/updates/2014-08-08_who_declares_ebola_outbreak_an_international_public_health_emergency


Haiti in 2010
revealed the capacity of the OpenStreetMap community to effectively
support UN agencies and humanitarian NGOs, to quickly produce
detailed maps and offer various services in support of the
humanitarians. And as you saw for Philippines last year, we showed our capacity 
to escalate and respond rapidly to such a dramatic humanitarian crisis.


The OSM 10th Anniversary coincides with the Ebola Activation to fight a deadly 
epidemic, but also other interventions especially in Gaza. We still need the 
help from the internet community to answer these  humanitarian crisis. 

For the Ebola epidemy, we have already covered 24,000 square km (155 km x 155 
km) in three countries. It is also an unprecedented effort with more than 4.5 
million objects modified inthe OSM database so far. And over 700 contributors 
have already responded. 

With this international public health emergency, international humanitarian 
organizations call on the OpenStreetMap community to escalate again is response 
to support groups like MSF, the Red Cross and WHO. 

We invite you to use the task manager to coordinate with the other 
OpenStreetMapcontributors around the world.

http://tasks.hotosm.org/
 
We need also more experienced contributors toimport place names from the GNS 
database. This information is also essential for teams traveling in the area. 
To participate, contact me by providing me with your username OpenStreetMap. We 
will create a special Tasking manager job for this work. 
 
Pierre 
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-us] (no subject)

[Paul Johnson]

On Tue, Jun 24, 2014 at 12:10 AM, Paul Norman penor...@mac.com wrote:


 On 2014-06-23 8:41 PM, Paul Johnson wrote:

 Supreme Court rules for a second time that indian nations are domestic
 dependent nations with inherent sovereign authority.  This affirms that
 indian reservations are higher than the state level, lower than the federal
 level.

 This sounds like the SCOTUS just reaffirmed a case for indian reservations
 being tagged as admin_level=3, if we're tagging for accurate status and not
 for the renderer.  Thoughts?


 http://www2.bloomberglaw.com/public/desktop/document/Mich_v_Bay_Mills_Indian_Cmty_No_12515_US_May_27_2014_Court_Opinio


 Having read through the decision, it's about tribal immunity for acts
 outside Indian* territory.


It is, but both Bay Mills and Kiowa came to this conclusion because of the
domestic dependent nation status.  Similar situations overseas that I can
think of that weren't initially just slapped on a map pretty much wherever
in an effort to divide, conquer and exterminate populations systematically
include Scotland, Wales, Guam, Puerto Rico, the Virgin Islands, etc.


 Do you propose cutting the areas out of the states, i.e. so that IRs are
 not in any admin_level=4 relations? That's what you have to do if you're
 fitting IRs into the admin_level hierarchy.


No, since the states often have agreements for limited jurisdiction over
things like continuing state highways and providing some services,
particularly in less fortunate nations that struggle to provide basic
services themselves.  They're overlapping jurisdictions, typically.

* The term used in the legal case


That's fine, most people who get offended by that term aren't indian
themselves.  Or they're Indian and frustrated with the confusion (which I
get).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] (no subject)

[Paul Johnson]

Supreme Court rules for a second time that indian nations are domestic
dependent nations with inherent sovereign authority.  This affirms that
indian reservations are higher than the state level, lower than the federal
level.

This sounds like the SCOTUS just reaffirmed a case for indian reservations
being tagged as admin_level=3, if we're tagging for accurate status and not
for the renderer.  Thoughts?

http://www2.bloomberglaw.com/public/desktop/document/Mich_v_Bay_Mills_Indian_Cmty_No_12515_US_May_27_2014_Court_Opinio
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] (no subject)

[Paul Norman]

On 2014-06-23 8:41 PM, Paul Johnson wrote:
Supreme Court rules for a second time that indian nations are domestic 
dependent nations with inherent sovereign authority.  This affirms 
that indian reservations are higher than the state level, lower than 
the federal level.


This sounds like the SCOTUS just reaffirmed a case for indian 
reservations being tagged as admin_level=3, if we're tagging for 
accurate status and not for the renderer.  Thoughts?


http://www2.bloomberglaw.com/public/desktop/document/Mich_v_Bay_Mills_Indian_Cmty_No_12515_US_May_27_2014_Court_Opinio


Having read through the decision, it's about tribal immunity for acts 
outside Indian* territory.


Do you propose cutting the areas out of the states, i.e. so that IRs are 
not in any admin_level=4 relations? That's what you have to do if you're 
fitting IRs into the admin_level hierarchy.


* The term used in the legal case
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-bf] (no subject)

[joel zio]

Bonjour Cecile;

2014-06-05 13:47 UTC, SARAMBE Cécile cecilesara...@gmail.com:
 bonjour

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



-- 
*ZIO Asso Henri Joel*
*Tél:(+226) 70-15-89-63*

*Je puis tout, par celui qui me fortifie Phi 4.13*

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

[Talk-GB] (no subject)

[Lee Galea]

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

[Talk-cz] (no subject)

[Pavel Kwiecien]

Ahoj,
chtěl bych upozornit na nové satelitní snímky dostupné přes MapBox 
Satellite. 

http://www.openstreetmap.org/user/lxbarth/diary/21622

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

Re: [Talk-lv] (no subject)

[Pēteris Brūns]

Viss atkarīgs no tā, ko uzskata par ērti, bet tas ko vēlas laikam saucās
objekta centroīds. Ja ir zināmi objekti vai objektu veidi, kuriem vajag
varu kaut kad uzģenerēt db ar LV/LT/EE un vēl bišķiņ ar ~ dienas
aktualitāti ir.


2014-02-11 20:26 GMT+02:00 cuu...@gmail.com cuu...@gmail.com:

 Sveika, liste,

 Endijs interesējas, kā no OSM datiem ērti noskaidrot objekta (liela
 poligona, piem. ezera) koordinātes. Nodēm var vienkārši osm.org ieslēgt
 datu slāni un klikšķināt virsū, bet kā ar poligoniem (centra punktiem
 drošvien)? Idejas?

 Pēteris

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




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