[Talk-ca] Fwd: BC2020i - update Sept 2018

[Matthew Darwin]

 Forwarded Message 
Subject:BC2020i - update Sept 2018
Date:   Thu, 13 Sep 2018 13:54:41 +
From:   Alasia, Alessandro (STATCAN) 
To: many



Dear all,

I hope you had a good and relaxing summer. I imagine this email will 
find you all back in the office or at your activity.


I have been in touch with many over the summer and I know that 
numerous things are moving and brewing, which is great! At our end we 
have continued working on our open database of building (we expect 
this to be shared soon). It has now passed the 4.3 million mark for 
number of building footprints.


In terms of *updates from our end*, we recently established a 
collaborative agreement with the Bing Maps team (Microsoft) in the 
hope that, by joining forces and avoiding duplication of efforts, what 
they did in the US can be replicated in Canada (see 
https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data). 
Additionally, we started a dialogue with OpenAddresses to explore 
collaborations and, most recently, began work on an Open Business 
Repository, which mimics the approach of OpenAddresses but uses open 
business records. The preliminary results on these and other open data 
explorations are very encouraging.


In various conversations, I learned that a lot of great work has been 
done at your end as well! And talking with some of you, *the idea of a 
second meeting on the topic of BC2020i has been tossed around*. Since 
the initiative has matured, slowly but surely, I think it would be 
great to get together again, take a stock of where we are at, and see 
what the next steps could be. Like last year, I think we may be able 
to offer the venue.


With that said, if a second meeting (say “*BC2020i-2*”) is organized, 
I would hope it to be a bit more focused. An ideal outcome coming out 
of BC2020i-2 could be the following:


·Stronger buy-in from some of the key federal departments interested 
in building data


·Greater involvement (maybe sponsorship J?) from some of the key 
players in the private sector who have shown a great interest in 
supporting open data platforms, which could help smaller businesses, 
NGOs, and students/academics to become more involved.


·More awareness and highlighting of some of the 
local-municipal-regional initiatives. I heard of very interesting work 
happening in the Niagara region, for instance. And same for the work 
that has been done by many academic departments (I just had a chat 
with a graduate student from the University of Waterloo who is 
researching the BC2020i)


·And of course, it would be great if this could be an opportunity to 
solidify the presence of OSM-Canada in the institutional arena (as an 
institutional player as well?)


One way to re-think BC2020i is by placing it in the context of a *data 
co-op*. And now that this initiative is past its infancy, how can we 
solidify this data co-op for the benefit of all?


It would be great if we can share ideas on all of the above. My team 
and I remain committed to facilitating this and moving the discussion 
forward. Ideally, *we could target a date in January 2019* for a 
second meeting. Ottawa is such a lovely place to visit in that 
season…we have a frozen canal and beaver tails! – the latter being 
essentially a flat doughnut.


Looking forward to hearing from you,

Alessandro and the DEIL-Team

*PS.*Over the fall my team and I will present our work on open data as 
well as make reference to the ideas of BC2020i in many different 
places and we hope to see you in person at some of these events. In 
particular we will be at:


·Sept 28 - Open First Day  – Ottawa

·Oct 26-28 – People, Places, and Public Engagement Conference - St. 
John’s, NFL


·Nov 6-9 - StatCan International Methodological Symposium - Ottawa

·Nov 7-9 – CODS18  - Niagara Falls (to be 
confirmed)


·Nov – GIS Day – probably at McGill- Montreal (to be confirmed)

·A longer list of seminars and workshops with Fed Departments

Alessandro Alasia
Chief | Chef

Data Exploration and Integration Lab (DEIL) | Lab pour l’exploration 
et l’intégration de données (LEID)


Center for Special Business Projects | Centre des Projets Spéciaux sur 
les entreprises


Statistics Canada | Statistique Canada
alessandro.ala...@canada.ca  / 
(613) 796-6049


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

[OSM-talk-ie] Land showing as sea

[Colm Moore]

Hi,


Is the land showing as sea for other people here: 
https://www.openstreetmap.org/#map=13/54.8509/-5.8483 ? It may be there was a 
problem and it was fixed already.


Thanks


Colm



---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Valeu, vou pesquisar.

Tamo chegando lá.


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

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: sábado, 15 de setembro de 2018 19:53
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

MDS (multi dimensional scaling) também ajuda na análise multidimensional.  Veja 
se o QGis tem MDS.

Em sáb, 15 de set de 2018 às 19:51, Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>> escreveu:
Oi, Sérgio, o caminho é esse mesmo.  Mas estás usando três variáveis: B11, NDVI 
e EVI2.  Em rigor seria necessário um crossplot 3D, mas aí a análise visual 
começa a complicar.  Nesse ponto eu usaria um dendrograma para analisar as 
classes.  O QGis tem dendrograma?

Em sáb, 15 de set de 2018 às 12:29, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Ok, agora entendi esse negócio de manter as variáveis disponíveis sem fundir em 
uma. Valeu!
-O NDVI distingue bem vegetal do que não é, e as classes de vegetal em 
diferentes graus de clorofila nas folhas, isto é crescimento, atividade 
vegetal. Mas nas matas densas tem mata nativa + mata plantada (pinus 
principalmente no RS). Mata plantada tem sempre atividade mais alta e valores 
mais altos de NDVI. Mata nativa já mistura: tem áreas e indivíduos com ambos 
estados, em crescimento e em estagnação/maturidade, mas tende a menor atividade 
de crescimento.

Assim NDVI não distingue estas 2 dentro da mata ou em contato de bordas. Mas em 
imagem hi-res do Bing já é fácil distinguir uma da outra. Existe esta distinção 
de área de mata nativa separada de área de mata plantada.

-O B11 distingue muito bem uma da outra, aproximadamente por volta do valor 
1000: ~200 a 1000 (mais escuro) mata planta; ~1000 a 1600 (mais claro) mata 
nativa. Porém não distingue bem água/rio/sombra que fica entre ~0 a 300. Afeta 
um tanto pelas sombras em encostas, onde baixa o valor.

Do que entendi, assim, usando ao mesmo tempo as 2 variáveis, uma poderia fazer 
o recorte onde a outra ainda mistura alguma coisa, uma apara as arestas da 
outra.


