Re: [Talk-cz] Toll values on the D8

[majka]

Našla jsem
http://www.ceskedalnice.cz/pro-ridice/dalnicni-znamky/#zpoplatnene-useky a
vypadá to, že by to mělo být dobře takhle - zpoplatněné úseky jsou tu
uvedené jen:

Zdiby (výjezd 1) – Řehlovice (výjezd 65)
Knínice (výjezd 80) – hranice s Německem (km 92) – *ve směru z Německa bez
poplatku*

On 6 January 2017 at 05:22, Tom Ka  wrote:

> Hello, I can not check that on place, so just short translation to
> czech for others:
>
> Vypada to ze je problem v nastaveni placenych useku pomoci tagu
> toll=yes/no na nove dalnici D8. Je nekdo schopen zkontrolovat v terenu
> pripadne je nekde dostupny hodnoverny zdroj o placeni online?
>
> Diky
>
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] [Talk-us] Beware Pokemon users

[Russ Nelson]

Bill Ricker writes:
 > The PokeStop was at our exact target,  "1899 MIT Observatory site" which is
 > moderately well known (on the park map, in FourSquare). [1]

 > http://www.openstreetmap.org/node/944663159#map=19/42.44109/-71.08359=D

https://www.ingress.com/intel?pll=42.441303,-71.085092

 > This six year old OSM "man made/man mad/Survey point" is the only online
 > reference to this point i've found ... aside from the PokeGo Gym ... for
 > this disk.

 > http://www.openstreetmap.org/changeset/6007454#map=16/42.4433/-71.0844=D

https://www.ingress.com/intel?pll=42.441213,-71.084321

They're Ingress portals, well-known to be the source of Pokestops. You
won't be able to visit those links unless you sign up for Ingress,
just sayin'.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

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

Re: [Talk-us] [OSM-talk] Beware Pokemon users

[Russ Nelson]

Bill Ricker writes:
 > The PokeStop was at our exact target,  "1899 MIT Observatory site" which is
 > moderately well known (on the park map, in FourSquare). [1]

 > http://www.openstreetmap.org/node/944663159#map=19/42.44109/-71.08359=D

https://www.ingress.com/intel?pll=42.441303,-71.085092

 > This six year old OSM "man made/man mad/Survey point" is the only online
 > reference to this point i've found ... aside from the PokeGo Gym ... for
 > this disk.

 > http://www.openstreetmap.org/changeset/6007454#map=16/42.4433/-71.0844=D

https://www.ingress.com/intel?pll=42.441213,-71.084321

They're Ingress portals, well-known to be the source of Pokestops. You
won't be able to visit those links unless you sign up for Ingress,
just sayin'.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

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

Re: [Talk-cz] Toll values on the D8

[Tom Ka]

Hello, I can not check that on place, so just short translation to
czech for others:

Vypada to ze je problem v nastaveni placenych useku pomoci tagu
toll=yes/no na nove dalnici D8. Je nekdo schopen zkontrolovat v terenu
pripadne je nekde dostupny hodnoverny zdroj o placeni online?

Diky


2017-01-06 2:20 GMT+01:00 Jakob Mühldorfer :
> Hi,
>
> Sorry for asking on this list without being informed what you wrote about
> the D8 before, but I wanted to ask about the "toll" values on the D8
> Something seems a bit odd, but maybe it all makes sense.
>
> The first part between Germany and Knínice has the side leaving the country
> toll=yes, and on the other side toll=no
> Is this so people who drive into the country can still exit the highway on
> the first exit, without paying toll?
> If yes, this seems correct
>
> Then follows a part between Knínice and Teplice where both sides are
> toll=no. Is it also correct that anyone can drive without paying toll in
> either direction here?
>
> After Teplice, in one direction, is a tiny part of toll=yes
> Then between Teplice and Vchynice toll values are missing entirely.
> This is the part where something might be wrong.
>
> The rest until Zdiby is toll=yes, then from there to Prague toll=no.
> This seems correct.
>
> Thanks for some information
> Jakob
>
>
> ___
> 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-us] [OSM-talk] Beware Pokemon users

[Toby Murray]

As an ingress player, I can confirm use of ingress data for pokestops and
gyms. Same location descriptions and images submitted by ingress players.
Ingress saw a huge influx of new users when Pokemon Go launched. People
created ingress accounts just so that they could use the ingress Intel map
to find pokestops since (in typical niantic fashion) they did not supply
this useful information to players directly.

The thing that is (MAYBE!) being pulled from OSM is Pokemon spawn locations
along pedestrian features and "biomes" which (I think) are land use area
that spawn specific types of Pokemon. So water ones around rivers, canals
and lakes.

Toby

On Jan 5, 2017 4:20 PM, "Rihards"  wrote:

On 2017.01.05. 22:34, Bill Ricker wrote:
> I have a possible confirmation that PokeGo is using OSM Points of
> Interest to populate features, but not of edit vandalism.
>
> We went onto local hiking trails to document some local science history,
> taking my daughter along for company and having someone under 50 to keep
> an eye on us oldsters. She brought her iPhone and PokeGo of course. (I'd
> expected her to be my photographic "2nd shooter", oh well.)  She
> reported that our destination included both a PokeGo Gym and a PokeStop.
>
> The PokeStop was at our exact target,  "1899 MIT Observatory site" which
> is moderately well known (on the park map, in FourSquare). [1]
>
> But the Gym was a horizontal control benchmark "BLOOM 1934" which is NOT
> in published catalogs (USGS, MASSDOT, Geocache.com) of benchmarks. It
> appears to be part of the MAGS 1934 survey, does not appear to have
> elevation stamped, consistent with other MAGS 1934 disks. Is it not
> cataloged because not required in final control mesh?  [2]
> (I have added the disk name "BLOOM 1934" to the OSM node today.)

reportedly gyms have been populated from their previous game, ingress.
in ingress they got in by people taking photos of objects and sending
those in.

> Both were added in a 6 year old trail-improvement changeset based on GPS
> hiking track. [3]
> (Which was more uptodate than the published park map and was very
> helpful for old guys taking the gradual slope trail! )
>
> This six year old OSM "man made/man mad/Survey point" is the only online
> reference to this point i've found ... aside from the PokeGo Gym ... for
> this disk.
>
> Alas I did not have her take screen-captures to determine if the
> spelling of feature names is exactly OSM's.
>
> (There's another point in that change set i need to discuss with
> OceanVortex ... will DM on OSM.org ...)
>
> [1]
> http://www.openstreetmap.org/node/944663159#map=19/42.
44109/-71.08359=D
>
> [2] http://www.openstreetmap.org/node/944663076
> [3]
> http://www.openstreetmap.org/changeset/6007454#map=16/42.
4433/-71.0844=D
>
>
>
> --
> Bill Ricker
> bill.n1...@gmail.com 
> https://www.linkedin.com/in/n1vux
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


--
 Rihards

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

Re: [OSM-talk] [Talk-us] Beware Pokemon users

[Toby Murray]

As an ingress player, I can confirm use of ingress data for pokestops and
gyms. Same location descriptions and images submitted by ingress players.
Ingress saw a huge influx of new users when Pokemon Go launched. People
created ingress accounts just so that they could use the ingress Intel map
to find pokestops since (in typical niantic fashion) they did not supply
this useful information to players directly.

The thing that is (MAYBE!) being pulled from OSM is Pokemon spawn locations
along pedestrian features and "biomes" which (I think) are land use area
that spawn specific types of Pokemon. So water ones around rivers, canals
and lakes.

Toby

On Jan 5, 2017 4:20 PM, "Rihards"  wrote:

On 2017.01.05. 22:34, Bill Ricker wrote:
> I have a possible confirmation that PokeGo is using OSM Points of
> Interest to populate features, but not of edit vandalism.
>
> We went onto local hiking trails to document some local science history,
> taking my daughter along for company and having someone under 50 to keep
> an eye on us oldsters. She brought her iPhone and PokeGo of course. (I'd
> expected her to be my photographic "2nd shooter", oh well.)  She
> reported that our destination included both a PokeGo Gym and a PokeStop.
>
> The PokeStop was at our exact target,  "1899 MIT Observatory site" which
> is moderately well known (on the park map, in FourSquare). [1]
>
> But the Gym was a horizontal control benchmark "BLOOM 1934" which is NOT
> in published catalogs (USGS, MASSDOT, Geocache.com) of benchmarks. It
> appears to be part of the MAGS 1934 survey, does not appear to have
> elevation stamped, consistent with other MAGS 1934 disks. Is it not
> cataloged because not required in final control mesh?  [2]
> (I have added the disk name "BLOOM 1934" to the OSM node today.)

reportedly gyms have been populated from their previous game, ingress.
in ingress they got in by people taking photos of objects and sending
those in.

> Both were added in a 6 year old trail-improvement changeset based on GPS
> hiking track. [3]
> (Which was more uptodate than the published park map and was very
> helpful for old guys taking the gradual slope trail! )
>
> This six year old OSM "man made/man mad/Survey point" is the only online
> reference to this point i've found ... aside from the PokeGo Gym ... for
> this disk.
>
> Alas I did not have her take screen-captures to determine if the
> spelling of feature names is exactly OSM's.
>
> (There's another point in that change set i need to discuss with
> OceanVortex ... will DM on OSM.org ...)
>
> [1]
> http://www.openstreetmap.org/node/944663159#map=19/42.
44109/-71.08359=D
>
> [2] http://www.openstreetmap.org/node/944663076
> [3]
> http://www.openstreetmap.org/changeset/6007454#map=16/42.
4433/-71.0844=D
>
>
>
> --
> Bill Ricker
> bill.n1...@gmail.com 
> https://www.linkedin.com/in/n1vux
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


--
 Rihards

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

[talk-ph] Fwd: [OSM-talk] weeklyOSM #337 27/12/2016-02/01/2017

[Eugene Alvin Villar]

-- Forwarded message --
From: weeklyteam 
Date: Fri, Jan 6, 2017 at 2:10 AM
Subject: [OSM-talk] weeklyOSM #337 27/12/2016-02/01/2017
To: t...@openstreetmap.org


The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all
things happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email.

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-
produced-in_56718#2/8.6/108.3
___
talk mailing list
t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[santamariense]

Penso que não existam metodologias completamente diferente entre nós.
Existem alguns pormenores em discussão, mas de modo geral a
metodologia parece ser a mesma.

Eu não tenho conhecimentos de POSTGis mas to querendo aprender. Então
se lançarem no Git beleza.

A ideia é que a metodologia seja aberta para que, quem tiver
interesse, possa contrapor, dar sugestões e entender o processo, mas
não necessariamente vai ter que aprender a fazer todo o processo do
zero.

A ideia é (passos):

1. Padronizar uma metodologia (estamos neste momento aqui);
2. Processar os dados de TODOS os municípios, já com formato *.osm
3. Criar na wiki uma tabela de todos os municípios, com um link para
download do arquivo *.OSM e um campo de assinatura. (Exemplo: Escolhi
trabalhar no município X, então baixo o arquivo e, assino meu nome de
usuário para que outra pessoa não conflite em escolher o mesmo
município para edição). Além do que, se terá controle do andamento do
trabalho em escala nacional.
4. Com o arquivo em mãos, vai se trabalhando em cima dele e salvando,
e, quando estiver pronto (todo o município) se faz o upload. Não
poderá ser baixado dados do OSM sobre o arquivo para evitar potenciais
conflitos de edição.

Como a ideia é já entregar o arquivo em formato *.osm pronto para
ajustes finais, quem não tiver interesse em entender o processo de
como se chegou a ele, não precisará aprender a fazer.

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

[Talk-cz] Toll values on the D8

[Jakob Mühldorfer]

Hi,

Sorry for asking on this list without being informed what you wrote 
about the D8 before, but I wanted to ask about the "toll" values on the D8

Something seems a bit odd, but maybe it all makes sense.

The first part between Germany and Knínice has the side leaving the 
country toll=yes, and on the other side toll=no
Is this so people who drive into the country can still exit the highway 
on the first exit, without paying toll?

If yes, this seems correct

Then follows a part between Knínice and Teplice where both sides are 
toll=no. Is it also correct that anyone can drive without paying toll in 
either direction here?


After Teplice, in one direction, is a tiny part of toll=yes
Then between Teplice and Vchynice toll values are missing entirely.
This is the part where something might be wrong.

The rest until Zdiby is toll=yes, then from there to Prague toll=no.
This seems correct.

Thanks for some information
Jakob


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

Re: [Talk-at] Peter Paul

[Liberaler Humanist]

Einerseits: Der Benutzer nimmt auch sinnhafte Bearbeitungen vor. Andererseits: Mit Changeset 12461398 bzw. dem dortigen Kommentar scheint klar, dass die Änderung die Theoriefindung des Benutzers ist. Ich plädiere dafür, den Benutzer darauf hinzuweisen, dass Theoriefindung in der Datenbank nicht sinnhaft ist.
MfG, LH
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-br] duplicidade de projetos

[Peter Krauss]

Oi gente , pelo que entendi o nome oficial ficou sendo "Muncicípios" (tem
também ~1/3 a mais de dados), assim vale fazer o merge de uma página para
outra...  Se ninguém tem ideia do que ainda tem em "CIdades" mas não tem em
"Municipios", o mais simples seria levando ambas para uma planilha, o diff
da Wiki é impossível de usar para essas coisas.



Em 5 de janeiro de 2017 21:31, Lucas Pereira 
escreveu:

> Olá Gerald, boa noite.
>
> Quando eu fiz as análises, fiz primeiramente com as cidades, estabelecendo
> um raio de 10km (se não estiver enganado) ao redor do ponto que identifica
> os agrupamentos urbanos. Como vimos que essa lista poderia não ser
> adequada, realizei outra análise, desta vez, comparando os dados com a área
> dos municípios.
>
> Assim, o projeto foi melhorado e os resultados foram adicionados na
> segunda página. Por uma razão qualquer, não modifiquei a página anterior, e
> acabei criando outra. Mesmo assim, em alguns casos aparecem nomes na lista
> de cidades que não aparecem na lista de municípios, pois haviam municípios
> que tinham vias residenciais desenhadas no interior de seu limite, mas não
> havia mapeamento em suas sedes.
>
> Atenciosamente,
> LucFreitas.
>
> Em 5 de janeiro de 2017 20:57, Gerald Weber  escreveu:
>
>> Oi Turma
>>
>> esses dois projetos na wiki me parecem bem semelhantes?
>>
>> https://wiki.openstreetmap.org/wiki/Cidades_brasileiras_com_
>> mapeamento_deficit%C3%A1rio
>>
>> https://wiki.openstreetmap.org/wiki/Munic%C3%ADpios_brasilei
>> ros_com_mapeamento_deficit%C3%A1rio
>>
>> o que vocês acham?
>>
>> Gerald
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-ie] Are Civil Parishes currently used by Church of Ireland?