Abaixo segue crossplot e mapa, coloridos na mesma base, as cores de NDVI para 
12 classes. EVI2 é quase igual a EVI e a NDVI. Mas dizem que EVI e EVI2 são 
melhores para matas densas. NDVI pra vegetação em geral.


"EVI (Enhanced Vegetation Index) - In areas of dense canopy where the leaf area 
index (LAI) is high, the NDVI values can be improved by leveraging information 
in the blue wavelength. " 
(https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts)


"...contrary to that notion the Amazon forest does exhibit distinct growth 
during the dry season..." 
(https://en.wikipedia.org/wiki/Enhanced_vegetation_index - # Application of 
EVI...)


A ver o que acham.

https://i.imgur.com/9dBhNjC.jpg


Obrigado!

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

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>>
Enviado: sexta-feira, 14 de setembro de 2018 18:14
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

O problema, Sérgio, quando se usa uma fórmula, efetivamente estás resumindo 
duas variáveis a uma variável só.  Pela forma da mancha no crossplot B11 versus 
NDVI, a correlação entre elas não é linear, ou seja, elas não informam a mesma 
coisa.  Pelo contrário, temos que aumentar a dimensionalidade.  Seria 
importante vermos como os pontos se agrupam.  Talvez haja até bem mais do que 
duas classes.

Em sex, 14 de set de 2018 às 17:10, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único 
pixel"


A coisa que me intriga ainda é que estava reexaminando as imagens e 
histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que pode 
ser confirmada na alta resolução do Bing.

E os histogramas me parecem ainda indicar que apontam para a confirmação da 
formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de classes e 
diferenciação de:

1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)

2)forest  (mais jovem, mais úmida, mais ativa em clorofila)

3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para "null").


Imagens junto com histogramas correspondentes do caso B11 x ((1-NDVI)*4000):

https://i.imgur.com/4uKNw1r.jpg


É a mesma área que peguei como exemplo desde o início, porque tem todos os 
tipos que poderiam interferir, e dá pra examinar se o resultado distingue bem 
wood e forest do resto:

wood; forest; river; pond; campos ralos; farmland; estradas; ...


Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos, de 
vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood variam 
mais no espectro: há área velhas e algumas em crescimento. Então há mistura das 
2 classes.

Já no B11 se destacam bem claramente entre si: uma não invade a margem de 

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Paulo Carvalho]

MDS (multi dimensional scaling) também ajuda na análise multidimensional.
Veja se o QGis tem MDS.

Em sáb, 15 de set de 2018 às 19:51, Paulo Carvalho <
paulo.r.m.carva...@gmail.com> escreveu:

> Oi, Sérgio, o caminho é esse mesmo.  Mas estás usando três variáveis: B11,
> NDVI e EVI2.  Em rigor seria necessário um crossplot 3D, mas aí a análise
> visual começa a complicar.  Nesse ponto eu usaria um dendrograma para
> analisar as classes.  O QGis tem dendrograma?
>
> Em sáb, 15 de set de 2018 às 12:29, Sérgio V. 
> escreveu:
>
>> Ok, agora entendi esse negócio de manter as variáveis disponíveis sem
>> fundir em uma. Valeu!
>> -O NDVI distingue bem vegetal do que não é, e as classes de vegetal em
>> diferentes graus de clorofila nas folhas, isto é crescimento, atividade
>> vegetal. Mas nas matas densas tem mata nativa + mata plantada (pinus
>> principalmente no RS). Mata plantada tem sempre atividade mais alta e
>> valores mais altos de NDVI. Mata nativa já mistura: tem áreas e indivíduos
>> com ambos estados, em crescimento e em estagnação/maturidade, mas tende a
>> menor atividade de crescimento.
>>
>> Assim NDVI não distingue estas 2 dentro da mata ou em contato de bordas.
>> Mas em imagem hi-res do Bing já é fácil distinguir uma da outra. Existe
>> esta distinção de área de mata nativa separada de área de mata plantada.
>>
>> -O B11 distingue muito bem uma da outra, aproximadamente por volta do
>> valor 1000: ~200 a 1000 (mais escuro) mata planta; ~1000 a 1600 (mais
>> claro) mata nativa. Porém não distingue bem água/rio/sombra que fica entre
>> ~0 a 300. Afeta um tanto pelas sombras em encostas, onde baixa o valor.
>>
>> Do que entendi, assim, usando ao mesmo tempo as 2 variáveis, uma poderia 
>> fazer
>> o recorte onde a outra ainda mistura alguma coisa, uma apara as arestas
>> da outra.
>>
>>
>> Abaixo segue crossplot e mapa, coloridos na mesma base, as cores de NDVI
>> para 12 classes. EVI2 é quase igual a EVI e a NDVI. Mas dizem que EVI e
>> EVI2 são melhores para matas densas. NDVI pra vegetação em geral.
>>
>>
>> "EVI (Enhanced Vegetation Index) - In areas of dense canopy where the
>> leaf area index (LAI) is high, the NDVI values can be improved by
>> leveraging information in the blue wavelength. " (
>> https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts
>> )
>>
>>
>> "...contrary to that notion the Amazon forest does exhibit distinct
>> growth during the dry season..." (
>> https://en.wikipedia.org/wiki/Enhanced_vegetation_index - # Application
>> of EVI...)
>>
>>
>> A ver o que acham.
>>
>> https://i.imgur.com/9dBhNjC.jpg
>>
>>
>> Obrigado!
>>
>> - - - - - - - - - - - - - - - -
>>
>> Sérgio - http://www.openstreetmap.org/user/smaprs
>>
>>
>> --
>> *De:* Paulo Carvalho 
>> *Enviado:* sexta-feira, 14 de setembro de 2018 18:14
>> *Para:* OSM talk-br
>> *Assunto:* Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2
>>
>> O problema, Sérgio, quando se usa uma fórmula, efetivamente estás
>> resumindo duas variáveis a uma variável só.  Pela forma da mancha no
>> crossplot B11 versus NDVI, a correlação entre elas não é linear, ou seja,
>> elas não informam a mesma coisa.  Pelo contrário, temos que aumentar a
>> dimensionalidade.  Seria importante vermos como os pontos se agrupam.
>> Talvez haja até bem mais do que duas classes.
>>
>> Em sex, 14 de set de 2018 às 17:10, Sérgio V. 
>> escreveu:
>>
>> Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único
>> pixel"
>>
>>
>> A coisa que me intriga ainda é que estava reexaminando as imagens e
>> histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que
>> pode ser confirmada na alta resolução do Bing.
>>
>> E os histogramas me parecem ainda indicar que apontam para a confirmação da
>> formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de
>> classes e diferenciação de:
>>
>> 1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)
>>
>> 2)forest  (mais jovem, mais úmida, mais ativa em clorofila)
>>
>> 3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para
>> "null").
>>
>>
>> Imagens junto com histogramas correspondentes do caso B11 x
>> ((1-NDVI)*4000):
>>
>> https://i.imgur.com/4uKNw1r.jpg
>>
>> É a mesma área que peguei como exemplo desde o início, porque tem todos
>> os tipos que poderiam interferir, e dá pra examinar se o
>> resultado distingue bem wood e forest do resto:
>>
>> wood; forest; river; pond; campos ralos; farmland; estradas; ...
>>
>> Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos,
>> de vegetação crescendo ativamente; como próprio do NDVI; enquanto as
>> wood variam mais no espectro: há área velhas e algumas em crescimento.
>> Então há mistura das 2 classes.
>>
>> Já no B11 se destacam bem claramente entre si: uma não invade a margem de
>> valores da outra.
>>
>>
>> Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200),
>> daria pra usar só B11.
>>
>>
>> -No 

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Paulo Carvalho]