[Patrick Matthews]

As far as I know, the direct relationship between civil and CoI parishes
would have come to an end with disestablishment in the 1860s (possibly even
before that in areas like Belfast where there was only a single civil
parish on the Antrim side of the Lagan).

The Representative Church Body Library would probably be the best people to
advise. I've seen a map of CoI parishes in Clogher diocese in Duffy's
Landscapes of South Ulster that would indicate that there has been a good
many mergers or divisions depending on the area.

On Thu, Jan 5, 2017 at 3:51 PM, Rory McCann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Something I've wondered about, but I was never sure. Maybe someone can
> answer.
>
> Are Civil Parishes the same parishes as currently used by the Church of
> Ireland? I know they aren't the same as Roman Catholic parishes. Or has
> the CoI changed their parishes and the CPs aren't the same? Or how does
> it all fit together?
>
> Rory
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJYbmt9AAoJEOrWdmeZivv2h9wH/RWOF8sGdRKNkC1AhZRwkj3C
> RVZsi3U6aROfy6UwjUpBXCS9NvRv9uYduJFpNHlhzfQLh2uL62LBM1iwN2CNm1d4
> YKMk2jnm/RCgzTtoPyg47DX4jeTkktLmQTljwgGUMJ7nJ9zl4aaLKOexd1i+b7zM
> iD7Kb5nwqXfgxXwzVO1arXmR23qC7FZkQNmTiAO5J1sPanvsJEKegVWDQiqNfXSI
> pYCY7NyTAjZYH268o4vXdULTmy9EA2VAbsnSBx8Keaz8qjrXFHkx8KFguBDNuDfs
> AJlOH0zsBVtDongWx2MiFz0DWgw6HXIX/d/a9ejlMPN2ea08qXzGwNwZdh7iv+Q=
> =UfQH
> -END PGP SIGNATURE-
>
> ___
> 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

Re: [Talk-br] duplicidade de projetos

[Lucas Pereira]

Olá Gerald, boa noite.

Quando eu fiz as análises, fiz primeiramente com as cidades, estabelecendo
um raio de 10km (se não estiver enganado) ao redor do ponto que identifica
os agrupamentos urbanos. Como vimos que essa lista poderia não ser
adequada, realizei outra análise, desta vez, comparando os dados com a área
dos municípios.

Assim, o projeto foi melhorado e os resultados foram adicionados na segunda
página. Por uma razão qualquer, não modifiquei a página anterior, e acabei
criando outra. Mesmo assim, em alguns casos aparecem nomes na lista de
cidades que não aparecem na lista de municípios, pois haviam municípios que
tinham vias residenciais desenhadas no interior de seu limite, mas não
havia mapeamento em suas sedes.

Atenciosamente,
LucFreitas.

Em 5 de janeiro de 2017 20:57, Gerald Weber  escreveu:

> Oi Turma
>
> esses dois projetos na wiki me parecem bem semelhantes?
>
> https://wiki.openstreetmap.org/wiki/Cidades_brasileiras_
> com_mapeamento_deficit%C3%A1rio
>
> https://wiki.openstreetmap.org/wiki/Munic%C3%ADpios_
> brasileiros_com_mapeamento_deficit%C3%A1rio
>
> o que vocês acham?
>
> Gerald
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Peter Krauss]

Oi gente, por favor preencham os links vermelhinhos ou acrescentem outros
em que estiverem trabalhando.

https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/CNEFE_2010



Em 5 de janeiro de 2017 20:10, Sérgio V.  escreveu:

> Penso que seria útil se os que já tem uma metodologia em andamento,
>  se pudesse ir começando uma wiki comum (tipo "Proposta de importação de
> endereços no Brasil - CNEFE 2010 ") e descrevendo ali a metodologia
> pensada (mesmo que certamente vá sendo mudada e aprimorada no andar dos
> estudos e experimentos; e por experimentos entendo inicialmente "fora" do
> OSM, para que todos possam ver antes se tá funcionando suficientemente bem,
> e aprovar o uso no Brasil todo).
>
> Poderia ser em tópicos nesta wiki:
>
> -metodologia proposta por santamariense;
>
> -metodologia proposta por papibarrígafo;...
>
> -problemas identificados;
>
> -objeções;
>
> -preferências da comunidade;...
>
>
> Por exemplo, pode-se colocar na wiki também imagens dos resultados para
> que mesmo quem não entende de programação possa acompanhar.
>
> E em passo-a-passo, para mesmo quem não entende muito de programação ou
> processamentoem QGIS.
>
> Eu pessoalmente sou muito limitado em entender de programação.
>
> Assim todos podem enxergar melhor o que uns e outros estão propondo.
>
> Por exemplo, talvez seria útil colocar figuras do QGIS das tags com
> "labels", nas faces, tal como ficaria para importar.
>
> (pensei nisto na questão do Augusto sobre se  < pelo recenseador sempre em ordem de numeração crescente? Digamos, face 001,
> face 002, face 003, etc?>>).
>
> Aí se enxerga a coisa.
>
> Mas acho que tá indo bem a coisa, estamos próximos de chegar lá.
>
>
> Parabéns aos que tão metendo a mão no bagulho.
>
> Eu percebo minhas limitações em programação e processamento.
>
> Mas assim que entender o método, pego e executo.
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] duplicidade de projetos

[Gerald Weber]

Oi Turma

esses dois projetos na wiki me parecem bem semelhantes?

https://wiki.openstreetmap.org/wiki/Cidades_brasileiras_com_mapeamento_deficit%C3%A1rio

https://wiki.openstreetmap.org/wiki/Munic%C3%ADpios_brasileiros_com_mapeamento_deficit%C3%A1rio

o que vocês acham?

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

[OSM-talk] MapContrib's blog

[Guillaume AMAT]

Good evening,

To follow the release of the 1.0 version of MapContrib, we are launching the 
project's blog :)

https://blog.mapcontrib.xyz

It will contain some use cases, release notes, etc. Those about the 1.0 version 
are already published though.

Fire your RSS agregator, you will follow the future news from the project!

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

[OSM-talk-fr] Blog MapContrib

[Guillaume AMAT]

Bonsoir à tous,

À la suite de la sortie de la version 1.0 de MapContrib, nous venons de lancer 
le blog du projet :)

https://blog.mapcontrib.xyz

Il contiendra des cas d'utilisation, les notes de versions, etc. Celles de la 
version 1.0 sont d'ailleurs en ligne en anglais et en français.

Dégainez vos agrégateurs RSS, vous pourrez suivre les futures avancées du 
projet !

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

Re: [Talk-us] Am I wrong to be bothered by this?

[Frederik Ramm]

Hi Tod,

On 01/05/2017 09:26 PM, Tod Fitch wrote:
> I monitor a number of places I’ve done mapping in and suspect I’ll be back to 
> in the future. Today I noticed a change set that covers nearly all of 
> California and Nevada [1].  It looks like this same mapper has even done some 
> changes that span continents [2].
> 
> I guess I prefer geographically compact change sets: It makes me feel that 
> all the changes have actually been looked at. And, at least with how I use 
> the OSM tools I know about, I can quickly take a look and see if I agree or 
> not. In this case, I’ve found a few of the actual ways changed in my area of 
> interest [3] and wonder why the street name was dropped from the way. I guess 
> I need to dig through all the changed ways now and it would just be easier if 
> the change set did not cover so large an area most of which I have no way of 
> doing a site survey to verify.
> 
> Am I out of line to be annoyed when I see a change set like this one?

Well maybe annoyance is too intense as a first reaction. We have rules
about automatic/mechanical edits that say that any edit where the person
making the edit doesn't actually look at the concrete object they're
editing needs to be discussed and approved in advance.

So "I'll find all mini roundabouts in California, look them up on Bing
imagery, and remove them if what I see isn't a mini roundabout" is ok to
do just like that, but "I'll find all mini roundabouts in California and
remove them whoesale because there can't legally be any" is something
that would require prior discussion which obviously hasn't happened in
this case.

But it's quite possible that the user in question didn't know that so
the best thing is to make contact via a changeset discussion and find
out what happened and what the user was doing/thinking. If necessary,
the edit can then be reverted.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Penso que seria útil se os que já tem uma metodologia em andamento,  se pudesse 
ir começando uma wiki comum (tipo "Proposta de importação de endereços no 
Brasil - CNEFE 2010 ") e descrevendo ali a metodologia pensada (mesmo que 
certamente vá sendo mudada e aprimorada no andar dos estudos e experimentos; e 
por experimentos entendo inicialmente "fora" do OSM, para que todos possam ver 
antes se tá funcionando suficientemente bem, e aprovar o uso no Brasil todo).

Poderia ser em tópicos nesta wiki:

-metodologia proposta por santamariense;

-metodologia proposta por papibarrígafo;...

-problemas identificados;

-objeções;

-preferências da comunidade;...


Por exemplo, pode-se colocar na wiki também imagens dos resultados para que 
mesmo quem não entende de programação possa acompanhar.

E em passo-a-passo, para mesmo quem não entende muito de programação ou 
processamentoem QGIS.

Eu pessoalmente sou muito limitado em entender de programação.

Assim todos podem enxergar melhor o que uns e outros estão propondo.

Por exemplo, talvez seria útil colocar figuras do QGIS das tags com "labels", 
nas faces, tal como ficaria para importar.

(pensei nisto na questão do Augusto sobre se  <>).

Aí se enxerga a coisa.

Mas acho que tá indo bem a coisa, estamos próximos de chegar lá.


Parabéns aos que tão metendo a mão no bagulho.

Eu percebo minhas limitações em programação e processamento.

Mas assim que entender o método, pego e executo.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-us] [OSM-talk] Beware Pokemon users

[Rihards]

On 2017.01.05. 22:34, Bill Ricker wrote:
> I have a possible confirmation that PokeGo is using OSM Points of
> Interest to populate features, but not of edit vandalism.
> 
> We went onto local hiking trails to document some local science history,
> taking my daughter along for company and having someone under 50 to keep
> an eye on us oldsters. She brought her iPhone and PokeGo of course. (I'd
> expected her to be my photographic "2nd shooter", oh well.)  She
> reported that our destination included both a PokeGo Gym and a PokeStop.
> 
> The PokeStop was at our exact target,  "1899 MIT Observatory site" which
> is moderately well known (on the park map, in FourSquare). [1]
> 
> But the Gym was a horizontal control benchmark "BLOOM 1934" which is NOT
> in published catalogs (USGS, MASSDOT, Geocache.com) of benchmarks. It
> appears to be part of the MAGS 1934 survey, does not appear to have
> elevation stamped, consistent with other MAGS 1934 disks. Is it not
> cataloged because not required in final control mesh?  [2]
> (I have added the disk name "BLOOM 1934" to the OSM node today.)

reportedly gyms have been populated from their previous game, ingress.
in ingress they got in by people taking photos of objects and sending
those in.

> Both were added in a 6 year old trail-improvement changeset based on GPS
> hiking track. [3]
> (Which was more uptodate than the published park map and was very
> helpful for old guys taking the gradual slope trail! )
> 
> This six year old OSM "man made/man mad/Survey point" is the only online
> reference to this point i've found ... aside from the PokeGo Gym ... for
> this disk.
> 
> Alas I did not have her take screen-captures to determine if the
> spelling of feature names is exactly OSM's.
> 
> (There's another point in that change set i need to discuss with
> OceanVortex ... will DM on OSM.org ...)
> 
> [1]
> http://www.openstreetmap.org/node/944663159#map=19/42.44109/-71.08359=D
> 
> [2] http://www.openstreetmap.org/node/944663076
> [3]
> http://www.openstreetmap.org/changeset/6007454#map=16/42.4433/-71.0844=D
> 
> 
> 
> -- 
> Bill Ricker
> bill.n1...@gmail.com 
> https://www.linkedin.com/in/n1vux 
> 
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
> 


-- 
 Rihards

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

Re: [OSM-talk-fr] Répertoire SIRENE

[Philippe Verdy]

Oh oui la géolocalisation est vraiment très grossière, même quand il y a
une adresse avec un numéro, on peut se retrouver à 300 mètres de là, et
parfois même pas la bonne rue. Quand l'adresse indiquait le nom d'un centre
commercial, là c'est vraiment n'importe où alors que le centre commercial
est bien là (et la pharmacie déjà présente, donc pas à intégrer... pire
même la dite pharmacie peut même déjà avoir un SIREN voire un SIRET et
aucun rapprochement dessus non plus).

Je pense que pour l'instant il n'y a eu aucune tentative de rapprochement
avec l'existant, on aura donc de très nombreux "faux positifs" dans Osmose:
ne pas prendre les points suggérés à la lettre mais bien regarder autour,
en faisant une lecture humaine de l'adresse indiquée et pas une lecture
automatique, les adresses étant aussi un peu approximatives.

J'ai vu des cas avec plusieurs kilomètres d'erreur de géolocalisation. On
dirait que la géolocalisation faite par le SIRENE a été faite de façon
totalement automatique sans aucun contrôle qualité et qu'on nous demande de
le faire. Cette géolocalisation ne sert donc pas à grand chose pour
l'instant (mais l'INSEE semble attendre qu'on fasse le travail pour lui, la
cartographie ce n'est pas son truc alors que l'INSEE n'était tenu que
d'enregistrer les identités et adresses légales; il y aurait du y avoir
depuis longtemps une collaboration avec le fisc/cadastre pour affiner tout
ça)

Le 5 janvier 2017 à 17:15, Christian Quest  a
écrit :

> ça mouline dur... plus que 2 fichiers à terminer (Paris et les DOM)
>
> J'ai commencé à documenter sur le wiki: https://wiki.
> openstreetmap.org/wiki/WikiProject_France/data.gouv.fr/Base_SIRENE
>
> Il faut vraiment qu'on se pose et réfléchisse avant de se lancer.
>
> Ma petite expérimentation sur osmose avec les pharmacies montre qu'il y a
> du boulot pour intégrer proprement.
>
>
> Le 5 janvier 2017 à 16:55, Donat ROBAUX  a écrit :
>
>> Bonjour ou plutôt re-bonjour,
>>
>> Ca y est la bête est lâchée https://www.data.gouv.f
>> r/fr/datasets/base-sirene-des-entreprises-et-de-leurs-etabli
>> ssements-siren-siret/
>> La version géocodée est en cours avec la BAN, mais Christian nous en dira
>> surement plus dans un prochain épisode.
>>
>> Donat
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] [OSM-talk] Beware Pokemon users

[Bill Ricker]

I have a possible confirmation that PokeGo is using OSM Points of Interest
to populate features, but not of edit vandalism.

We went onto local hiking trails to document some local science history,
taking my daughter along for company and having someone under 50 to keep an
eye on us oldsters. She brought her iPhone and PokeGo of course. (I'd
expected her to be my photographic "2nd shooter", oh well.)  She reported
that our destination included both a PokeGo Gym and a PokeStop.