Oi, Sérgio, o caminho é esse mesmo.  Mas estás usando três variáveis: B11,
NDVI e EVI2.  Em rigor seria necessário um crossplot 3D, mas aí a análise
visual começa a complicar.  Nesse ponto eu usaria um dendrograma para
analisar as classes.  O QGis tem dendrograma?

Em sáb, 15 de set de 2018 às 12:29, Sérgio V.  escreveu:

> Ok, agora entendi esse negócio de manter as variáveis disponíveis sem
> fundir em uma. Valeu!
> -O NDVI distingue bem vegetal do que não é, e as classes de vegetal em
> diferentes graus de clorofila nas folhas, isto é crescimento, atividade
> vegetal. Mas nas matas densas tem mata nativa + mata plantada (pinus
> principalmente no RS). Mata plantada tem sempre atividade mais alta e
> valores mais altos de NDVI. Mata nativa já mistura: tem áreas e indivíduos
> com ambos estados, em crescimento e em estagnação/maturidade, mas tende a
> menor atividade de crescimento.
>
> Assim NDVI não distingue estas 2 dentro da mata ou em contato de bordas.
> Mas em imagem hi-res do Bing já é fácil distinguir uma da outra. Existe
> esta distinção de área de mata nativa separada de área de mata plantada.
>
> -O B11 distingue muito bem uma da outra, aproximadamente por volta do
> valor 1000: ~200 a 1000 (mais escuro) mata planta; ~1000 a 1600 (mais
> claro) mata nativa. Porém não distingue bem água/rio/sombra que fica entre
> ~0 a 300. Afeta um tanto pelas sombras em encostas, onde baixa o valor.
>
> Do que entendi, assim, usando ao mesmo tempo as 2 variáveis, uma poderia fazer
> o recorte onde a outra ainda mistura alguma coisa, uma apara as arestas
> da outra.
>
>
> Abaixo segue crossplot e mapa, coloridos na mesma base, as cores de NDVI
> para 12 classes. EVI2 é quase igual a EVI e a NDVI. Mas dizem que EVI e
> EVI2 são melhores para matas densas. NDVI pra vegetação em geral.
>
>
> "EVI (Enhanced Vegetation Index) - In areas of dense canopy where the
> leaf area index (LAI) is high, the NDVI values can be improved by
> leveraging information in the blue wavelength. " (
> https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts
> )
>
>
> "...contrary to that notion the Amazon forest does exhibit distinct growth
> during the dry season..." (
> https://en.wikipedia.org/wiki/Enhanced_vegetation_index - # Application
> of EVI...)
>
>
> A ver o que acham.
>
> https://i.imgur.com/9dBhNjC.jpg
>
>
> Obrigado!
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
>
> --
> *De:* Paulo Carvalho 
> *Enviado:* sexta-feira, 14 de setembro de 2018 18:14
> *Para:* OSM talk-br
> *Assunto:* Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2
>
> O problema, Sérgio, quando se usa uma fórmula, efetivamente estás
> resumindo duas variáveis a uma variável só.  Pela forma da mancha no
> crossplot B11 versus NDVI, a correlação entre elas não é linear, ou seja,
> elas não informam a mesma coisa.  Pelo contrário, temos que aumentar a
> dimensionalidade.  Seria importante vermos como os pontos se agrupam.
> Talvez haja até bem mais do que duas classes.
>
> Em sex, 14 de set de 2018 às 17:10, Sérgio V. 
> escreveu:
>
> Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único
> pixel"
>
>
> A coisa que me intriga ainda é que estava reexaminando as imagens e
> histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que
> pode ser confirmada na alta resolução do Bing.
>
> E os histogramas me parecem ainda indicar que apontam para a confirmação da
> formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de
> classes e diferenciação de:
>
> 1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)
>
> 2)forest  (mais jovem, mais úmida, mais ativa em clorofila)
>
> 3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para
> "null").
>
>
> Imagens junto com histogramas correspondentes do caso B11 x
> ((1-NDVI)*4000):
>
> https://i.imgur.com/4uKNw1r.jpg
>
> É a mesma área que peguei como exemplo desde o início, porque tem todos os
> tipos que poderiam interferir, e dá pra examinar se o resultado distingue
> bem wood e forest do resto:
>
> wood; forest; river; pond; campos ralos; farmland; estradas; ...
>
> Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos,
> de vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood
> variam mais no espectro: há área velhas e algumas em crescimento. Então há
> mistura das 2 classes.
>
> Já no B11 se destacam bem claramente entre si: uma não invade a margem de
> valores da outra.
>
>
> Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200),
> daria pra usar só B11.
>
>
> -No Cerrado, por exemplo, bastou usar só B11, não tem mata jovem/forest,
> nem mais úmida, deu pra usar só B11:
>
> água no B11 (~50a600) ;  wood(~1000a1300).
>
> É que também os tipos são de vegetação do Cerrado são diferentes, matas
> mais secas, mais castigadas, do que as matas mais úmidas da Mata Atlântica.
> Acho sempre vão 

Re: [Talk-cz] Brána na hlavní silnici vedoucí přes vojenský újezd

[xkomc...@centrum.cz]

Jo, access=yes by asi šlo (promiň, Mirku, já ten tvůj mail špatně 
pochopil jako "nevím co bych tam dal, ale nejspíš access=permisive", 
nikoliv jako "dal bych tam něco z access, od pasu střílím že permissive, 
ale možná jinou hodnotu" jak jsi to asi myslel ty).



Přidáno, uvidíme během pár dní, co to udělá s routováním.


Prozatím všem zúčastněným díky!


On 15.9.2018 23:40, majka wrote:


On Sat, 15 Sep 2018 at 22:52, xkomc...@centrum.cz 
 > wrote:


Právěže ne, je to normální silnice druhé třídy, která se uzavře jen
párkrát do roka (a to na jeden den s tím, že průjezd je možný pouze
párkrát za den - viz třeba http://www.drahany.wz.cz/informace.html


A to je situace, která tu panuje už od druhé světové války, tudíž
žádné
odebírání "povolení" (které k průjezdu není ani třeba) v nejbližších
letech (či spíše nikdy) nehrozí.


K té 4) by se hodil tag říkající "brána tu fyzicky je, ale spíše pro
okrasu". Pak bych to bral, ale nic takového (rozšířeného) asi není...


On 15.9.2018 22:37, Miroslav Suchy wrote:
> Dne 15.9.2018 v 22:32 xkomc...@centrum.cz
 napsal(a):
>> 4) přidat tag říkající, že závora bývá otevřená (nevím o žádném
takovém a i kdyby, tak jej zřejmě nebude znát routovací
>> software)
> Nevim, ale tipuji:
>    access=permissive
>
> https://wiki.openstreetmap.org/wiki/Cs:Key:access
>
> Tj.
>
>       Přístupno pro veřejnost do té doby, než vlastník toto
povolení odejme, což může z hlediska práva kdykoliv v budoucnu
> udělat.
>


ad 4) ... "brána tu fyzicky je, ale spíše prookrasu"...
Přesně tohle přece ten přístup říká - tj. brána tam je, ale dá se 
projet/projít. Pokud bych to chtěla udělat pro routování 
"blbuvzdorně", tak normálně dát na tu bránu access=yes. Tím je přece 
nastavená na "stále otevřeno". Těch pár výjimek se podle mě rozumně 
ošetřit nedá.



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


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

Re: [Talk-cz] Brána na hlavní silnici vedoucí přes vojenský újezd

[majka]

On Sat, 15 Sep 2018 at 22:52, xkomc...@centrum.cz 
wrote:

> Právěže ne, je to normální silnice druhé třídy, která se uzavře jen
> párkrát do roka (a to na jeden den s tím, že průjezd je možný pouze
> párkrát za den - viz třeba http://www.drahany.wz.cz/informace.html
>
>
> A to je situace, která tu panuje už od druhé světové války, tudíž žádné
> odebírání "povolení" (které k průjezdu není ani třeba) v nejbližších
> letech (či spíše nikdy) nehrozí.
>
>
> K té 4) by se hodil tag říkající "brána tu fyzicky je, ale spíše pro
> okrasu". Pak bych to bral, ale nic takového (rozšířeného) asi není...
>
>
> On 15.9.2018 22:37, Miroslav Suchy wrote:
> > Dne 15.9.2018 v 22:32 xkomc...@centrum.cz napsal(a):
> >> 4) přidat tag říkající, že závora bývá otevřená (nevím o žádném takovém
> a i kdyby, tak jej zřejmě nebude znát routovací
> >> software)
> > Nevim, ale tipuji:
> >access=permissive
> >
> > https://wiki.openstreetmap.org/wiki/Cs:Key:access
> >
> > Tj.
> >
> >   Přístupno pro veřejnost do té doby, než vlastník toto povolení
> odejme, což může z hlediska práva kdykoliv v budoucnu
> > udělat.
> >
>
>
ad 4) ...  "brána tu fyzicky je, ale spíše pro okrasu"...
Přesně tohle přece ten přístup říká - tj. brána tam je, ale dá se
projet/projít. Pokud bych to chtěla udělat pro routování "blbuvzdorně", tak
normálně dát na tu bránu access=yes. Tím je přece nastavená na "stále
otevřeno". Těch pár výjimek se podle mě rozumně ošetřit nedá.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Brána na hlavní silnici vedoucí přes vojenský újezd

[Jan Macura]

Ahoj,

pokud výchozí stav je "otevřeno, vjezd povolen" a jen n-krát do roka, kde
n<10, se ta brána zavře a stav se změní na "vjezd zakázán", pak se to skoro
v ničem neliší od normální silnice, kde taky může dojít k neplánovanému
uzavření z mnoha různých důvodů několikrát v roce. Akorát tady je to
uzavření plánované.
Nebál bych se tedy závoru nechat kde je, a přidal access=yes.

H.

On Sat, 15 Sep 2018 at 22:32, xkomc...@centrum.cz 
wrote:

> Zdravím,
>
> narazil jsem na problém, kdy na silnici druhé třídy, která vede přes
> vojenský újezd, je zaznačena brána -
> https://www.openstreetmap.org/node/4988051322 (vše podle reality - vizte
>
> https://en.mapy.cz/zakladni?x=16.9721126=49.4577555=18=1=58009407=0.982=1.571=0.157
> ). Problém je v tom, že ta brána je uzavřena pouze výjimečně, když se
> koná opravdu velké cvičení. Ovšem kvůli tomu přes tuto silnici nelze
> autem routovat (ani GrapHopper ani OSRM). Silniční kolo to pustí.
>
> Co s tím? Napadlo mne:
> 1) nechat jak je, ať si s tím poradí routovací software (podle mne
> špatně, jelikož routovací software to vyhodnotil správně. Nemá jak
> tušit, že přes závoru routovat může)
> 2) smazat (opět špatně, závora tam fyzicky je a stejně ji někdo obnoví)
> 3) přemístit kousek od cesty a přidat poznámku, ať to nikdo nepřesouvá
> na cestu (špatně, neboť ta závora je fyzicky na té silnici)
> 4) přidat tag říkající, že závora bývá otevřená (nevím o žádném takovém
> a i kdyby, tak jej zřejmě nebude znát routovací software)
>
> Nuže? Jako nejmenší zlo se mi jeví možnost 3), ale třeba to lze řešit i
> jinak.
>
> Jirka Komárek
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Brána na hlavní silnici vedoucí přes vojenský újezd