The PokeStop was at our exact target,  "1899 MIT Observatory site" which is
moderately well known (on the park map, in FourSquare). [1]

But the Gym was a horizontal control benchmark "BLOOM 1934" which is NOT in
published catalogs (USGS, MASSDOT, Geocache.com) of benchmarks. It appears
to be part of the MAGS 1934 survey, does not appear to have elevation
stamped, consistent with other MAGS 1934 disks. Is it not cataloged because
not required in final control mesh?  [2]
(I have added the disk name "BLOOM 1934" to the OSM node today.)

Both were added in a 6 year old trail-improvement changeset based on GPS
hiking track. [3]
(Which was more uptodate than the published park map and was very helpful
for old guys taking the gradual slope trail! )

This six year old OSM "man made/man mad/Survey point" is the only online
reference to this point i've found ... aside from the PokeGo Gym ... for
this disk.

Alas I did not have her take screen-captures to determine if the spelling
of feature names is exactly OSM's.

(There's another point in that change set i need to discuss with
OceanVortex ... will DM on OSM.org ...)

[1]
http://www.openstreetmap.org/node/944663159#map=19/42.44109/-71.08359=D
[2] http://www.openstreetmap.org/node/944663076
[3]
http://www.openstreetmap.org/changeset/6007454#map=16/42.4433/-71.0844=D



-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

VItor, só pra confirmar, precisamos saber algo sobre a metodologia de numeração 
das faces:

Seria verdade que, dentro de cada quadra, as faces são percorridas pelo 
recenseador sempre em ordem de numeração crescente? Digamos, face 001, face 
002, face 003, etc?

Se for o caso, tá matada a charada.
Em Quinta-feira, 5 de Janeiro de 2017 20:03, Vítor Rodrigo Dias 
 escreveu:
 

 

Ainda: os recenseadores (e antes, os agentes censitários, na pré-coleta) são 
instruídos a coletar os dados de uma determinada quadra em sentido horário - ou 
seja, sempre com o imóvel à direita do recenseador.
Em qui, 5 de jan de 2017 às 17:00, Vítor Rodrigo Dias  
escreveu:

@santamariense, só pra confirmar que a probabilidade do txt refletir a ordem 
real das casas é de 99% Trabalhei no Censo 2010 e os recenseadores foram 
instruídos a respeitar a ordem das casas.
Em qui, 5 de jan de 2017 às 16:27, Peter Krauss  escreveu:

@santamariense,   eu não sou contra a interpolação, acho inclusive que, por ser 
um atributo distinto da numeração praticada (zero risco de adulteração pelo que 
entendi), é sempre lucro em relação ao "NADA" usual.  A demanda pelo Github é 
quanto à  reprodutibilidade da sua metodologia: não dá para ficar batendo papo 
aqui, é preciso mão-na-massa, pelo menos uma amostrinha, e de preferência 
(ajudo a traduzir passos QGis para PostGIS) com código-fonte do processo.
PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh para 
todos fazerem seus testes no mesmo ambiente, sem precisar ficar montando cada 
um a sua base.
PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em Janeiro de 
2015, mas não tinha gente para colaborar como agora.  
https://github.com/lucasmation/osm_cnefe_import



 

Em 5 de janeiro de 2017 15:35, santamariense  escreveu:

@Peter, teremos que documentar tudo. Você quer dizer usar o Git como
repositório de arquivos? A documentação mesmo terá que ser no wiki.

Eu pessoalmente sou a favor do uso das linhas de interpolação também
no sentido de manter uma organização dos pontos. Os números de casas
avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
dos números de uma esquina a outra (achar que uma rua inicia numa
ponta, quando na verdade iniciava em outra). Se isso acontecer fica
muito simples identificar quais números de casas são do CNEFE, pegar a
linha mestre e girar.

Claro, isso é questão de opinião (há pontos favoráveis e
desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
ruas de uma quadra só (e não se sabe o sentido da numeração das casas
daquela cidade) - não necessariamente como addr:interpolation. Talvez
uma fixme.

@Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
ter certeza que a ordem dos elementos no TXT corresponde à ordem real
dos prédios?"  > Isso é muito interessante. Já havia observado em
leitura manual dos dados. Creio que realmente seja a ordem real. O
problema é que essa informação se perde pela metodologia que estamos
astuciando. E fica realmente complicado um ser humano ler aquele monte
de linhas com caracteres esparsos quando se quer realizar um trabalho
a nível nacional.


Estando a source no changeset, é possível fazer uma query no overpass
com base nas tags da changeset, mesmo um objeto já não estando mais em
sua version=1???

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


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



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


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

[Talk-us] Am I wrong to be bothered by this?

[Tod Fitch]

I monitor a number of places I’ve done mapping in and suspect I’ll be back to 
in the future. Today I noticed a change set that covers nearly all of 
California and Nevada [1].  It looks like this same mapper has even done some 
changes that span continents [2].

I guess I prefer geographically compact change sets: It makes me feel that all 
the changes have actually been looked at. And, at least with how I use the OSM 
tools I know about, I can quickly take a look and see if I agree or not. In 
this case, I’ve found a few of the actual ways changed in my area of interest 
[3] and wonder why the street name was dropped from the way. I guess I need to 
dig through all the changed ways now and it would just be easier if the change 
set did not cover so large an area most of which I have no way of doing a site 
survey to verify.

Am I out of line to be annoyed when I see a change set like this one?

[1] https://www.openstreetmap.org/changeset/44914222
[2] https://www.openstreetmap.org/user/Stephen214/history#map=2/44.7/-56.0
[3] https://www.openstreetmap.org/way/437522050/history


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

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Volker Schmidt]

C'è solo l'imbarazzo della scelta. La direzione permette di capire anche la
precisione dei dati GPX, se le tracce sono gruppate nettamente per
direzione corettamente sui due lati di una strada hai una buona probabilità
che le tracce sono affidabili.

On 5 Jan 2017 8:49 p.m., "Martin Koppenhoefer" 
wrote:

>
>
> sent from a phone
>
> > On 5 Jan 2017, at 19:47, Volker Schmidt  wrote:
> >
> > E' standard in JOSM
> > clic destra sul layer GPX tracks, poi "customize track drawing"
>
>
> si, è utile per distinguere la direzione percorsa per esempio per
> individuare sensi unici, ma preferisco la colorazione secondo la velocità
>
> ciao,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[michael spreng]

Hi Mikel

I would like to offer a different view on community friendliness.

On 04/01/17 22:18, Mikel Maron wrote:
> Reverts should be held to the same standard as imports (outside of
> obviously urgent problems). That means a well documented and visible
> plan, community discussion. Rob's comment shows that it is not possible
> for someone eyeing a revert to judge this from a quick look at the data
> or discussion on talk@. Right or wrong, the communication I've seen from
> community members making reverts has left a lot of rough feelings. I
> don't believe that this thread meets a community friendly threshold for
> reverts.
As a caring contributor I checked my vicinity with regard to this edit.
After all, it touches all borders. This wastes a lot of time and is not
an activity I like. It was not announced on our local mailing list
talk-ch. Therefore I find this forced edit not community friendly.
> 
> Can we hold off on the current revert regime across the board until we
> have as good guidance and practice in place as we have for Imports?
For the above reason, and reasons mentioned in other posts, I fully
support the good work of the DWG. If people go ahead irresponsibly they
should be sent back in order to keep OSM a place to contribute, and not
just fix data dumps.

Michael


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

[OSM-talk-fr] OpenDataHG - données du réseau Arc-en-ciel des bus de la Haute-Garonne

[lenny.libre]

Bonjour,
Je vous transmet, ci-dessous, le message du CD31 qui vient de mettre à 
dispo les données des lignes régulières ; les Points d'arrêt des lignes 
des transports scolaires étaient déjà sur le site 
https://data.haute-garonne.fr/explore/dataset/points-darret-des-transports-scolaires/


Il sont également dispo si certains ont des souhaits de réutilisation 
des données.


Bonne Année 2017 à tous
cordialement
léni

---
Bonjour,

Je fais suite à la conversation que nous avons eu il y a quelques temps déjà.
Comme je m'y suis engagé, je souhaite vous prévenir que les données concernant 
le réseau Arc-en-ciel sont disponibles
sur le portail opendata du département Haute-Garonne :
https://data.haute-garonne.fr/explore/dataset/lignes-regulieres-format-gtfs/

La page propose une pièce jointe à télécharger contenant les informations au 
format GTFS (lignes, arrêts, horaires théoriques de passage).
J'espère que toutes ces informations pourront être utiles à la communauté 
OpenStreetMap.

Toutes les données sont publiées sous Licence Ouverte Etalab, vous pouvez donc 
les réutiliser dans OpenStreetMap sans problème.

N'hésitez pas à me recontacter si vous avez des questions.
Vous pouvez également inviter les utilisateurs de la communauté à soumettre des 
exemples de réutilisations.

Meilleurs vœux pour 2017
Boris
Pôle communication numérique et dialogue citoyen

Conseil départemental de la Haute-Garonne 1, boulevard de la Marquette, 31090 
Toulouse cedex 9 haute-garonne.fr



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

Re: [Talk-at] Peter Paul

[Stefan Tauner]

He did it again...
http://www.openstreetmap.org/changeset/44929255
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Martin Koppenhoefer]

sent from a phone

> On 5 Jan 2017, at 19:47, Volker Schmidt  wrote:
> 
> E' standard in JOSM
> clic destra sul layer GPX tracks, poi "customize track drawing"


si, è utile per distinguere la direzione percorsa per esempio per individuare 
sensi unici, ma preferisco la colorazione secondo la velocità 

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

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Vítor Rodrigo Dias]

Ainda: os recenseadores (e antes, os agentes censitários, na pré-coleta)
são instruídos a coletar os dados de uma determinada quadra em sentido
horário - ou seja, sempre com o imóvel à direita do recenseador.

Em qui, 5 de jan de 2017 às 17:00, Vítor Rodrigo Dias 
escreveu:

> @santamariense, só pra confirmar que a probabilidade do txt refletir a
> ordem real das casas é de 99% Trabalhei no Censo 2010 e os recenseadores
> foram instruídos a respeitar a ordem das casas.
>
> Em qui, 5 de jan de 2017 às 16:27, Peter Krauss 
> escreveu:
>
> @santamariense,   eu não sou contra a interpolação, acho inclusive que,
> por ser um atributo distinto da numeração praticada (zero risco de
> adulteração pelo que entendi), é sempre lucro em relação ao "NADA" usual.
> A demanda pelo Github é quanto à  reprodutibilidade
>  da sua metodologia: não
> dá para ficar batendo papo aqui, é preciso mão-na-massa, pelo menos uma
> amostrinha, e de preferência (ajudo a traduzir passos QGis para *PostGIS*)
> com código-fonte do processo.
>
> PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh
> para todos fazerem seus testes no mesmo ambiente, sem precisar ficar
> montando cada um a sua base.
>
> PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em
> Janeiro de 2015, mas não tinha gente para colaborar como agora.
> https://github.com/lucasmation/osm_cnefe_import
>
>
>
>
>
>
>
> Em 5 de janeiro de 2017 15:35, santamariense 
> escreveu:
>
> @Peter, teremos que documentar tudo. Você quer dizer usar o Git como
> repositório de arquivos? A documentação mesmo terá que ser no wiki.
>
> Eu pessoalmente sou a favor do uso das linhas de interpolação também
> no sentido de manter uma organização dos pontos. Os números de casas
> avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
> dos números de uma esquina a outra (achar que uma rua inicia numa
> ponta, quando na verdade iniciava em outra). Se isso acontecer fica
> muito simples identificar quais números de casas são do CNEFE, pegar a
> linha mestre e girar.
>
> Claro, isso é questão de opinião (há pontos favoráveis e
> desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
> ruas de uma quadra só (e não se sabe o sentido da numeração das casas
> daquela cidade) - não necessariamente como addr:interpolation. Talvez
> uma fixme.
>
> @Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
> aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
> ter certeza que a ordem dos elementos no TXT corresponde à ordem real
> dos prédios?"  > Isso é muito interessante. Já havia observado em
> leitura manual dos dados. Creio que realmente seja a ordem real. O
> problema é que essa informação se perde pela metodologia que estamos
> astuciando. E fica realmente complicado um ser humano ler aquele monte
> de linhas com caracteres esparsos quando se quer realizar um trabalho
> a nível nacional.
>
>
> Estando a source no changeset, é possível fazer uma query no overpass
> com base nas tags da changeset, mesmo um objeto já não estando mais em
> sua version=1???
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Vítor Rodrigo Dias]

@santamariense, só pra confirmar que a probabilidade do txt refletir a
ordem real das casas é de 99% Trabalhei no Censo 2010 e os recenseadores
foram instruídos a respeitar a ordem das casas.

Em qui, 5 de jan de 2017 às 16:27, Peter Krauss 
escreveu:

> @santamariense,   eu não sou contra a interpolação, acho inclusive que,
> por ser um atributo distinto da numeração praticada (zero risco de
> adulteração pelo que entendi), é sempre lucro em relação ao "NADA" usual.
> A demanda pelo Github é quanto à  reprodutibilidade
>  da sua metodologia: não
> dá para ficar batendo papo aqui, é preciso mão-na-massa, pelo menos uma
> amostrinha, e de preferência (ajudo a traduzir passos QGis para *PostGIS*)
> com código-fonte do processo.
>
> PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh
> para todos fazerem seus testes no mesmo ambiente, sem precisar ficar
> montando cada um a sua base.
>
> PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em
> Janeiro de 2015, mas não tinha gente para colaborar como agora.
> https://github.com/lucasmation/osm_cnefe_import
>
>
>
>
>
>
>
> Em 5 de janeiro de 2017 15:35, santamariense 
> escreveu:
>
> @Peter, teremos que documentar tudo. Você quer dizer usar o Git como
> repositório de arquivos? A documentação mesmo terá que ser no wiki.
>
> Eu pessoalmente sou a favor do uso das linhas de interpolação também
> no sentido de manter uma organização dos pontos. Os números de casas
> avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
> dos números de uma esquina a outra (achar que uma rua inicia numa
> ponta, quando na verdade iniciava em outra). Se isso acontecer fica
> muito simples identificar quais números de casas são do CNEFE, pegar a
> linha mestre e girar.
>
> Claro, isso é questão de opinião (há pontos favoráveis e
> desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
> ruas de uma quadra só (e não se sabe o sentido da numeração das casas
> daquela cidade) - não necessariamente como addr:interpolation. Talvez
> uma fixme.
>
> @Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
> aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
> ter certeza que a ordem dos elementos no TXT corresponde à ordem real
> dos prédios?"  > Isso é muito interessante. Já havia observado em
> leitura manual dos dados. Creio que realmente seja a ordem real. O
> problema é que essa informação se perde pela metodologia que estamos
> astuciando. E fica realmente complicado um ser humano ler aquele monte
> de linhas com caracteres esparsos quando se quer realizar um trabalho
> a nível nacional.
>
>
> Estando a source no changeset, é possível fazer uma query no overpass
> com base nas tags da changeset, mesmo um objeto já não estando mais em
> sua version=1???
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Volker Schmidt]