[xkomc...@centrum.cz]

Právěže ne, je to normální silnice druhé třídy, která se uzavře jen 
párkrát do roka (a to na jeden den s tím, že průjezd je možný pouze 
párkrát za den - viz třeba http://www.drahany.wz.cz/informace.html



A to je situace, která tu panuje už od druhé světové války, tudíž žádné 
odebírání "povolení" (které k průjezdu není ani třeba) v nejbližších 
letech (či spíše nikdy) nehrozí.



K té 4) by se hodil tag říkající "brána tu fyzicky je, ale spíše pro 
okrasu". Pak bych to bral, ale nic takového (rozšířeného) asi není...



On 15.9.2018 22:37, Miroslav Suchy wrote:

Dne 15.9.2018 v 22:32 xkomc...@centrum.cz napsal(a):

4) přidat tag říkající, že závora bývá otevřená (nevím o žádném takovém a i 
kdyby, tak jej zřejmě nebude znát routovací
software)

Nevim, ale tipuji:
   access=permissive

https://wiki.openstreetmap.org/wiki/Cs:Key:access

Tj.

Přístupno pro veřejnost do té doby, než vlastník toto povolení odejme, 
což může z hlediska práva kdykoliv v budoucnu
udělat.

Mirek

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



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

Re: [Talk-cz] Brána na hlavní silnici vedoucí přes vojenský újezd

[Miroslav Suchy]

Dne 15.9.2018 v 22:32 xkomc...@centrum.cz napsal(a):
> 4) přidat tag říkající, že závora bývá otevřená (nevím o žádném takovém a i 
> kdyby, tak jej zřejmě nebude znát routovací
> software)

Nevim, ale tipuji:
  access=permissive

https://wiki.openstreetmap.org/wiki/Cs:Key:access

Tj.

Přístupno pro veřejnost do té doby, než vlastník toto povolení odejme, 
což může z hlediska práva kdykoliv v budoucnu
udělat.

Mirek

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

[Talk-cz] Brána na hlavní silnici vedoucí přes vojenský újezd

[xkomc...@centrum.cz]

Zdravím,

narazil jsem na problém, kdy na silnici druhé třídy, která vede přes 
vojenský újezd, je zaznačena brána - 
https://www.openstreetmap.org/node/4988051322 (vše podle reality - vizte 
https://en.mapy.cz/zakladni?x=16.9721126=49.4577555=18=1=58009407=0.982=1.571=0.157 
). Problém je v tom, že ta brána je uzavřena pouze výjimečně, když se 
koná opravdu velké cvičení. Ovšem kvůli tomu přes tuto silnici nelze 
autem routovat (ani GrapHopper ani OSRM). Silniční kolo to pustí.


Co s tím? Napadlo mne:
1) nechat jak je, ať si s tím poradí routovací software (podle mne 
špatně, jelikož routovací software to vyhodnotil správně. Nemá jak 
tušit, že přes závoru routovat může)

2) smazat (opět špatně, závora tam fyzicky je a stejně ji někdo obnoví)
3) přemístit kousek od cesty a přidat poznámku, ať to nikdo nepřesouvá 
na cestu (špatně, neboť ta závora je fyzicky na té silnici)
4) přidat tag říkající, že závora bývá otevřená (nevím o žádném takovém 
a i kdyby, tak jej zřejmě nebude znát routovací software)


Nuže? Jako nejmenší zlo se mi jeví možnost 3), ale třeba to lze řešit i 
jinak.


Jirka Komárek

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

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Mirek Dlask]

Zkus Osmose
http://osmose.openstreetmap.fr/cs/map/#country=czech_republic_jihomoravsky=4080=1%2C2%2C3=4080=17=49.5694420=16.6614084=1
a můžeš si odzoomovat a začít opravovat ;-)
Nebo jestli chceš seznam objektů označkovaných dvakrát pro Jihomoravský
kraj.
http://osmose.openstreetmap.fr/cs/errors/?country=czech_republic_jihomoravsky=4080=1%2C2%2C3
a kompletní přehled chyb ...
http://osmose.openstreetmap.fr/cs/errors/?country=czech_republic_jihomoravsky==1%2C2%2C3
Další možnost je přímo zobrazení v mapě. To se nedá odkazovat, musíš se tam
doklikat a přesunout postupně. Potom si už pamatuje poslední pozici na mapě.
http://osmose.openstreetmap.fr/cs/map/
-
Sousední fara je využívána církví?  Pak doplnit religion a denomination,
možná office?

so 15. 9. 2018 v 19:15 odesílatel Marián Kyral  napsal:

> On 9/15/18 3:14 PM, Jan Macura wrote:
>
> Ahoj,
>
> On Sat, 15 Sep 2018 at 10:33, Vladimír Slávik 
> wrote:
>
>> PS: Nemám preference jak to má být, jen nechcu dělat půlku práce,
>> případně zrovna tu co se nehodí :-)
>>
>
>  preference je rozhodně toto neduplikovat.
> Kdy je vhodnější samostatný bod a kdy označení funkce přidat ke geometrii
> celého objektu je na posouzení v každém případě zvlášť. Souhlasím s tím, co
> napsal Mirek Dlask.
> Pokud je možné nakreslit kostel jako polygon, pak označení, že jde o
> kostel, patří na ten polygon, protože asi až na vzácné výjimky je celá ta
> stavba kostelem, a ne že je uvnitř budovy vestavěný kostel.
>
> Čili ta editace ad (2) je zcela zbytná a smazatelná.
>
>
> Tak tak. JOSM řve, když najde POI uvnitř stejně otagovaného polygonu
> (parkoviště, kostel...)
> iD to už má taky? Nebo ještě pořád ne.
>
> Není na to nějaký QA nástroj? Rychle jsem kouknul na keepright a osmi, ale
> nic takového jsem tam nenašel.
>
> Marián
>
>
> H.
>
> ___
> Talk-cz mailing 
> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Majka]