> > Qualcuno ha capito che logica seguono i colori?
>
Guardando le tracce mie nelle vicinanze, è chiaro che si tratta della
direzione. Colori complementari per direzioni opposte.

>
> Mi sembra di ricordare di aver letto parecchio tempo fa un articolo su
> come far apparire questo layer in Josm. Se riesco a recuperarlo magari
> trovo la risposta sui colori.
>
E' standard in JOSM
clic destra sul layer GPX tracks, poi "customize track drawing"

Volker



>
> In questo momento non riesco a trovare l'informazione riguardo al
> layer di josm, l'unica pagina al riguardo che trovo è
>
> https://help.openstreetmap.org/questions/33175/why-tile-
> layer-with-gps-traces-different-from-downloaded-traces
>
> Però sono riuscito a trovare questa pagina di mapbox
>
> https://www.mapbox.com/blog/openstreetmap-gps-layer/
>
> dove nella sezione "Color by direction" si dice che il colore dipende
> dalla direzione.
>
> Non so se la fonte di quello che si vede ora nella mappa principale
> sia la stessa, ma mi sembra di capire che ci sia una correlazione tra
> direzione e colore, mentre tenderei ad escludere una correlazione con
> la velocità (strade diverse parallele tra loro hanno colori uguali
> anche nei casi in cui è presumibile che una strada sia più veloce).
>
> AnyFile
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Marco Barbieri]

A proposito di tracce GPS cumulate, utilissime per disegnare strade e
sentieri, segnalo la Strava heat map, che sicuramente molti conoscono. In
particolare io uso spesso l'editor ID di Strava:
https://strava.github.io/iD/#background=Bing=16.82/10.54233/43.74496

Vedi questo articolo: http://labs.strava.com/slide/

M
-- 
*Marco Barbieri / *Cartografo
marcobarbi...@webmapp.it
www.webmapp.it
+39 050 55 25 74 / +39 347 683 03 13

Webmapp is made by:
Net7
Via Marche 10 / 56123 Pisa
P.Iva e CF 01577590506
CCIAA di Pisa n. 01577590506 del 26/04/2001
Capitale Sociale 10.000,00 €
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Peter Krauss]

@santamariense,   eu não sou contra a interpolação, acho inclusive que, por
ser um atributo distinto da numeração praticada (zero risco de adulteração
pelo que entendi), é sempre lucro em relação ao "NADA" usual.
A demanda pelo Github é quanto à  reprodutibilidade
 da sua metodologia: não dá
para ficar batendo papo aqui, é preciso mão-na-massa, pelo menos uma
amostrinha, e de preferência (ajudo a traduzir passos QGis para *PostGIS*)
com código-fonte do processo.

PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh
para todos fazerem seus testes no mesmo ambiente, sem precisar ficar
montando cada um a sua base.

PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em Janeiro
de 2015, mas não tinha gente para colaborar como agora.
https://github.com/lucasmation/osm_cnefe_import







Em 5 de janeiro de 2017 15:35, santamariense 
escreveu:

> @Peter, teremos que documentar tudo. Você quer dizer usar o Git como
> repositório de arquivos? A documentação mesmo terá que ser no wiki.
>
> Eu pessoalmente sou a favor do uso das linhas de interpolação também
> no sentido de manter uma organização dos pontos. Os números de casas
> avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
> dos números de uma esquina a outra (achar que uma rua inicia numa
> ponta, quando na verdade iniciava em outra). Se isso acontecer fica
> muito simples identificar quais números de casas são do CNEFE, pegar a
> linha mestre e girar.
>
> Claro, isso é questão de opinião (há pontos favoráveis e
> desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
> ruas de uma quadra só (e não se sabe o sentido da numeração das casas
> daquela cidade) - não necessariamente como addr:interpolation. Talvez
> uma fixme.
>
> @Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
> aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
> ter certeza que a ordem dos elementos no TXT corresponde à ordem real
> dos prédios?"  > Isso é muito interessante. Já havia observado em
> leitura manual dos dados. Creio que realmente seja a ordem real. O
> problema é que essa informação se perde pela metodologia que estamos
> astuciando. E fica realmente complicado um ser humano ler aquele monte
> de linhas com caracteres esparsos quando se quer realizar um trabalho
> a nível nacional.
>
>
> Estando a source no changeset, é possível fazer uma query no overpass
> com base nas tags da changeset, mesmo um objeto já não estando mais em
> sua version=1???
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8535/

Disculpe la URL errada en nuestro primer correo electrónico

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8535/

Disculpe la URL errada en nuestro primer correo electrónico

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8535/

Disculpe la URL errada en nuestro primer correo electrónico

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8535/

Disculpe la URL errada en nuestro primer correo electrónico

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Any File]

2017-01-05 18:30 GMT+01:00 Lorenzo "Beba" Beltrami :
> Qualcuno ha capito che logica seguono i colori?

Mi sembra di ricordare di aver letto parecchio tempo fa un articolo su
come far apparire questo layer in Josm. Se riesco a recuperarlo magari
trovo la risposta sui colori.

In questo momento non riesco a trovare l'informazione riguardo al
layer di josm, l'unica pagina al riguardo che trovo è

https://help.openstreetmap.org/questions/33175/why-tile-layer-with-gps-traces-different-from-downloaded-traces

Però sono riuscito a trovare questa pagina di mapbox

https://www.mapbox.com/blog/openstreetmap-gps-layer/

dove nella sezione "Color by direction" si dice che il colore dipende
dalla direzione.

Non so se la fonte di quello che si vede ora nella mappa principale
sia la stessa, ma mi sembra di capire che ci sia una correlazione tra
direzione e colore, mentre tenderei ad escludere una correlazione con
la velocità (strade diverse parallele tra loro hanno colori uguali
anche nei casi in cui è presumibile che una strada sia più veloce).

AnyFile

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

[OSM-talk-ie] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email. 

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-ca] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email. 

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-GB] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email. 

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email. 

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-in] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email. 

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-us] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8535/

We apoligize to send a wrong URL in our last email. 

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[girarsi_liste]

Il 05/01/2017 18:30, Lorenzo "Beba" Beltrami ha scritto:
> Qualcuno ha capito che logica seguono i colori?
> Mi sembra che ci sia uno schema, ma non riesco ad afferrarlo...
> Forse una combinazione di velocità e direzione?
> 
> Lorenzo
> 
> 

Penso anche per utente, ma da quel che vedo delle mie tracce, variano
colore in intensità anche sulla stessa traccia, può essere che varia in
base alla direzione, sulle curve mi pare si evidenzino intensità
diversificate.




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



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

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[santamariense]

@Peter, teremos que documentar tudo. Você quer dizer usar o Git como
repositório de arquivos? A documentação mesmo terá que ser no wiki.

Eu pessoalmente sou a favor do uso das linhas de interpolação também
no sentido de manter uma organização dos pontos. Os números de casas
avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
dos números de uma esquina a outra (achar que uma rua inicia numa
ponta, quando na verdade iniciava em outra). Se isso acontecer fica
muito simples identificar quais números de casas são do CNEFE, pegar a
linha mestre e girar.

Claro, isso é questão de opinião (há pontos favoráveis e
desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
ruas de uma quadra só (e não se sabe o sentido da numeração das casas
daquela cidade) - não necessariamente como addr:interpolation. Talvez
uma fixme.

@Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
ter certeza que a ordem dos elementos no TXT corresponde à ordem real
dos prédios?"  > Isso é muito interessante. Já havia observado em
leitura manual dos dados. Creio que realmente seja a ordem real. O
problema é que essa informação se perde pela metodologia que estamos
astuciando. E fica realmente complicado um ser humano ler aquele monte
de linhas com caracteres esparsos quando se quer realizar um trabalho
a nível nacional.


Estando a source no changeset, é possível fazer uma query no overpass
com base nas tags da changeset, mesmo um objeto já não estando mais em
sua version=1???

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

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Lorenzo "Beba" Beltrami]

Qualcuno ha capito che logica seguono i colori?
Mi sembra che ci sia uno schema, ma non riesco ad afferrarlo...
Forse una combinazione di velocità e direzione?

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

Re: [talk-ph] Updated node density maps

[Eugene Alvin Villar]

Hello all,

I have updated the node density maps for January 1, 2017:
http://wiki.openstreetmap.org/wiki/Philippines/Node_density_maps

Some observations:
- Project NOAH's building mapping tasks for Batangas, Samar, Misamis
Oriental, Aurora, Abra, and Ilocos Norte are visible
- Continued activity in ADB's project in Padre Burgos, Quezon and Santa
Josefa, Agusan del Sur is
also visible
- There's been an increase in mapping activity in Rally's pet project with
the LGUs Mamburao, Occidental Mindoro
- There are some pockets of activity in Caramoan Peninsula and south of
Dumaguete
- Ervin's expedition to Balabac, Palawan is visible

~Eugene


On Sun, Oct 16, 2016 at 1:32 AM, Eugene Alvin Villar 
wrote:

> Hello all,
>
> I have updated the node density maps for October 1, 2016:
> http://wiki.openstreetmap.org/wiki/Philippines/Node_density_maps
>
> Some observations:
> - Project NOAH's building mapping tasks for Zambales, Taguig, Biliran,
> and Misamis Oriental are visible
> - ADB's project in Padre Burgos, Quezon and Santa Josefa, Agusan del Sur
> is also visible
> - There's a lot of activity in Ilocos Sur and Abra (does anybody have any
> idea what this is?)
> - I believe the activity in Occidental Mindoro is due to Rally's pet
> project with the LGUs of Abra de Ilog and Mamburao
> - The Cabanatuan–Dingalan corridor seems to be active
> - The Lingayen–Dagupan area is also active
> - There's also a lot of mapping in Surigao del Norte and Dinagat Islands
>
>
> On Tue, Jul 19, 2016 at 12:04 PM, Eugene Alvin Villar 
> wrote:
>
>> Hello all,
>>
>> I have updated the node density maps for July 1, 2016:
>> http://wiki.openstreetmap.org/wiki/Philippines/Node_density_maps
>>
>> Some observations:
>> - The full impact of Project NOAH's task #1636 in Cavite is now visible
>> - The initial activity of Project NOAH's task #1966 in Zambales can be
>> seen
>> - There are pockets of activity in northern Cebu, eastern Leyte, and
>> Butuan
>>
>> ~Eugene
>>
>>
>> On Tue, Jun 14, 2016 at 9:34 AM, maning sambale <
>> emmanuel.samb...@gmail.com> wrote:
>>
>>> Thanks for this Eugene.  Interesting that Metro Manila is still getting
>>> updated.
>>>
>>> On Mon, Jun 13, 2016 at 9:33 PM, Eugene Alvin Villar 
>>> wrote:
>>> > Hello all,
>>> >
>>> > I've completed the node density maps for 2015 and 2016-to-date:
>>> > http://wiki.openstreetmap.org/wiki/Philippines/Node_density_maps
>>> >
>>> > Some things that I've noticed:
>>> > - 2016 Q1 shows activity due to HOT tasks #1129 (Missing Maps - Leyte),
>>> > #1636 (Project NOAH - Cavite), and #1684 (Project NOAH - Camiguin)
>>> > - 2015 Q4 shows a lot of activity in La Union and Benguet. I don't know
>>> > what's the reason.
>>> > - 2015 Q2 shows the activity from the Luzon roads mapping project
>>> >
>>> > ~Eugene
>>> >
>>> > ___
>>> > talk-ph mailing list
>>> > talk-ph@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-ph
>>> >
>>>
>>>
>>>
>>> --
>>> cheers,
>>> maning
>>> --
>>> "Freedom is still the most radical idea of all" -N.Branden
>>> https://epsg4253.wordpress.com/
>>> http://twitter.com/maningsambale
>>> --
>>>
>>
>>
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-br] RES: Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

A resposta à minha pergunta anterior — se é possível determinar o sentido da 
numeração de uma rua usando o CNEFE — está na página 83 deste documento:
https://international.ipums.org/international/resources/enum_materials_pdf/enum_instruct_br2010a.pdf
Pra resumir: em tese, é possível deduzir o sentido da numeração a partir do TXT 
e dos shapefiles. Se o resultado é confiável são outros quinhentos...


 

Em Quinta-feira, 5 de Janeiro de 2017 16:00, Papibaquígrafo 
 escreveu:
 

 Está claro que a direção das linhas nos shapefiles de face de quadra é 
completamente aleatória, não indicando nem numeração crescente nem 
descrescente. Pois agora eu notei que nos TXTs do CNEFE os numeros de uma mesma 
face às vezes vem em ordem crescente, às vezes decrescente.
Alguém checou se por acaso as duas coisas se compensam? Ou seja, distribuindo 
os números na ordem do TXT ao longo da face na direção que consta no shp, 
obtemos sempre a ordem real dos prédios?

Além disso, notei que no TXT às vezes aparece um endereço S/N entre dois que 
tem número. Nesse caso, dá pra ter certeza que a ordem dos elementos no TXT 
corresponde à ordem real dos prédios?
 

Em Quinta-feira, 5 de Janeiro de 2017 13:45, Peter Krauss 
 escreveu:
 

 Oi gente, que tal consolidar as discussões e decisões de projeto?É impossível 
acompanhar e tirar alguma conclusão mais séria aqui em meio a tantos e-mails 
dispersos e tantos tópicos discutidos pela metade.
Para mim está claro que é um experimento sério de consolidação global de dados, 
e que portanto requer antes um preparo, reprodutível por exemplo com PostGIS, 
para experts em processamento de dados poderem conferir e "assinarem embaixo" 
(eu me incluo nos voluntários), bem como emitirem relatórios mostrando os rumos 
da coisa antes de alterar a base OSM.  O uso dos dados do CNEF e o cruzamento 
com dados do CRP são dos mais relevantes (!), são dados oficiais e atualizados. 
Talvez o mais importante não seja a interpolação (num país onde ainda tem gente 
adotando numeração predial por Numerologia), mas o destaque das inconsistências 
e o registro confiável e definitivo dos dados relativos a faces de quadra.
Se todos aqui são "meio nerd", pode ser direto no Github, 
   https://github.com/OSMBrasil/_NOME_DO_PROJETO_
Qual nome será dado a esse projeto?  (ex. CNEFE2010)





Em 5 de janeiro de 2017 09:35, Reinaldo Neves  escreveu:

Também acredito que interpolação pelos dados do CNEFE vai trazer mais problemas 
que solução. Apenas a título de informação em São Paulo nas cidades que compõem 
a região metropolitana, a capital inclusive, o cep se inicia por zero,  
acredito que seja por isso que observou registros com 7 digítos.   Evidente que 
o problema ocorre na definição do campo CEP com sendo int e não char como é o 
correto.  No arquivo do CNEFE original a informação está correta. 
__ _Reinaldo Neves☎: (11) 3221-3722✉: 
rne...@equacao.com.brhttp://br.linkedin.com/in/ 
rrneveshttps://medium.com/Reinaldo_ Neves De: Papibaquígrafo 
[mailto:agostinho741-1@yahoo. com.br] 
Enviada em: quinta-feira, 5 de janeiro de 2017 07:49
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre addr:interpolation - possibilidades Santamariense, 
Sobre o ponto 1: O trabalho do recenseador não é muito diferente do nosso como 
colaboradores do OSM: você vai a campo e coleta os números da fachada das 
casas. Se falta o número de uma casa, então para todos os efeitos práticos esse 
número não existe: este é o princípio da verificabilidade do OSM ("the truth is 
on the ground"). Portanto, não há nada de errado em pular os endereços que 
constam como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N 
números nesta face" para posterior verificação. Por outro lado, ao adicionar 
interpolações, nós estamos "especulando" a respeito da numeração, o que de 
certa forma até fere o princípio da verificabilidade. E isso pode até mesmo 
introduzir erros e inconsistências. Se o número faltante é o da esquina, a 
interpolação não vai deixar de ser incompleta. Pior que isso, é sabido que 
existem quebras na sequencialidade dos números (acontece na rua em que cresci 
em Porto Alegre). Imagine se você usar um desses números "anômalos" (ou mesmo 
um dado incorreto, algo que há de existir no CNEFE) como base da interpolação!! 
(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número) Em suma, vamos tirar do CNEFE o que o CNEFE nos 
dá, sem especular em cima. Agora, sobre pontos menos importantes: a) Será 
preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se mantenha 
um registro desses deslocamentos, para uso futuro. O workflow 

Re: [OSM-talk-fr] Création suppression d'intercommunalité

[Christian Quest]

Pour aider à y voir clair, voici une liste des communes actuellement à
cheval sur plusieurs EPCI dans OSM:
https://gist.github.com/cquest/eec5f36b779764514b7c70a724e9dddc

Le 5 janvier 2017 à 16:40, Stéphane Péneau  a
écrit :

> A priori, j'ai terminé les Pays de la Loire, je mettrai à jour le wiki
> rapidement.
>
> En Mayenne je n'ai pas trouvé de modifications en 2017, mais certaines de
> 2016 ou 2015 n'avait pas été mises à jour dans Osm.
> Pour vérifier que je n'avais pas d'EPCI qui se chevauchait suite à des
> erreurs ou des oublis de "désactivation", j'ai utilisé la requête
> Overpass-turbo ci-dessous :
> http://overpass-turbo.eu/s/l4h
>
> Il suffit de changer le nom du département sur cette ligne de la requête :
> {{geocodeArea:Loire-Atlantique}}->.searchArea;
>
> Pourquoi a-t-on du ref:INSEE partout sur les EPCI, alors que c'est un
> numéro SIREN ? Même les arrêtés préfectoraux parlent de n° SIREN. Du coup,
> lorsque j'y ai pensé, j'ai remplacé ref:INSEE par ref:SIREN
>
> Pour presque terminer, un exemple de l'incohérence de choisir un node/area
> "place" comme pseudo chef-lieu, au lieu d'indiquer l'emplacement du siège :
> Communauté_de_communes_des_Coëvrons, en Mayenne
> - Le siège est à Châtres-la-Forêt
>  (789 habitants)
> - La commune la plus importante est Évron (7127 habitants), c'est aussi
> elle qui a le plus de membres au conseil communautaire.
> - Le premier président était le maire de Sainte-Suzanne (1333 habitants).
>
> Question à 1€ : Où est le pseudo chef-lieu ?
>
> Au passage, j'ai découvert BANATIC, dont il a été question plusieurs fois
> ici il y a quelques années. Ce n'est toujours pas utilisable ?
> J'imagine que cette base pourrait alimenter Osmose pour nous alerter en
> cas d'erreur ou de manque.
>
> Stf
>
>
> ___
> 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] Répertoire SIRENE

[Christian Quest]

ça mouline dur... plus que 2 fichiers à terminer (Paris et les DOM)

J'ai commencé à documenter sur le wiki:
https://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr/Base_SIRENE

Il faut vraiment qu'on se pose et réfléchisse avant de se lancer.

Ma petite expérimentation sur osmose avec les pharmacies montre qu'il y a
du boulot pour intégrer proprement.


Le 5 janvier 2017 à 16:55, Donat ROBAUX  a écrit :

> Bonjour ou plutôt re-bonjour,
>
> Ca y est la bête est lâchée https://www.data.gouv.
> fr/fr/datasets/base-sirene-des-entreprises-et-de-leurs-
> etablissements-siren-siret/
> La version géocodée est en cours avec la BAN, mais Christian nous en dira
> surement plus dans un prochain épisode.
>
> Donat
>
> ___
> 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: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[Martin Koppenhoefer]

2017-01-05 16:33 GMT+01:00 girarsi_liste :

> Non mi pare di averlo visto passare in lista, ma segnalo è presente una
> voce, non so da quando perchè me ne sono accorto ieri, ovvero quella in
> oggetto.
>


si, è recentissimo (da ieri mi sembra). Sono delle tiles prerenderizzate di
alcune tracce caricate come "pubblico", purtroppo non sono tutte le tracce
ma soltanto quelli più recenti, e spesso sono tracce registrate con
telefonino, o semplificate in altro modo. Possono comunque andar bene per
trovare strade e sopratutto sentieri mancanti.

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

[OSM-talk-fr] Répertoire SIRENE

[Donat ROBAUX]

Bonjour ou plutôt re-bonjour,

Ca y est la bête est lâchée
https://www.data.gouv.fr/fr/datasets/base-sirene-des-entreprises-et-de-leurs-etablissements-siren-siret/
La version géocodée est en cours avec la BAN, mais Christian nous en dira
surement plus dans un prochain épisode.

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

[OSM-talk-ie] Are Civil Parishes currently used by Church of Ireland?

[Rory McCann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Something I've wondered about, but I was never sure. Maybe someone can
answer.

Are Civil Parishes the same parishes as currently used by the Church of
Ireland? I know they aren't the same as Roman Catholic parishes. Or has
the CoI changed their parishes and the CPs aren't the same? Or how does
it all fit together?

Rory
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYbmt9AAoJEOrWdmeZivv2h9wH/RWOF8sGdRKNkC1AhZRwkj3C
RVZsi3U6aROfy6UwjUpBXCS9NvRv9uYduJFpNHlhzfQLh2uL62LBM1iwN2CNm1d4
YKMk2jnm/RCgzTtoPyg47DX4jeTkktLmQTljwgGUMJ7nJ9zl4aaLKOexd1i+b7zM
iD7Kb5nwqXfgxXwzVO1arXmR23qC7FZkQNmTiAO5J1sPanvsJEKegVWDQiqNfXSI
pYCY7NyTAjZYH268o4vXdULTmy9EA2VAbsnSBx8Keaz8qjrXFHkx8KFguBDNuDfs
AJlOH0zsBVtDongWx2MiFz0DWgw6HXIX/d/a9ejlMPN2ea08qXzGwNwZdh7iv+Q=
=UfQH
-END PGP SIGNATURE-

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

Re: [OSM-talk-fr] Création suppression d'intercommunalité

[Stéphane Péneau]

A priori, j'ai terminé les Pays de la Loire, je mettrai à jour le wiki 
rapidement.


En Mayenne je n'ai pas trouvé de modifications en 2017, mais certaines 
de 2016 ou 2015 n'avait pas été mises à jour dans Osm.
Pour vérifier que je n'avais pas d'EPCI qui se chevauchait suite à des 
erreurs ou des oublis de "désactivation", j'ai utilisé la requête 
Overpass-turbo ci-dessous :

http://overpass-turbo.eu/s/l4h

Il suffit de changer le nom du département sur cette ligne de la requête :
{{geocodeArea:Loire-Atlantique}}->.searchArea;

Pourquoi a-t-on du ref:INSEE partout sur les EPCI, alors que c'est un 
numéro SIREN ? Même les arrêtés préfectoraux parlent de n° SIREN. Du 
coup, lorsque j'y ai pensé, j'ai remplacé ref:INSEE par ref:SIREN


Pour presque terminer, un exemple de l'incohérence de choisir un 
node/area "place" comme pseudo chef-lieu, au lieu d'indiquer 
l'emplacement du siège : Communauté_de_communes_des_Coëvrons, en Mayenne
- Le siège est à Châtres-la-Forêt 
 (789 habitants)
- La commune la plus importante est Évron (7127 habitants), c'est aussi 
elle qui a le plus de membres au conseil communautaire.

- Le premier président était le maire de Sainte-Suzanne (1333 habitants).

Question à 1€ : Où est le pseudo chef-lieu ?

Au passage, j'ai découvert BANATIC, dont il a été question plusieurs 
fois ici il y a quelques années. Ce n'est toujours pas utilisable ?
J'imagine que cette base pourrait alimenter Osmose pour nous alerter en 
cas d'erreur ou de manque.


Stf

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

Re: [Talk-it] Public GPS Traces, come layer sul sito OSM.

[girarsi_liste]

Il 05/01/2017 16:33, girarsi_liste ha scritto:
> Da quanto vedo io quelle che ho caricato questa settimana ancora non si
> vedono e non si vedono nemmeno quelle vecchie mie, ma solo qualcuna recente.


Ritiro tutto si vedono, guardato adesso.

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



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

[Talk-it] Public GPS Traces, come layer sul sito OSM.

[girarsi_liste]

Non mi pare di averlo visto passare in lista, ma segnalo è presente una
voce, non so da quando perchè me ne sono accorto ieri, ovvero quella in
oggetto.

La trovate nel pannello dei layer, insieme alle "Note sulla mappa" e
"Dati della mappa".

Mettendo la spunta compaiono tracce colorate relative a quelle caricate
su OSM, quelle pubbliche.

Da quanto vedo io quelle che ho caricato questa settimana ancora non si
vedono e non si vedono nemmeno quelle vecchie mie, ma solo qualcuna recente.

Ho cercato sulla wiki ma non vedo riferimenti, per cui mi rimetto a chi
eventualmente sa dove trovare la notizia.


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



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

[OSM-co] Fwd: [HOT] Final HOT Summit 2016 videos now available!

[hyan...@gmail.com]

Saludos a todos y los mejores deseos para este 2017!

Tengo el gusto de reenviarles las charlas de la pasada HOT Summit II
realizada en Bruselas, Bélgica el 21 de septiembre:

https://www.youtube.com/watch?v=lmrNHD6lGMM=PLb9506_-6FMFoS6_LqOFS-tCD__1rpmKN=23

Que las disfruten,

Humberto Yances

-- Forwarded message --
From: Nate Smith 
Date: 2017-01-05 9:31 GMT-05:00
Subject: [HOT] Final HOT Summit 2016 videos now available!
To: h...@openstreetmap.org
Cc: HOT Summit 


Hello HOTOSM Community -

Happy 2017! All HOT Summit 2016 videos are now online. You can find all the
videos on the HOT Summit 2016 playlist on our YouTube channel:

https://www.youtube.com/playlist?list=PLb9506_-6FMFoS6_LqOFS-tCD__1rpmKN

Thanks for everyone’s patience as we received the final videos over the
last couple of months. Most of all, thank you to all the speakers who
shared at last year’s Summit. We had top-notch presentations that covered
the breadth of work the entire community does on a daily basis. If anyone
has questions about the videos, please send an email directly to the HOT
Summit Working Group: sum...@hotosm.org.

We look forward to the next Summit for new community members and projects
to be shared. As a reminder, the HOT Summit working group needs volunteers
to be able to plan and implement our annual meeting. If you’re interested
in helping or want to see the next summit be a success, please send an
email to sum...@hotosm.org and let us know you would like to get involved.

Nate and HOT Summit Working Group


Nate Smith
@nas_smith 

___
HOT mailing list
h...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [OSM-talk] weeklyOSM #337 27/12/2016-02/01/2017

[Steve Doerr]

http://www.weeklyosm.eu/archives/8535, actually.

On 05/01/2017 11:58, weeklyteam wrote:

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8514/

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-br] RES: Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

Está claro que a direção das linhas nos shapefiles de face de quadra é 
completamente aleatória, não indicando nem numeração crescente nem 
descrescente. Pois agora eu notei que nos TXTs do CNEFE os numeros de uma mesma 
face às vezes vem em ordem crescente, às vezes decrescente.
Alguém checou se por acaso as duas coisas se compensam? Ou seja, distribuindo 
os números na ordem do TXT ao longo da face na direção que consta no shp, 
obtemos sempre a ordem real dos prédios?

Além disso, notei que no TXT às vezes aparece um endereço S/N entre dois que 
tem número. Nesse caso, dá pra ter certeza que a ordem dos elementos no TXT 
corresponde à ordem real dos prédios?
 

Em Quinta-feira, 5 de Janeiro de 2017 13:45, Peter Krauss 
 escreveu:
 

 Oi gente, que tal consolidar as discussões e decisões de projeto?É impossível 
acompanhar e tirar alguma conclusão mais séria aqui em meio a tantos e-mails 
dispersos e tantos tópicos discutidos pela metade.
Para mim está claro que é um experimento sério de consolidação global de dados, 
e que portanto requer antes um preparo, reprodutível por exemplo com PostGIS, 
para experts em processamento de dados poderem conferir e "assinarem embaixo" 
(eu me incluo nos voluntários), bem como emitirem relatórios mostrando os rumos 
da coisa antes de alterar a base OSM.  O uso dos dados do CNEF e o cruzamento 
com dados do CRP são dos mais relevantes (!), são dados oficiais e atualizados. 
Talvez o mais importante não seja a interpolação (num país onde ainda tem gente 
adotando numeração predial por Numerologia), mas o destaque das inconsistências 
e o registro confiável e definitivo dos dados relativos a faces de quadra.
Se todos aqui são "meio nerd", pode ser direto no Github, 
   https://github.com/OSMBrasil/_NOME_DO_PROJETO_
Qual nome será dado a esse projeto?  (ex. CNEFE2010)





Em 5 de janeiro de 2017 09:35, Reinaldo Neves  escreveu:

Também acredito que interpolação pelos dados do CNEFE vai trazer mais problemas 
que solução. Apenas a título de informação em São Paulo nas cidades que compõem 
a região metropolitana, a capital inclusive, o cep se inicia por zero,  
acredito que seja por isso que observou registros com 7 digítos.   Evidente que 
o problema ocorre na definição do campo CEP com sendo int e não char como é o 
correto.  No arquivo do CNEFE original a informação está correta. 
__ _Reinaldo Neves☎: (11) 3221-3722✉: 
rne...@equacao.com.brhttp://br.linkedin.com/in/ 
rrneveshttps://medium.com/Reinaldo_ Neves De: Papibaquígrafo 
[mailto:agostinho741-1@yahoo. com.br] 
Enviada em: quinta-feira, 5 de janeiro de 2017 07:49
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre addr:interpolation - possibilidades Santamariense, 
Sobre o ponto 1: O trabalho do recenseador não é muito diferente do nosso como 
colaboradores do OSM: você vai a campo e coleta os números da fachada das 
casas. Se falta o número de uma casa, então para todos os efeitos práticos esse 
número não existe: este é o princípio da verificabilidade do OSM ("the truth is 
on the ground"). Portanto, não há nada de errado em pular os endereços que 
constam como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N 
números nesta face" para posterior verificação. Por outro lado, ao adicionar 
interpolações, nós estamos "especulando" a respeito da numeração, o que de 
certa forma até fere o princípio da verificabilidade. E isso pode até mesmo 
introduzir erros e inconsistências. Se o número faltante é o da esquina, a 
interpolação não vai deixar de ser incompleta. Pior que isso, é sabido que 
existem quebras na sequencialidade dos números (acontece na rua em que cresci 
em Porto Alegre). Imagine se você usar um desses números "anômalos" (ou mesmo 
um dado incorreto, algo que há de existir no CNEFE) como base da interpolação!! 
(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número) Em suma, vamos tirar do CNEFE o que o CNEFE nos 
dá, sem especular em cima. Agora, sobre pontos menos importantes: a) Será 
preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se mantenha 
um registro desses deslocamentos, para uso futuro. O workflow poderia ser o 
seguinte: 1. abrir o shp no JOSM e traçar algumas linhas entre uma esquina do 
shp e a correspondente esquina no OSM; 2. salvar essas geometrias em um 
arquivo; 3. usar a média aritmética das linhas para realinhar o shp; 4. 
arquivar o deslocamento usado em cada setor censitário nalgum lugar da wiki.b) 
Notei que há muitas inconsistências no campo CEP. Em São Paulo, por exemplo, 
eles tem só 7 digitios, o erro parece ser que falta o "1" no início.c) Sobre a 
tag source, veja exemplos mais recentes. 

Re: [OSM-talk-fr] Fusion de communes au 1er Janvier...

[Nicolas Moyroud]

Salut,

Mon premier message de l'année donc le traditionnel bonne année et 
meilleurs voeux à tous.
L'an passé (ou en 2015) une commune nouvelle qui correspondait 
exactement à une communauté de communes, n'a ainsi pas pu rejoindre 
une autre communauté de commune et s'est retrouvée sans EPCI.
Ouah celle-là elle aurait sa place dans le best-of des âneries 
administratives à la française ! :-D


Nicolas

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

Re: [Talk-it] Gecocoding

[Maurizio Napolitano]

2017-01-05 13:59 GMT+01:00 Luca Moiana :
> Quale geocoder si può usare?
>
> Ho visto quello di Mapobox, non trovo i TOS

Della serie "il gatto che si morde la coda"?
Mapbox, come nominatim, photon, pelias ed altri usano openstreetmap.

In ogni caso leggere i TOS fa bene.

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

Re: [Talk-de] 20 City-Zonen in Westfalen

[Jochen]

Hallo Roland,

nur eine kleine Nachfrage noch. Spielen sich die Abweichungen auch auf 
Ortsteilebene ab?


Ortsteilgrenzen sind ja in OWL im Vergleich zu anderen Regionen nicht 
gut erfasst, da ansonsten wohl meist importiert. Vielleicht könnte man 
da noch mal nachhaken - ohne die Diskussion um WMS Fluren und 
Gemarkungen neu zu beleben.


Gruß

Jochen
Am 05.01.2017 um 12:53 schrieb Roland Olbricht:

Hallo zusammen,


gibt es Wünsche, wie wir die Tarifgebiete im künftigen Westfalentarif
taggen sollen?


Nachdem jetzt über einge Tage keine weitere Rückmeldung gekommen ist, 
würden wir den Vorschlag von Nakaner aufgreifen. Die Gemeinde-gleichen 
Tarifgebiete als kopierte Relationen und die Gemeinde-abweichenden 
Relationen als eigens gemappte Multipolygone.


Den Vorschlag mit den Shapefiles von Thomas kann ich nachvollziehen, 
wir werden ihn aber nicht weiterverfolgen können.


Aus Geo-Sicht sind Shapefiles vertraut. Aber aus VU-Sicht muss ich 
dann den Sachbearbeiter, der die Geografie unter Umständen als 
Nur-Teilaufgabe miterledigt, auch ein Tool für Shapefiles bekommen, 
darin geschult werden und wir müssen Support dafür leisten, obwohl 
alle übrigen Aufgaben mit JOSM gehen. Auch das ist dann eher mit 
Kanonen auf Spatzen geschossen.


Viele Grüße,

Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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




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

Re: [OSM-talk-fr] Fusion de communes au 1er Janvier...

[Stéphane Péneau]

Le 05/01/2017 à 13:50, Christian Quest a écrit :



Une communauté de communes qui se transforme en commune nouvelle
n'a aucune obligation de rejoindre une autre communauté.


Et si... toutes les communes doivent faire partie d'un EPCI depuis un 
ou deux ans qu'elles soient nouvelles ou pas.


J'ai croisé plusieurs fois des mentions de possibilité d'un délai de 24 
mois pour rejoindre une nouvelle communauté.


Tiens, ici, en bas de la première page :
http://www.maine-et-loire.gouv.fr/IMG/pdf/extension_alm_a_loire_authion.pdf

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

Re: [Talk-it] Gecocoding

[Martin Koppenhoefer]

2017-01-05 13:59 GMT+01:00 Luca Moiana :

> Quale geocoder si può usare?
>
> Ho visto quello di Mapobox, non trovo i TOS
>


lo standard di OSM è nominatim, ma ce ne stanno altri, vedi la wiki...

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

Re: [Talk-it] Novità sulle piazze

[Martin Koppenhoefer]

2017-01-05 13:40 GMT+01:00 Lorenzo "Beba" Beltrami :

> Trovo Prato della Valle un buon esempio di come place=square sia di più
> ampio respiro rispetto ad area=yes su una highway=*.
>
> Tra l'altro la situazione attuale[1] usa proprio la configurazione
> particolare di highway=pedestrian con area=yes, ma in questo modo si
> tralasciano le vie attorno (come notato da Martin) e tutta una serie di
> oggetti che fanno parte della piazza come il prato/isola centrale[2], il
> canale[3], per non parlare di cestini, edicole, parcheggi per bici...
>


si, se penso alle più famose piazze di Roma, come Piazza Navona, Campo de'
Fiori, Piazza della Repubblica, piazza dei 500, Piazza Venezia, Piazza
Farnese, Piazza del Popolo, Piazza del Quirinale, non ce n'è una che va
bene come highway=pedestrian e area=yes, tutte hanno delle fontane e
sculture oppure al meno dei prati da escludere dal highway. Non parliamo
neanche delle strade che non sono "pedestrian".

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

Re: [Talk-it] Gecocoding

[Luca Moiana]

Quale geocoder si può usare?

Ho visto quello di Mapobox, non trovo i TOS


Grazie



From: Maurizio Napolitano 
Sent: Thursday, January 5, 2017 11:50 AM
To: openstreetmap list - italiano
Subject: Re: [Talk-it] Gecocoding



Il 05 gen 2017 12:27, "Luca Moiana" 
> ha scritto:

Buongiorno,


scusate se ritorno sull'argomento ma non trovo spiegazioni chiare e voglio 
essere scrupoloso.


Mettiamo che i consorzi DOC/DOCG interpellati acconsentano a mappare i loro 
membri e mi diano un elenco di aziende con indirizzo, per creare i punti, posso 
affidarmi al plugin MMQGIS che fa geocoding attraverso Google o violo qualche 
licenza?

Se leggi i TOS di Google trovi scritto che i dati ricavati dal loro geocoder 
devono essere ripubblicati con una mappa di Google come sfondo



Lo so che la risposta più corretta sarebbe di mappare quello che si rileva 
direttamente ma, dopo la terza cantina, rischierei di essere impreciso

Non è che il geocoder di Google sia poi così preciso



Grazie e buona giornata

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


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

Re: [Talk-es] Limpieza de etiquetas innecesarias o mal usadas.

[Jorge Sanz Sanfructuoso]

Si hay mas que estén así claramente si, a corregirlos todos.

El jue., 5 ene. 2017 a las 13:55, Matías h ()
escribió:

> Hola. Yo es que en la columna que he puesto de ejemplos, no he añadido
> todas las etiquetas que considero erroneas en cada grupo de datos, como
> digo sólo en REGENTE hay más de una docena de ellas.
>
> Pero si es verdad que ese valor de ele no es válido. Ya puestos se podrían
> corregir todos los valores de ele que aparezacan así no?.
>
> Gracias.
>
> El 5 de enero de 2017, 13:47, Jorge Sanz Sanfructuoso 
> escribió:
>
> He añadido otro error de los Vértices ROI con la key ele.
> A ver si hago memoria que me suena que había mas cosas.
>
> Un saludo
>
> El jue., 5 ene. 2017 a las 12:30, Matías h ()
> escribió:
>
> Hola, buen día.
>
> A raíz de la reunión de la otra noche, se estableció que intentaríamos
> hacer en principio un estudio de los tags que se han usado a lo largo de
> los años (sobre todo en importaciones) que aportan una información
> innecesaria, así como el uso de algunas etiquetas de forma erronea.
>
> He creado en la wiki una tabla para que vayamos aportando algunas ideas y
> casos que nos vayamos encontrando y luego ya decidiremos la forma de
> actuar. [1]
>
> Por otro lado, aunque el pasado martes se mencionó de pasada, u siguiendo
> con el tema de limpieza, no estaría de más que nos plantearamos hacer
> "algo" con las manchas verdes, CORINE. No me refiero a eliminar a saco, ya
> que muchas modificaciones sobre estas entidades ahora si que se ajustan a
> la realidad, pero en zonas menos mapeadas, siguen estando en su versión
> original.
>
> Aunque lo ideal sería abrir otro hilo para comentar este tema ¿no?
>
> Saludos.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Limpieza de etiquetas innecesarias o mal usadas.

[Matías h]

Hola. Yo es que en la columna que he puesto de ejemplos, no he añadido
todas las etiquetas que considero erroneas en cada grupo de datos, como
digo sólo en REGENTE hay más de una docena de ellas.

Pero si es verdad que ese valor de ele no es válido. Ya puestos se podrían
corregir todos los valores de ele que aparezacan así no?.

Gracias.

El 5 de enero de 2017, 13:47, Jorge Sanz Sanfructuoso 
escribió:

> He añadido otro error de los Vértices ROI con la key ele.
> A ver si hago memoria que me suena que había mas cosas.
>
> Un saludo
>
> El jue., 5 ene. 2017 a las 12:30, Matías h ()
> escribió:
>
>> Hola, buen día.
>>
>> A raíz de la reunión de la otra noche, se estableció que intentaríamos
>> hacer en principio un estudio de los tags que se han usado a lo largo de
>> los años (sobre todo en importaciones) que aportan una información
>> innecesaria, así como el uso de algunas etiquetas de forma erronea.
>>
>> He creado en la wiki una tabla para que vayamos aportando algunas ideas y
>> casos que nos vayamos encontrando y luego ya decidiremos la forma de
>> actuar. [1]
>>
>> Por otro lado, aunque el pasado martes se mencionó de pasada, u siguiendo
>> con el tema de limpieza, no estaría de más que nos plantearamos hacer
>> "algo" con las manchas verdes, CORINE. No me refiero a eliminar a saco, ya
>> que muchas modificaciones sobre estas entidades ahora si que se ajustan a
>> la realidad, pero en zonas menos mapeadas, siguen estando en su versión
>> original.
>>
>> Aunque lo ideal sería abrir otro hilo para comentar este tema ¿no?
>>
>> Saludos.
>>
>> [1] https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Fusion de communes au 1er Janvier...

[Christian Quest]

Le 5 janvier 2017 à 12:56, Philippe Verdy  a écrit :

>
>
> Le 5 janvier 2017 à 11:29, Christian Quest  a
> écrit :
>
>>
>> Oui, c'est au conseil municipal de la commune nouvelle de prendre la
>> décision... même si chacun aurait pu aussi le faire en amont.
>>
>> L'an passé (ou en 2015) une commune nouvelle qui correspondait exactement
>> à une communauté de communes, n'a ainsi pas pu rejoindre une autre
>> communauté de commune et s'est retrouvée sans EPCI.
>>
>
> Une communauté de communes qui se transforme en commune nouvelle n'a
> aucune obligation de rejoindre une autre communauté.
>

Et si... toutes les communes doivent faire partie d'un EPCI depuis un ou
deux ans qu'elles soient nouvelles ou pas.

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

Re: [Talk-GB] Brighton water (quarterly project)

[Jez Nicholson]

Paul - I've been on the sewer tour. It was very interesting, mostly
containing rainwater runoff than poo. We emerged from a manhole on the edge
of the Old Steine to the surprise of pedestrians. And you're right, it does
raise questions on how much of underground could/should be mapped. I think
i'd probably draw the line (no pun intended) at the entrances and exits to
the sewer system.

Brian - Good pointers. Moving on to pumping stations next. I went out to
find the Environment Agency borehole at Ladies Mile which turns out to be
quite nondescript https://pbs.twimg.com/media/CzO5DodWIAAUbei.jpg:large it
has its own telegraph pole as I believe they use a dial-up modem for
communication.

I also noticed a pub called The Reservoir whilst doing fhrs:ids. There is a
temporary reservoir nearby hidden between two roads of houses.

- Jez


On Thu, 5 Jan 2017 at 12:12 Brian Prangle  wrote:

> Hi everyone
>
> Don't forget there is also urban/industrial infrastructure relating to
> water to be mapped: sewage treatment works, water treatment works, fire
> hydrants (see my recent blog
> )
> and aqueducts/pipelines (especially the buried ones like the Elan Valley
> Aqueduct which brings Birmingham's water from a reservoir in Wales).
> There's a massive project underway to create a parallel route from the
> River Severn for resilience purposes for the last part  this
> aqueduct/pipeline before it reaches Birmingham. Mapping that will take a
> lot of effort (STW won't release any opendata maps claiming protection of
> national critical infrastructure - the sorry saga of which will form a
> future blog). It might be a satisfying project to dig out the Victorian and
> Edwardian archives in libraries and map the aqueducts/pipelines connecting
> cities to their respective reservoirs in the mountains.
>
> Mapping fire hydrants is a nice little treasure hunt, which gives you an
> opportunity to revisit streets/roads that haven't been visited for a long
> time
>
> Regards
>
> brian
>
>
> On 5 January 2017 at 09:38, Jez Nicholson  wrote:
>
> I use the quarterly projects to focus my attention on different aspects of
> the city I live in. Factlets that i've unearthed so far are:
>
> * I'm going to have to be creative for water in Brighton & Hove as most of
> it is in the water table.
>
> * Water influenced the shape of the city, as it did for many in the UK.
>
> * There are (almost) no buildings to the north of the A27 (now the South
> Downs National Park) as it is the rainfall catchment area for water
> extracted at Patcham.
>
> * Patcham, the village by the first roundabout just as you get to Brighton
> on the A23, was absorbed as part of Brighton in 1924 so that the water
> table could be protected from building development.
>
> * There used to be many shack dwellings on the outskirts of the city,
> often owned by soldiers back from the war. These were stopped because they
> had no sewerage and were polluting the water table.
>
> * The Wellesbourne 'river' was where groundwater surfaces at Patcham and
> all the way down London Road to the eponymous 'pool' of Pool Valley (now
> the coach station near to the Palace Pier).
>
> * The Wellesbourne hardly ever appears now that water is extracted, but
> following persistent rain groundwater can appear in the basements of
> houses, etc.
>
> I'm building a groundwater flood forecasting system as part of my day job
> so know a bit.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-es] Limpieza de etiquetas innecesarias o mal usadas.

[Jorge Sanz Sanfructuoso]

He añadido otro error de los Vértices ROI con la key ele.
A ver si hago memoria que me suena que había mas cosas.

Un saludo

El jue., 5 ene. 2017 a las 12:30, Matías h ()
escribió:

> Hola, buen día.
>
> A raíz de la reunión de la otra noche, se estableció que intentaríamos
> hacer en principio un estudio de los tags que se han usado a lo largo de
> los años (sobre todo en importaciones) que aportan una información
> innecesaria, así como el uso de algunas etiquetas de forma erronea.
>
> He creado en la wiki una tabla para que vayamos aportando algunas ideas y
> casos que nos vayamos encontrando y luego ya decidiremos la forma de
> actuar. [1]
>
> Por otro lado, aunque el pasado martes se mencionó de pasada, u siguiendo
> con el tema de limpieza, no estaría de más que nos plantearamos hacer
> "algo" con las manchas verdes, CORINE. No me refiero a eliminar a saco, ya
> que muchas modificaciones sobre estas entidades ahora si que se ajustan a
> la realidad, pero en zonas menos mapeadas, siguen estando en su versión
> original.
>
> Aunque lo ideal sería abrir otro hilo para comentar este tema ¿no?
>
> Saludos.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-br] RES: Sobre addr:interpolation - possibilidades

[Peter Krauss]

Oi gente, que tal *consolidar *as discussões e decisões de projeto*?*
É impossível acompanhar e tirar alguma conclusão mais séria aqui em meio a
tantos e-mails dispersos e tantos tópicos discutidos pela metade.

Para mim está claro que é um experimento sério de consolidação global de
dados, e que portanto requer antes um preparo, reprodutível por exemplo com
PostGIS, para *experts* em processamento de dados poderem conferir e
"assinarem embaixo" (eu me incluo nos voluntários), bem como emitirem
relatórios mostrando os rumos da coisa antes de alterar a base OSM.

O uso dos dados do CNEF e o cruzamento com dados do CRP
 são dos mais relevantes (!),
são dados oficiais e atualizados.
Talvez o mais importante não seja a interpolação (num país onde ainda tem
gente adotando numeração predial por Numerologia), mas o destaque das
inconsistências e o registro confiável e definitivo dos dados
relativos a *faces
de quadra*.

Se todos aqui são "meio nerd", pode ser direto no Github,

   https://github.com/*OSMBrasil* /
*_NOME_DO_PROJETO_*

*Qual nome será dado a esse projeto?*  (ex. *CNEFE2010*)






Em 5 de janeiro de 2017 09:35, Reinaldo Neves 
escreveu:

> Também acredito que interpolação pelos dados do CNEFE vai trazer mais
> problemas que solução.
>
>
>
> Apenas a título de informação em São Paulo nas cidades que compõem a
> região metropolitana, a capital inclusive, o cep se inicia por zero,
> acredito que seja por isso que observou registros com 7 digítos.
>
>
>
> Evidente que o problema ocorre na definição do campo CEP com sendo int e
> não char como é o correto.  No arquivo do CNEFE original a informação está
> correta.
>
>
>
> ___
>
> Reinaldo Neves
>
> ☎: (11) 3221-3722
>
> ✉: rne...@equacao.com.br
>
> http://br.linkedin.com/in/rrneves
>
> https://medium.com/Reinaldo_Neves 
>
>
>
> *De:* Papibaquígrafo [mailto:agostinho74...@yahoo.com.br]
> *Enviada em:* quinta-feira, 5 de janeiro de 2017 07:49
> *Para:* OpenStreetMap no Brasil
> *Assunto:* Re: [Talk-br] Sobre addr:interpolation - possibilidades
>
>
>
> Santamariense,
>
>
>
> Sobre o ponto 1:
>
>
>
> O trabalho do recenseador não é muito diferente do nosso como
> colaboradores do OSM: você vai a campo e coleta os números da fachada das
> casas. Se falta o número de uma casa, então para todos os efeitos práticos
> esse número não existe: este é o princípio da verificabilidade do OSM ("the
> truth is on the ground"). Portanto, não há nada de errado em pular os
> endereços que constam como S/N no CNEFE. Pode-se até deixar uma nota
> dizendo "faltam N números nesta face" para posterior verificação.
>
>
>
> Por outro lado, ao adicionar interpolações, nós estamos "especulando" a
> respeito da numeração, o que de certa forma até fere o princípio da
> verificabilidade. E isso pode até mesmo introduzir erros e inconsistências.
> Se o número faltante é o da esquina, a interpolação não vai deixar de ser
> incompleta. Pior que isso, é sabido que existem quebras na sequencialidade
> dos números (acontece na rua em que cresci em Porto Alegre). Imagine se
> você usar um desses números "anômalos" (ou mesmo um dado incorreto, algo
> que há de existir no CNEFE) como base da interpolação!!
>
>
>
> (Note também que as tags para numeração interpolada foram pensadas para o
> sistema europeu, de números sequenciais. No Brasil, onde a numeração é por
> metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa
> completo, a *não existência* de um número é uma informação tão importante
> quando o da *existência* de um número)
>
>
>
> Em suma, vamos tirar do CNEFE o que o CNEFE nos dá, sem especular em cima.
>
>
>
> Agora, sobre pontos menos importantes:
>
>
>
> a) Será preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que
> se mantenha um registro desses deslocamentos, para uso futuro. O workflow
> poderia ser o seguinte: 1. abrir o shp no JOSM e traçar algumas linhas
> entre uma esquina do shp e a correspondente esquina no OSM; 2. salvar essas
> geometrias em um arquivo; 3. usar a média aritmética das linhas para
> realinhar o shp; 4. *arquivar* o deslocamento usado em cada setor
> censitário nalgum lugar da wiki.
>
> b) Notei que há muitas inconsistências no campo CEP. Em São Paulo, por
> exemplo, eles tem só 7 digitios, o erro parece ser que falta o "1" no
> início.
>
> c) Sobre a tag source, veja exemplos mais recentes. Na importação de Nova
> York, não há source nos objetos. Note que ninguém jamais atualiza o source
> ao fazer uma edição, logo você precisa ir no histórico de qualquer forma
> para saber algo com convicção.
>
>
>
> E, pra finalizar, queria dizer que essa é uma ótima iniciativa. Parabéns!
>
>
>
> Em Quarta-feira, 4 de Janeiro de 2017 23:30, santamariense <
> imagens...@gmail.com> escreveu:
>
>
>
> @Papibaquígrafo,
>
> 1. A questão é que existem muitos SN (sem número) cadastrados entre

Re: [Talk-it] Novità sulle piazze

[Lorenzo "Beba" Beltrami]

2017-01-05 12:50 GMT+01:00 mircozorzo :

> Ciao, quindi Prato della Valle a Padova è un place=square, giusto?
>

Trovo Prato della Valle un buon esempio di come place=square sia di più
ampio respiro rispetto ad area=yes su una highway=*.

Tra l'altro la situazione attuale[1] usa proprio la configurazione
particolare di highway=pedestrian con area=yes, ma in questo modo si
tralasciano le vie attorno (come notato da Martin) e tutta una serie di
oggetti che fanno parte della piazza come il prato/isola centrale[2], il
canale[3], per non parlare di cestini, edicole, parcheggi per bici...

Lorenzo

[1] https://www.openstreetmap.org/relation/571885
[2] https://www.openstreetmap.org/relation/6541028
[3] https://www.openstreetmap.org/way/42423786
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] WeeklyOSM CZ 335

[Marián Kyral]

-- Původní zpráva --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 5. 1. 2017 13:28:23
Předmět: Re: [Talk-cz] WeeklyOSM CZ 335

"


Vzhledem k tomu, že v datech OSM to osvětlení není všude (JOSM umí zobrazit 
pomocí několika stylů mapy, používám to při kontrole mapování), bych řekla 
že užití není v současnosti reálné - alespoň České Budějovice a okolí nemá 
zmapováno osvětlené ulice všude. Spíš bych to viděla jako námět na co se 
zaměřit v blízké době při mapování.



"



No máme na to issue pro openstreetmap.cz https://github.com/osmcz/osmcz/
issues/48




A je to přesně tak. Lidi mapují hlavně věci, které vidí. Když bude speciální
noční vrstva, tak bude i větší motivace ji naplnit daty.



"




Co vím, třeba ve Velké Británii mají "téma měsíce". Což takhle to zkusit i u
nás? Tím myslím vyhlásit, na co se v daném měsíci zaměřit při mapování - 
třeba zrovna to osvětlení, nebo nedávno zmiňované rampy na schodištích nebo 
ty sochy, na které se narazilo před vánoci... Bývají to věci, které mě 
normálně nenapadne kontrolovat, zda už jsou nebo nejsou zmapované.


"



No my teď máme téma roku - turistické trasy  Na další témata asi nebudou 
lidi :-D




Marián




"



Majka






2017-01-04 16:36 GMT+01:00 Mikoláš Štrajt :
"



"

"



Jo, to znám, ale to není z dat OSM ;-)
Zajímal mě ten inverzní případ. Use case je jasný: Jsem slabý jedinec v 
cizím městě a chci vědět, kudy je relativně bezpečné procházet. Což mě 
přivádí na myšlenku, že routovací engin, který by uměl zohlednit "noční" 
cestu jsem taky ještě nepotkal :-)






"





___
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-br] strava

[Arlindo Pereira]

Complementando: o Strava disponibiliza camadas heatmap (mapas de calor) com
as trilhas de seus usuários, anonimizadas. É possível escolher entre
somente ciclismo, somente corrida ou os dois juntos, em diferentes estilos
de coloração.


[]s
Arlindo Pereira

Em 5 de janeiro de 2017 10:22, Helio Cesar Tomio 
escreveu:

> Complementando o que o Roger muito bem explanou, a camada do strava pode
> ser aberta também no editor iD.
>
> Existe tb um editor iD modificado pela Strava, para auxiliar nas edições :
> https://strava.github.io/iD/
>
> Em 05/01/2017 07:52, "Gerald Weber"  escreveu:
>
>> Oi Turma
>>
>>
>> eu vejo muitas menções ao strava nas discussões aqui e no telegram, já vi
>> até edições com gente se referindo ao strava.
>>
>>
>> Eu só não entendi muito bem como nós podemos usar os dados do strava.
>> Lendo a wiki do OSM eu fiquei na mesma.
>>
>>
>> Entendi que se trata de um aplicativo onde se registra caminhadas,
>> corridas etc. Uma amiga minha até me mostrou a trilha gps que ela gravou de
>> bicicleta.
>>
>>
>> Mas onde entramos nisto? A gente tem acesso a estas trilhas gps? como?
>>
>>
>> qualquer dica será muito bem vinda
>>
>>
>> abraço
>>
>>
>> Gerald
>>
>>
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] strava

[Helio Cesar Tomio]

Complementando o que o Roger muito bem explanou, a camada do strava pode
ser aberta também no editor iD.

Existe tb um editor iD modificado pela Strava, para auxiliar nas edições :
https://strava.github.io/iD/

Em 05/01/2017 07:52, "Gerald Weber"  escreveu:

> Oi Turma
>
>
> eu vejo muitas menções ao strava nas discussões aqui e no telegram, já vi
> até edições com gente se referindo ao strava.
>
>
> Eu só não entendi muito bem como nós podemos usar os dados do strava.
> Lendo a wiki do OSM eu fiquei na mesma.
>
>
> Entendi que se trata de um aplicativo onde se registra caminhadas,
> corridas etc. Uma amiga minha até me mostrou a trilha gps que ela gravou de
> bicicleta.
>
>
> Mas onde entramos nisto? A gente tem acesso a estas trilhas gps? como?
>
>
> qualquer dica será muito bem vinda
>
>
> abraço
>
>
> Gerald
>
>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-cz] WeeklyOSM CZ 335

[majka]

Vzhledem k tomu, že v datech OSM to osvětlení není všude (JOSM umí zobrazit
pomocí několika stylů mapy, používám to při kontrole mapování), bych řekla
že užití není v současnosti reálné - alespoň České Budějovice a okolí nemá
zmapováno osvětlené ulice všude. Spíš bych to viděla jako námět na co se
zaměřit v blízké době při mapování.

Co vím, třeba ve Velké Británii mají "téma měsíce". Což takhle to zkusit i
u nás? Tím myslím vyhlásit, na co se v daném měsíci zaměřit při mapování -
třeba zrovna to osvětlení, nebo nedávno zmiňované rampy na schodištích nebo
ty sochy, na které se narazilo před vánoci... Bývají to věci, které mě
normálně nenapadne kontrolovat, zda už jsou nebo nejsou zmapované.

Majka

2017-01-04 16:36 GMT+01:00 Mikoláš Štrajt :

>
> Jo, to znám, ale to není z dat OSM ;-)
> Zajímal mě ten inverzní případ. Use case je jasný: *Jsem slabý jedinec v
> cizím městě a chci vědět, kudy je relativně bezpečné procházet*. Což mě
> přivádí na myšlenku, že routovací engin, který by uměl zohlednit "noční"
> cestu jsem taky ještě nepotkal :-)
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] Novità sulle piazze

[Martin Koppenhoefer]

2017-01-05 12:50 GMT+01:00 mircozorzo :