Osobně jsem před časem rezignovala a začala ty duplicitní tagy umazávat z 
polygonů - protože jinak se tam bod objevil vzápětí zpátky. Sice jsem poctivě 
dotyčné upozorňovala, ale problém to byl systému, ne jednotlivců. 

Spousta těch duplicit se tam totiž dostává z mobilního mapování - tedy z 
maps.me a z OsmAndu. Ten až v poslední verzi umí editovat tagy na polygonech, 
přidat na polygon (budovu) to podle mě neumí dodnes. A ty kontroly na duplicity 
tam chyběly a možná chybí dodnes.

Jedinou výjimkou, kde jsem vždy smazala bod, byly kostely a školy, kde to podle 
mého patří skoro pokaždé jednoznačně na budovu. 

Majka

15. září 2018 10:32:50 SELČ, "Vladimír Slávik"  
napsal:
>Ahoj,
>všiml jsem si (po roce...) že doslova pár hodin po mé úpravě která dala
>
>vzniknout kostelu (1) někdo přidal i kostel jako bod uprostřed (2). Tak
>
>teď tam jsou dva objekty.
>
>Vzhledem k tomu že moje mapování je asi jak medvěd po zimním spánku - 
>jak se k tomuhle má člověk stavět v poslední době? Je to stále tak
>jaksi 
>libovolně, s tím že většina starých objektů je jen bod? Nebyl jsem 
>schopný najít které pravidlo na to vlastně platí, akorát se matně 
>pamatuju že snad body všude přidávávali lidi co používali nějakou 
>navigaci co neuměla nic jiného než body...
>
>(1) https://www.openstreetmap.org/way/102468040
>(2) https://www.openstreetmap.org/node/5145289501
>
>PS: Nemám preference jak to má být, jen nechcu dělat půlku práce, 
>případně zrovna tu co se nehodí :-)
>
>V+
>
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Marián Kyral]

On 9/15/18 3:14 PM, Jan Macura wrote:
> Ahoj,
>
> On Sat, 15 Sep 2018 at 10:33, Vladimír Slávik
> mailto:slavik.vladi...@seznam.cz>> wrote:
>
> PS: Nemám preference jak to má být, jen nechcu dělat půlku práce,
> případně zrovna tu co se nehodí :-)
>
>
>  preference je rozhodně toto neduplikovat.
> Kdy je vhodnější samostatný bod a kdy označení funkce přidat ke
> geometrii celého objektu je na posouzení v každém případě zvlášť.
> Souhlasím s tím, co napsal Mirek Dlask.
> Pokud je možné nakreslit kostel jako polygon, pak označení, že jde o
> kostel, patří na ten polygon, protože asi až na vzácné výjimky je celá
> ta stavba kostelem, a ne že je uvnitř budovy vestavěný kostel.
>
> Čili ta editace ad (2) je zcela zbytná a smazatelná.
>

Tak tak. JOSM řve, když najde POI uvnitř stejně otagovaného polygonu
(parkoviště, kostel...)
iD to už má taky? Nebo ještě pořád ne.

Není na to nějaký QA nástroj? Rychle jsem kouknul na keepright a osmi,
ale nic takového jsem tam nenašel.

Marián


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

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

[Talk-us] weeklyOSM #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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

[OSM-talk-ie] weeklyOSM #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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 #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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 #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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-in] weeklyOSM #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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 #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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-ph] weeklyOSM #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-africa] weeklyOSM #425 2018-09-04-2018-09-10

[weeklyteam]

The weekly round-up of OSM news, issue # 425,
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/10709/

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-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-it] dataset MISE distributori

[Federico Cortese]

On Fri, Sep 14, 2018, 23:31 Cascafico Giovanni  wrote:

> Io ci ho trafficato un po' ed ho trovato parecchi name non aggiornati.
> Fareste un revert per tornare alla situazione coerente name/brand, ma con
> entrambi non più esistenti?
>

Io mi sono già espresso negativamente rispetto ad un revert, come già avuto
modo di dire sono più gli effetti positivi di questo import che quelli
negativi, seppure è vero che questi ci siano e si sarebbero potuti evitare.
Ad esempio trovo ancora molti nobrand=yes o brand=Pompe Bianche che si era
detto di non mettere.
Ad ogni modo molti dei problemi principali (tipo i nodi duplicati) sono già
stati corretti.
Direi comunque che non sia il caso di aggiungere altre modifiche massicce
da import su quei dati, ma continuare a aggiornarli manualmente.

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

Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

[Sérgio V .]

Ok, agora entendi esse negócio de manter as variáveis disponíveis sem fundir em 
uma. Valeu!
-O NDVI distingue bem vegetal do que não é, e as classes de vegetal em 
diferentes graus de clorofila nas folhas, isto é crescimento, atividade 
vegetal. Mas nas matas densas tem mata nativa + mata plantada (pinus 
principalmente no RS). Mata plantada tem sempre atividade mais alta e valores 
mais altos de NDVI. Mata nativa já mistura: tem áreas e indivíduos com ambos 
estados, em crescimento e em estagnação/maturidade, mas tende a menor atividade 
de crescimento.

Assim NDVI não distingue estas 2 dentro da mata ou em contato de bordas. Mas em 
imagem hi-res do Bing já é fácil distinguir uma da outra. Existe esta distinção 
de área de mata nativa separada de área de mata plantada.

-O B11 distingue muito bem uma da outra, aproximadamente por volta do valor 
1000: ~200 a 1000 (mais escuro) mata planta; ~1000 a 1600 (mais claro) mata 
nativa. Porém não distingue bem água/rio/sombra que fica entre ~0 a 300. Afeta 
um tanto pelas sombras em encostas, onde baixa o valor.

Do que entendi, assim, usando ao mesmo tempo as 2 variáveis, uma poderia fazer 
o recorte onde a outra ainda mistura alguma coisa, uma apara as arestas da 
outra.