> Ciao, quindi Prato della Valle a Padova è un place=square, giusto?



direi di si, al meno wikipedia lo vede così. Quando lo ho aperto in
GStreetview il primo istinto è stato ni, perché è molto grande, e sembra
più un parco che una piazza, d'altro canto ha il nome tutto intorno (le
strade), quindi sembrebbe di si.

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

Re: [Talk-it] Gecocoding

[Martin Koppenhoefer]

2017-01-05 12:50 GMT+01:00 Maurizio Napolitano :

> Non è che il geocoder di Google sia poi così preciso



+1, mentre per il geocoding con OSM si deve essere proprio fortunato per
trovare un civico (ovviamente dipende dalla zona, in Germania la situazione
è molto meglio, ma non ci sono cantine D.O.C. ;-) ).

L'unica soluzione è inserire civici ovviamente. Inserite qualsiasi civico
che conoscete (dove avete abitato, dove abitano persone che conoscete,
ristoranti, ecc.). Io talvolta inserisco civici col cellulare quando sto da
qualche parte aspettando qualcuno, metto un paio di civici così a caso. Non
aspettate di fare un lavoro "completo" e sistematico. Ogni civico
"galleggiante" ha effetti molto positivi: uno perché può motivare altre
persone a continuare e due per orientarsi: già con 2-3 civici a strada (non
troppo lunga) si può più o meno capire dove sono gli altri civici.

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

Re: [Talk-GB] Brighton water (quarterly project)

[Paul Berry]

An idle thought, but I wonder how much of this could or should be mapped?

http://www.subbrit.org.uk/sb-sites/sites/b/brighton_sewers/index.shtml
https://www.southernwater.co.uk/brighton-sewer-tours

Regards,
*Paul*

On 5 January 2017 at 09:38, Jez Nicholson  wrote:

> I use the quarterly projects to focus my attention on different aspects of
> the city I live in. Factlets that i've unearthed so far are:
>
> * I'm going to have to be creative for water in Brighton & Hove as most of
> it is in the water table.
>
> * Water influenced the shape of the city, as it did for many in the UK.
>
> * There are (almost) no buildings to the north of the A27 (now the South
> Downs National Park) as it is the rainfall catchment area for water
> extracted at Patcham.
>
> * Patcham, the village by the first roundabout just as you get to Brighton
> on the A23, was absorbed as part of Brighton in 1924 so that the water
> table could be protected from building development.
>
> * There used to be many shack dwellings on the outskirts of the city,
> often owned by soldiers back from the war. These were stopped because they
> had no sewerage and were polluting the water table.
>
> * The Wellesbourne 'river' was where groundwater surfaces at Patcham and
> all the way down London Road to the eponymous 'pool' of Pool Valley (now
> the coach station near to the Palace Pier).
>
> * The Wellesbourne hardly ever appears now that water is extracted, but
> following persistent rain groundwater can appear in the basements of
> houses, etc.
>
> I'm building a groundwater flood forecasting system as part of my day job
> so know a bit.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-ie] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8514/

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-GB] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8514/

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-ca] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8514/

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-in] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8514/

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[OSM-talk] weeklyOSM #337 27/12/2016-02/01/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 337,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/8514/

Enjoy!

weeklyOSM?
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8514/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8514/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8514/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

semanarioOSM Nº 337 27/12/2016-02/01/2017

[weeklyteam]

Hola, el semanario Nº 337, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8514/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [OSM-talk-fr] Fusion de communes au 1er Janvier...

[Philippe Verdy]

Le 5 janvier 2017 à 11:29, Christian Quest  a
écrit :

>
> Oui, c'est au conseil municipal de la commune nouvelle de prendre la
> décision... même si chacun aurait pu aussi le faire en amont.
>
> L'an passé (ou en 2015) une commune nouvelle qui correspondait exactement
> à une communauté de communes, n'a ainsi pas pu rejoindre une autre
> communauté de commune et s'est retrouvée sans EPCI.
>

Une communauté de communes qui se transforme en commune nouvelle n'a aucune
obligation de rejoindre une autre communauté. Elle bénéficie de l'avantage
budgétaire du seul fait de cette transformation qui élimine un niveau
administratif. Certaines communes nouvelles sont très étendues et n'ont pas
d'intérêt particulier à se fondre encore dans une entité plus grande pour
déléguer encore plus, alors que la commune nouvelle a déjà repris quasiment
toutes les compétences des anciennes communes (hormis l'état-civil qui
reste dans les communes déléguées tant qu'elles ne décident pas aussi de
transférer ce service à la commune nouvelle)

Enfin une commune nouvelle peut être créée avec des communes qui faisaient
partie de plusieurs communautés. La loi leur donne quelques mois pour
décider à quelle communauté la commune nouvelle adhérera (et en attendant
la commune nouvelle ne fait elle même partie d'aucune communauté, les
communes déléguées sont encore représentées elles-mêmes dans leurs
communautés d'origine qui doivent statuer). La transition n'est donc pas
instantanée lors de la création ou l'extension d'une commune nouvelle.

Cependant la décision est souvent rapide et a lieu dans les premières
réunions des assemblées, qui font connaitre leur décision au préfet. Il
peut y avoir des différences dans les décisions des communes et des
communautés, et des litiges qui se règlent au tribunal administratif, mais
dans ce cas le délai sera sensiblement allongé. Parfois cela n'aboutit pas,
et des communes déléguées ne sont pas d'accord avec le choix de l'EPCI par
la commune nouvelle et des litiges peuvent exister avec les autres EPCI
dont doit sortir une commune déléguée
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] WeeklyOSM CZ 335

[Jan Macura]

Ahoj,

2017-01-04 16:36 GMT+01:00 Mikoláš Štrajt :

>
> Viz mapu světelného znečištění: http://svetelneznecisteni.cz/mapovani-tmy/
>
>
Jo, to znám, ale to není z dat OSM ;-)
Zajímal mě ten inverzní případ. Use case je jasný: *Jsem slabý jedinec v
cizím městě a chci vědět, kudy je relativně bezpečné procházet*. Což mě
přivádí na myšlenku, že routovací engin, který by uměl zohlednit "noční"
cestu jsem taky ještě nepotkal :-)

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

Re: [Talk-de] 20 City-Zonen in Westfalen

[Roland Olbricht]

Hallo zusammen,


gibt es Wünsche, wie wir die Tarifgebiete im künftigen Westfalentarif
taggen sollen?


Nachdem jetzt über einge Tage keine weitere Rückmeldung gekommen ist, 
würden wir den Vorschlag von Nakaner aufgreifen. Die Gemeinde-gleichen 
Tarifgebiete als kopierte Relationen und die Gemeinde-abweichenden 
Relationen als eigens gemappte Multipolygone.


Den Vorschlag mit den Shapefiles von Thomas kann ich nachvollziehen, wir 
werden ihn aber nicht weiterverfolgen können.


Aus Geo-Sicht sind Shapefiles vertraut. Aber aus VU-Sicht muss ich dann 
den Sachbearbeiter, der die Geografie unter Umständen als 
Nur-Teilaufgabe miterledigt, auch ein Tool für Shapefiles bekommen, 
darin geschult werden und wir müssen Support dafür leisten, obwohl alle 
übrigen Aufgaben mit JOSM gehen. Auch das ist dann eher mit Kanonen auf 
Spatzen geschossen.


Viele Grüße,

Roland

--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898

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

Re: [Talk-it] Gecocoding

[Maurizio Napolitano]

Il 05 gen 2017 12:27, "Luca Moiana"  ha scritto:

Buongiorno,


scusate se ritorno sull'argomento ma non trovo spiegazioni chiare e voglio
essere scrupoloso.


Mettiamo che i consorzi DOC/DOCG interpellati acconsentano a mappare i loro
membri e mi diano un elenco di aziende con indirizzo, per creare i punti,
posso affidarmi al plugin MMQGIS che fa geocoding attraverso Google o violo
qualche licenza?


Se leggi i TOS di Google trovi scritto che i dati ricavati dal loro
geocoder devono essere ripubblicati con una mappa di Google come sfondo


Lo so che la risposta più corretta sarebbe di mappare quello che si rileva
direttamente ma, dopo la terza cantina, rischierei di essere impreciso

Non è che il geocoder di Google sia poi così preciso


Grazie e buona giornata

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

Re: [Talk-it] Novità sulle piazze

[mircozorzo]

Ciao, quindi Prato della Valle a Padova è un place=square, giusto? 



--
View this message in context: 
http://gis.19327.n8.nabble.com/Novita-sulle-piazze-tp5888485p5888735.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-us] First new 2016 NAIP imagery is now online (Massachusetts & Tennessee)

[Mike N]

On 1/4/2017 10:46 PM, James Mast wrote:

I tested out the new 2016 TN link in JOSM before I sent the original
email and it worked perfectly fine for me.


  I looked again and all is working now!   It had been unusable for 
several weeks around the USGS transition, and I thought the whole NAIP 
program had also fallen victim.


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

[Talk-br] RES: Sobre addr:interpolation - possibilidades

[Reinaldo Neves]

Também acredito que interpolação pelos dados do CNEFE vai trazer mais problemas 
que solução.

 

Apenas a título de informação em São Paulo nas cidades que compõem a região 
metropolitana, a capital inclusive, o cep se inicia por zero,  acredito que 
seja por isso que observou registros com 7 digítos.  

 

Evidente que o problema ocorre na definição do campo CEP com sendo int e não 
char como é o correto.  No arquivo do CNEFE original a informação está correta.

 

___

Reinaldo Neves

☎: (11) 3221-3722

✉:   rne...@equacao.com.br

  http://br.linkedin.com/in/rrneves

  https://medium.com/Reinaldo_Neves

 

De: Papibaquígrafo [mailto:agostinho74...@yahoo.com.br] 
Enviada em: quinta-feira, 5 de janeiro de 2017 07:49
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre addr:interpolation - possibilidades

 

Santamariense,

 

Sobre o ponto 1:

 

O trabalho do recenseador não é muito diferente do nosso como colaboradores do 
OSM: você vai a campo e coleta os números da fachada das casas. Se falta o 
número de uma casa, então para todos os efeitos práticos esse número não 
existe: este é o princípio da verificabilidade do OSM ("the truth is on the 
ground"). Portanto, não há nada de errado em pular os endereços que constam 
como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N números nesta 
face" para posterior verificação.

 

Por outro lado, ao adicionar interpolações, nós estamos "especulando" a 
respeito da numeração, o que de certa forma até fere o princípio da 
verificabilidade. E isso pode até mesmo introduzir erros e inconsistências. Se 
o número faltante é o da esquina, a interpolação não vai deixar de ser 
incompleta. Pior que isso, é sabido que existem quebras na sequencialidade dos 
números (acontece na rua em que cresci em Porto Alegre). Imagine se você usar 
um desses números "anômalos" (ou mesmo um dado incorreto, algo que há de 
existir no CNEFE) como base da interpolação!!

 

(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número)

 

Em suma, vamos tirar do CNEFE o que o CNEFE nos dá, sem especular em cima.

 

Agora, sobre pontos menos importantes:

 

a) Será preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se 
mantenha um registro desses deslocamentos, para uso futuro. O workflow poderia 
ser o seguinte: 1. abrir o shp no JOSM e traçar algumas linhas entre uma 
esquina do shp e a correspondente esquina no OSM; 2. salvar essas geometrias em 
um arquivo; 3. usar a média aritmética das linhas para realinhar o shp; 4. 
arquivar o deslocamento usado em cada setor censitário nalgum lugar da wiki.

b) Notei que há muitas inconsistências no campo CEP. Em São Paulo, por exemplo, 
eles tem só 7 digitios, o erro parece ser que falta o "1" no início.

c) Sobre a tag source, veja exemplos mais recentes. Na importação de Nova York, 
não há source nos objetos. Note que ninguém jamais atualiza o source ao fazer 
uma edição, logo você precisa ir no histórico de qualquer forma para saber algo 
com convicção.

 

E, pra finalizar, queria dizer que essa é uma ótima iniciativa. Parabéns!

 

Em Quarta-feira, 4 de Janeiro de 2017 23:30, santamariense 
 escreveu:

 

@Papibaquígrafo,

1. A questão é que existem muitos SN (sem número) cadastrados entre
casas que já tem número. E as linhas ajudam a tapar este buraco,
interpolando numerações intermediárias que possam existir. Do meu
ponto de vista todo o material é provisório, pois na maioria dos casos
o ponto será apagado porque vai para a building quando se tiver a
certeza de qual building é. E a linha será apagada quando todas as
casas de uma face da quadra tiver os números corretos na building
correta.

2. Interessante. Não tinha pensado nisso. Mesmo assim me pergunto se
não seria melhor nos objetos para ser mais prático, quando futuramente
alguém for contribuir, buscar a fonte em históricos de changesets é
não-prático. Em Paris, tudo indica que se adicionou source a todos os
objetos (http://overpass-turbo.eu/s/l3J)

3. Isso são pormenores, mas que são sim muito relevantes. Eu proponho
que numa primeira fase, se faça testes em alguns municípios e que a
gente (cada um) faça relatório concomitantemente ao trabalho, a fim de
anotar todos os problemas/dúvidas enfrentados.

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



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

[Talk-es] Limpieza de etiquetas innecesarias o mal usadas.

[Matías h]

Hola, buen día.

A raíz de la reunión de la otra noche, se estableció que intentaríamos
hacer en principio un estudio de los tags que se han usado a lo largo de
los años (sobre todo en importaciones) que aportan una información
innecesaria, así como el uso de algunas etiquetas de forma erronea.

He creado en la wiki una tabla para que vayamos aportando algunas ideas y
casos que nos vayamos encontrando y luego ya decidiremos la forma de
actuar. [1]

Por otro lado, aunque el pasado martes se mencionó de pasada, u siguiendo
con el tema de limpieza, no estaría de más que nos plantearamos hacer
"algo" con las manchas verdes, CORINE. No me refiero a eliminar a saco, ya
que muchas modificaciones sobre estas entidades ahora si que se ajustan a
la realidad, pero en zonas menos mapeadas, siguen estando en su versión
original.

Aunque lo ideal sería abrir otro hilo para comentar este tema ¿no?

Saludos.

[1] https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-it] Gecocoding

[Luca Moiana]

Buongiorno,


scusate se ritorno sull'argomento ma non trovo spiegazioni chiare e voglio 
essere scrupoloso.


Mettiamo che i consorzi DOC/DOCG interpellati acconsentano a mappare i loro 
membri e mi diano un elenco di aziende con indirizzo, per creare i punti, posso 
affidarmi al plugin MMQGIS che fa geocoding attraverso Google o violo qualche 
licenza?


Lo so che la risposta più corretta sarebbe di mappare quello che si rileva 
direttamente ma, dopo la terza cantina, rischierei di essere impreciso []


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