Abaixo segue crossplot e mapa, coloridos na mesma base, as cores de NDVI para 
12 classes. EVI2 é quase igual a EVI e a NDVI. Mas dizem que EVI e EVI2 são 
melhores para matas densas. NDVI pra vegetação em geral.


"EVI (Enhanced Vegetation Index) - In areas of dense canopy where the leaf area 
index (LAI) is high, the NDVI values can be improved by leveraging information 
in the blue wavelength. " 
(https://www.sentinel-hub.com/develop/documentation/eo_products/Sentinel2EOproducts)


"...contrary to that notion the Amazon forest does exhibit distinct growth 
during the dry season..." 
(https://en.wikipedia.org/wiki/Enhanced_vegetation_index - # Application of 
EVI...)


A ver o que acham.

https://i.imgur.com/9dBhNjC.jpg


Obrigado!

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

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Paulo Carvalho 
Enviado: sexta-feira, 14 de setembro de 2018 18:14
Para: OSM talk-br
Assunto: Re: [Talk-br] Vetorização de matas no OSM com Sentinel-2

O problema, Sérgio, quando se usa uma fórmula, efetivamente estás resumindo 
duas variáveis a uma variável só.  Pela forma da mancha no crossplot B11 versus 
NDVI, a correlação entre elas não é linear, ou seja, elas não informam a mesma 
coisa.  Pelo contrário, temos que aumentar a dimensionalidade.  Seria 
importante vermos como os pontos se agrupam.  Talvez haja até bem mais do que 
duas classes.

Em sex, 14 de set de 2018 às 17:10, Sérgio V. 
mailto:svo...@hotmail.com>> escreveu:

Ok, ainda vou ver como fazer pra "definir a marca do crossplot para um único 
pixel"


A coisa que me intriga ainda é que estava reexaminando as imagens e 
histogramas, nos pontos onde há certeza das 2 classes, wood e forest, que pode 
ser confirmada na alta resolução do Bing.

E os histogramas me parecem ainda indicar que apontam para a confirmação da 
formulação empírica / gambiarra B11 x ((1-NDVI)*4000), nos valores de classes e 
diferenciação de:

1)wood (mais velha, pouco menos úmida, menos ativa em clorofila)

2)forest  (mais jovem, mais úmida, mais ativa em clorofila)

3)o que não é nenhum dos 2 e pode ser retirado de vetorização (para "null").


Imagens junto com histogramas correspondentes do caso B11 x ((1-NDVI)*4000):

https://i.imgur.com/4uKNw1r.jpg


É a mesma área que peguei como exemplo desde o início, porque tem todos os 
tipos que poderiam interferir, e dá pra examinar se o resultado distingue bem 
wood e forest do resto:

wood; forest; river; pond; campos ralos; farmland; estradas; ...


Nos histogramas, no NDVI, as forest ocupam sempre os níveis mais altos, de 
vegetação crescendo ativamente; como próprio do NDVI; enquanto as wood variam 
mais no espectro: há área velhas e algumas em crescimento. Então há mistura das 
2 classes.

Já no B11 se destacam bem claramente entre si: uma não invade a margem de 
valores da outra.


Se não fosse a água no B11 (~50a300) se misturar com forest(~150a1200), daria 
pra usar só B11.


-No Cerrado, por exemplo, bastou usar só B11, não tem mata jovem/forest, nem 
mais úmida, deu pra usar só B11:

água no B11 (~50a600) ;  wood(~1000a1300).

É que também os tipos são de vegetação do Cerrado são diferentes, matas mais 
secas, mais castigadas, do que as matas mais úmidas da Mata Atlântica. Acho 
sempre vão apresentar valores um tanto diferentes tendendo pro mais seco.

https://wiki.openstreetmap.org/wiki/User:SergioAJV/Sentinel-2_vectorizing_tests#Cerrado_.28vetorizado_e_100.25_validado_para_OSM.29


-Já na Amazônia, úmida mas também com áreas de mata velha, a ponderação teve 
que ser não x4000, mas x500, para B11 + ((1- NDVI ) * 500 ):

[Talk-it] biciclette su highway=trunk

[Volker Schmidt]

Probabilmante già discusso più volte.

Quali highway=x escludono come default le biciclette?

highway=motorway | motorway_link | motorroad | motorroad_link   SI!

highway=trunk | trunk_link  ???

highway=primary | swcondary | ...  NO!


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

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Jan Macura]

Ahoj,

On Sat, 15 Sep 2018 at 10:33, Vladimír Slávik 
wrote:

> PS: Nemám preference jak to má být, jen nechcu dělat půlku práce,
> případně zrovna tu co se nehodí :-)
>

 preference je rozhodně toto neduplikovat.
Kdy je vhodnější samostatný bod a kdy označení funkce přidat ke geometrii
celého objektu je na posouzení v každém případě zvlášť. Souhlasím s tím, co
napsal Mirek Dlask.
Pokud je možné nakreslit kostel jako polygon, pak označení, že jde o
kostel, patří na ten polygon, protože asi až na vzácné výjimky je celá ta
stavba kostelem, a ne že je uvnitř budovy vestavěný kostel.

Čili ta editace ad (2) je zcela zbytná a smazatelná.

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

Re: [OSM-talk-fr] Arrêts de bus sans nom dans MAPS.ME

[garminup]

If you are facing any kind of issues with your Garmin Device updates, Just
call us @ 844-277-4958 our toll free number from any place of USA & UK. For
more information about free Garmin Map Update visit our official website:
https://www.skymapupdate.com/blog/free-garmin-map-update/



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

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

Re: [OSM-talk-fr] Les bretelles

[marc marc]

le preprocesseur peux tres bien analyser la moindre diff
c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie 
toutes les bretelles d'une route pour mettre à jour un tag 
mono-utilisateur :)

publie qlq part stp un extrait rendu osm <> rendu avec ta modif
(ou extrait michelin), j'ai du mal a imaginer la chose.


Le 15. 09. 18 à 11:01, djakk djakk a écrit :
> Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour 
> récupérer l’info, mais en pratique difficile de faire un pré-processeur 
> pour les données énormes et très mouvantes d’osm. De plus, je pense que 
> pour les collectrices c’est impossible d’y arriver.
> 
> Le rendu correspondrait à la plupart des cartes, par exemple les cartes 
> Michelin papier.
> 
> 
> djakk
> 
> Le sam. 15 sept. 2018 à 10:09, marc marc  > a écrit :
> 
> Bonjour djakk,
> 
> Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
> 
>  > si on relie une autoroute à une tertiary, on pourrait
>  > choisir au niveau du rendu de ne pas afficher la bretelle.
> 
> je ne suis pas sur de comprendre.
> De quel rendu tu parles ? un rendu perso ?
> tu peux poster qlq part un extrait de carte qui n'afficherait pas
> certains bretelles parce que autoroute-tertiary  ?
> 
>  > Impossible en l’état actuel.
> 
> Parmis les spécialistes des styles de rendu, quelqu'un confirme
> qu'on ne peux pas récupérer le type de voie inférieur connectée à un
> bretelle ?
> si c'était confirmée, cela me semble bien + un problème de rendu
> qu'un problème de donnée.
> s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
> pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le
> cas réel d'utilisation)
> 
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour
récupérer l’info, mais en pratique difficile de faire un pré-processeur
pour les données énormes et très mouvantes d’osm. De plus, je pense que
pour les collectrices c’est impossible d’y arriver.

Le rendu correspondrait à la plupart des cartes, par exemple les cartes
Michelin papier.


djakk

Le sam. 15 sept. 2018 à 10:09, marc marc  a
écrit :

> Bonjour djakk,
>
> Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :
>
> > si on relie une autoroute à une tertiary, on pourrait
> > choisir au niveau du rendu de ne pas afficher la bretelle.
>
> je ne suis pas sur de comprendre.
> De quel rendu tu parles ? un rendu perso ?
> tu peux poster qlq part un extrait de carte qui n'afficherait pas
> certains bretelles parce que autoroute-tertiary  ?
>
> > Impossible en l’état actuel.
>
> Parmis les spécialistes des styles de rendu, quelqu'un confirme
> qu'on ne peux pas récupérer le type de voie inférieur connectée à un
> bretelle ?
> si c'était confirmée, cela me semble bien + un problème de rendu
> qu'un problème de donnée.
> s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
> pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le
> cas réel d'utilisation)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Mirek Dlask]

Ahoj,
preference jsou značně individuální.
U kostelů dávám přednost tagování na budově.
- není moc vícefunkčních kostelů
- render může budovu kostela zvýraznit.
Naopak obchody je lepe mít jako bod
- jedno pekařství jsem "stěhoval" už dvakrát
- v jedné budově může být více obchodů.

so 15. 9. 2018 v 10:33 odesílatel Vladimír Slávik 
napsal:

> Ahoj,
> všiml jsem si (po roce...) že doslova pár hodin po mé úpravě která dala
> vzniknout kostelu (1) někdo přidal i kostel jako bod uprostřed (2). Tak
> teď tam jsou dva objekty.
>
> Vzhledem k tomu že moje mapování je asi jak medvěd po zimním spánku -
> jak se k tomuhle má člověk stavět v poslední době? Je to stále tak jaksi
> libovolně, s tím že většina starých objektů je jen bod? Nebyl jsem
> schopný najít které pravidlo na to vlastně platí, akorát se matně
> pamatuju že snad body všude přidávávali lidi co používali nějakou
> navigaci co neuměla nic jiného než body...
>
> (1) https://www.openstreetmap.org/way/102468040
> (2) https://www.openstreetmap.org/node/5145289501
>
> PS: Nemám preference jak to má být, jen nechcu dělat půlku práce,
> případně zrovna tu co se nehodí :-)
>
> V+
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] Body uvnitř stejně tagovaných ploch

[Vladimír Slávik]

Ahoj,
všiml jsem si (po roce...) že doslova pár hodin po mé úpravě která dala 
vzniknout kostelu (1) někdo přidal i kostel jako bod uprostřed (2). Tak 
teď tam jsou dva objekty.


Vzhledem k tomu že moje mapování je asi jak medvěd po zimním spánku - 
jak se k tomuhle má člověk stavět v poslední době? Je to stále tak jaksi 
libovolně, s tím že většina starých objektů je jen bod? Nebyl jsem 
schopný najít které pravidlo na to vlastně platí, akorát se matně 
pamatuju že snad body všude přidávávali lidi co používali nějakou 
navigaci co neuměla nic jiného než body...


(1) https://www.openstreetmap.org/way/102468040
(2) https://www.openstreetmap.org/node/5145289501

PS: Nemám preference jak to má být, jen nechcu dělat půlku práce, 
případně zrovna tu co se nehodí :-)


V+


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

Re: [OSM-talk-fr] Les bretelles

[marc marc]

Bonjour djakk,

Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit :

> si on relie une autoroute à une tertiary, on pourrait
> choisir au niveau du rendu de ne pas afficher la bretelle.

je ne suis pas sur de comprendre.
De quel rendu tu parles ? un rendu perso ?
tu peux poster qlq part un extrait de carte qui n'afficherait pas 
certains bretelles parce que autoroute-tertiary  ?

> Impossible en l’état actuel.

Parmis les spécialistes des styles de rendu, quelqu'un confirme
qu'on ne peux pas récupérer le type de voie inférieur connectée à un 
bretelle ?
si c'était confirmée, cela me semble bien + un problème de rendu
qu'un problème de donnée.
s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info
pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le 
cas réel d'utilisation)

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

[Talk-at] Einladung zum OSM Stammtisch Leoben / Obersteiermark

[Borut Maricic]

Wann: Donnerstag, 20.09.2018, ab 18:00 Uhr
Wo:   "Zum Italo-Steierer", Bachgasse 8, Leoben (Göß)

Einige Themen stehen fest. Weitere sind willkommen:

https://wiki.openstreetmap.org/wiki/Leoben/Stammtisch

Wir bleiben fast immer bis 22:00 Uhr. Ein Transfer vom
Bahnhof zum Tisch und zurück ist bei Bedarf auch möglich
- bitte mich anschreiben.

Herzlich willkommen!

Liebe Grüße,
Borut (Borut@OSM)


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