date:20161222

On Fri, Dec 23, 2016 at 12:03 AM, Glenn Plas  wrote:
>>
>> Furthermore the data is not deleted from any dataset that was taken
>> from the main server before the "purge" is done. Not everybody
>> realizes this (although I know Glenn does)
>
> Like -every- preceding mapping mistake :)   Probably won't be an issue
> for most consumers.

Not for the consumers, but for the license holder that do not want
their data to be distributed.

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

Re: [Talk-ca] Community Conduct

Stewart, after re-reading what you posted, it seems to be about the imagery
and not derived works. Aka, you cant sell the imagery, use it for finacial
gain(duh), but says nothing about derivative works from which I was told
was allowed. Clairification would be in order indeed.

On Dec 22, 2016 8:11 PM, "Stewart C. Russell"  wrote:

> On 2016-12-22 07:47 PM, James wrote:
> > From what was told to me at the school,  Stewart, you are allowed to
> > create derivative work/tracing, but not distribute the imagery.
>
> You may be able to create derivative work, but solely for teaching or
> academic purposes. The most recent Carleton University Data Use
> Agreement I can find
> ( DataUseAgreement.pdf>)
> says:
>
>   I am affiliated with Carleton University as a current
>   faculty member, student or staff member and I agree to
>   abide by the terms of the University’s contractual
>   obligations to the owner of the data. Data obtained
>   by this agreement is protected by copyright and remain
>   the property of the data producer. I understand that:
>
>   * The data provided to me is for the exclusive purposes
>   of teaching or academic research while I am a member
>   of the Carleton University community and may not be
>   used for any other purposes without the explicit prior
>   written approval of the owner of the data.
>
>   * I am prohibited from using these data products in
>   the pursuit of any commercial or income-generating
>   venture either privately, with government, or under
>   the auspices of Carleton University.
>
>   * The data is released to me as a working copy for my
>   use only. The distribution, sale, donation, transfer,
>   sharing or exchange of any portion of these data in
>   any way is expressly prohibited.
>
>   * The data is accepted ”as is”, and that the
>   owner makes no representations or warranties, either
>   expressed or implied, as to the appropriateness and
>   fitness for a particular purpose.
>
>   * All publications, paper printouts, or manuscripts
>   containing the data must acknowledge explicitly the
>   owner of the data.
>
>   * Licensed downloaded data files must be erased
>   upon the completion of my research project, course
>   assignment, or thesis work.
>
>   * Use of the data may be subject to audit by the data
>   producer; so that in the event of audits, my use of
>   the data may be disclosed to the producer.
>
>   Data covered by this agreement:
>
>   Data listed below is stored on the Library GIS network
>   and is available only to Carleton University students,
>   faculty and staff upon presentation of current
>   university identification.
>
>   Licenced data include files from agencies of the
>   Government of Canada, the Government of Ontario,
>   the Government of Quebec, cities of Ottawa, Hamilton,
>   London and Niagara, commercial providers such as DMTI,
>   Teranet, and Landlnfo, and any other data providers
>   which require authenticated access. A full list of
>   data providers is available on the GIS website.
>
> I would say that this unequivocally prevents the data being used as an
> OSM source. Again, I ask you to refrain from using it until the licence
> is clarified by the Carleton library.
>
> Best Wishes,
>  Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

2016-12-22 Thread Pierre Béland

Eh assez de problèmes comme cela. Permettez moi de dévier un peu cette 
discussion et parler d'autres problèmes qui me préoccupent davantage.
J'arrive de Jérémie, Haiti où la situation est toujours critique 10 semaines 
après l'ouragan Matthew.  Tout est cassé à Jérémie, les maisons, les écoles, 
les églises, les espoirs. En montagne, plusieurs villages isolées n'ont pas 
reçu d'aide et les problèmes de santé sont criants.

Un article du Journal Le Monde montre bien la situation problématique pour les 
populations dans les montagnes des départements de Grande Anse et du 
Sud.http://www.lemonde.fr/planete/article/2016/12/12/en-haiti-deux-mois-apres-l-ouragan-matthew-les-estomacs-sont-vides_5047254_3244.html#bsMe9EDCAcvMQcsf.99

James, tu dois prendre un "Break" et éviter des "conflits supplémentaires" en 
incluant maintenant les franco :) 
Joyeux Noel. 
 
Pierre 


  De : john whelan 
 À : James  
Cc : Paul Norman ; Talk-CA OpenStreetMap 

 Envoyé le : jeudi 22 décembre 2016 19h00
 Objet : Re: [Talk-ca] Community Conduct
   
> no one maps Gatineau(seriously, maybe cause it's the French side?)

Tact my son tact, look the word up in the dictionary or you'll have Pierre 
descending on Ottawa demanding double Lattes.

Cheerio John

On 22 December 2016 at 18:40, James  wrote:

Paul, I am aware of conflicts may occur, but seeing as no one maps 
Gatineau(seriously, maybe cause it's the French side?) I'm not that scared to 
go on a mapping session all day long. In Toronto or Ottawa is a different 
story, in which I would commit more often.

On Thu, Dec 22, 2016 at 6:35 PM, Paul Norman  wrote:

  On 12/22/2016 3:21 PM, James wrote:
 
As pnorman has said in the past( https://lists.openstreetmap.or 
g/pipermail/talk-ca/2016-Septe mber/007260.html):
 
  Uploaded in small enough parts that the changesets make sense. This means 
never uploading more than 50k objects at once, and typically fewer than 10k.
 
 
 I try to keep my changes under 10k, but with buildings, nodes multiply quickly 
as there are minimum 4 per building(rare usually average 6-10 depending on 
complexity)
 
 
 The numbers quoted are in the context of an import where the concerns are the 
ability to revert, working with the changeset in other tools, not leaving stray 
nodes in the database, not splitting one upload over multiple changesets, and 
not having a broken upload. I wouldn't recommend exceeding them for any work, 
but a non-import is out of the scope of the CanVec post linked.
 
 Personally, I'd get worried about conflicts, lost work, and want to upload 
well before 1k changes, let alone 10k. Those often aren't a problem with an 
import, or if they are they can be easier to solve, but with normal mapping 
solving them often requires more thought.
 
 
__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk-ca





-- 
外に遊びに行こう！
__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk-ca




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


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

Re: [Talk-ca] Community Conduct

My expectation is the full City of Ottawa building foot print file will be
made available around the twelfth of January on their Open Data portal.
Although the formal decision has been made apparently they allow their
employees to take vacation from time to time hence the delay.  At which
point the image data from Carlton is no longer as attractive.

My suggestion from a practical point of view would be to stop using the
Carlton source, but since it is all City of Ottawa data and the City of
Ottawa have been very cooperative on their open data that we leave the
buildings that have been traced so far in the Map.  I honestly don't think
the City of Ottawa will be stomping all over us especially as effectively
the building foot prints will be made available in early January.

Cheerio John

On 22 December 2016 at 20:09, Stewart C. Russell  wrote:

> On 2016-12-22 07:47 PM, James wrote:
> > From what was told to me at the school,  Stewart, you are allowed to
> > create derivative work/tracing, but not distribute the imagery.
>
> You may be able to create derivative work, but solely for teaching or
> academic purposes. The most recent Carleton University Data Use
> Agreement I can find
> ( DataUseAgreement.pdf>)
> says:
>
>   I am affiliated with Carleton University as a current
>   faculty member, student or staff member and I agree to
>   abide by the terms of the University’s contractual
>   obligations to the owner of the data. Data obtained
>   by this agreement is protected by copyright and remain
>   the property of the data producer. I understand that:
>
>   * The data provided to me is for the exclusive purposes
>   of teaching or academic research while I am a member
>   of the Carleton University community and may not be
>   used for any other purposes without the explicit prior
>   written approval of the owner of the data.
>
>   * I am prohibited from using these data products in
>   the pursuit of any commercial or income-generating
>   venture either privately, with government, or under
>   the auspices of Carleton University.
>
>   * The data is released to me as a working copy for my
>   use only. The distribution, sale, donation, transfer,
>   sharing or exchange of any portion of these data in
>   any way is expressly prohibited.
>
>   * The data is accepted ”as is”, and that the
>   owner makes no representations or warranties, either
>   expressed or implied, as to the appropriateness and
>   fitness for a particular purpose.
>
>   * All publications, paper printouts, or manuscripts
>   containing the data must acknowledge explicitly the
>   owner of the data.
>
>   * Licensed downloaded data files must be erased
>   upon the completion of my research project, course
>   assignment, or thesis work.
>
>   * Use of the data may be subject to audit by the data
>   producer; so that in the event of audits, my use of
>   the data may be disclosed to the producer.
>
>   Data covered by this agreement:
>
>   Data listed below is stored on the Library GIS network
>   and is available only to Carleton University students,
>   faculty and staff upon presentation of current
>   university identification.
>
>   Licenced data include files from agencies of the
>   Government of Canada, the Government of Ontario,
>   the Government of Quebec, cities of Ottawa, Hamilton,
>   London and Niagara, commercial providers such as DMTI,
>   Teranet, and Landlnfo, and any other data providers
>   which require authenticated access. A full list of
>   data providers is available on the GIS website.
>
> I would say that this unequivocally prevents the data being used as an
> OSM source. Again, I ask you to refrain from using it until the licence
> is clarified by the Carleton library.
>
> Best Wishes,
>  Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-pt] HOT Tasking Manager: Gestor de tarefas para parties e outras atividades

2016-12-22 Thread Marcos Oliveira

Olá a todos,

Agradeçam ao Filipe e ao Rui pelo seu trabalho de tradução!

Jorge, eu já tenho experiência com esta ferramenta [1], qualquer dúvida que
tenhas ficarei feliz em ajudar.

Pedro, apoio a ideia da mapping party em Guimarães, até porque com o HOT
podemos ter elementos a fazer algum "armchair mapping" caso não possam
comparecer, visto que podem ter uma parcela designada só para eles.

[1] - http://tasks.hotosm.org/project/580

No dia 23 de dezembro de 2016 às 01:23, Pedro Pereira 
escreveu:

> Boas,
>
> Eu estou em condições de agendar uma party em Guimarães, na Vila das
> Taipas (Caldelas), no entanto acho que é um pouco em cima agendar uma party
> até final do ano, até porque eu queria envolver alunos da escola secundária
> e talvez de geografia da Univ. Minho.
> Poderemos pensar nisso para Janeiro, caso consigamos angariar um grupo
> porreiro de membros experientes para orientar os mais inexperientes.
>
> Abraço
> Pedro
>
> 2016-12-22 23:58 GMT+00:00 Jorge Gustavo Rocha :
>
>> Malta,
>>
>> Já vi algumas instalações do HOT Tasking Manager [1] e achei muito
>> interessante para suportar algumas das nossas atividades de mapeamento.
>>
>> De uma forma sucinta, a ferramenta permite dividir uma área em tarefas,
>> dar um conjunto de instruções sobre o que é prioritário para mapear, e
>> depois os mapeadores escolhem as áreas onde querem trabalhar. A ferramenta
>> ajuda a que uns não trabalhem em cima dos outros e dá umas estatísticas do
>> que está feito e o que está por fazer. Acho uma ótima ferramenta para as
>> nossas parties. Mas...
>>
>> Mas não tenho grande experiência com a ferramenta e precisava da vossa
>> ajuda para aprendermos a usá-lo e para termos várias pessoas que o possam
>> administrar.
>>
>> Instalei o software no endereço: http://tarefas.openstreetmap.pt
>>
>> 1. Aparentemente, por ter sido o primeiro a entrar, fiquei como
>> "administrador". Entra-se com a conta existente do OpenStreetMap. Há três
>> níveis de utilizadores [2]: user, project manager e administrator. Façam
>> login e mandem-me um email (ou uma mensagem no skype) para vos passar para
>> "project manager" ou "administrator", para poderem criar projetos e mudarem
>> o perfil de outros utilizadores.
>>
>> 2. Primeiro projeto. Quem quer definir um primeiro projeto para
>> experimentarmos a plataforma e fazermos alguma coisa de útil? Ou quem quer
>> organizar uma party entre o Natal e o fim de ano?
>> Independentemente de se criar um primeiro projeto "real", estejam à
>> vontade para criarem projetos de teste.
>> Com a instalação, já vem um projeto "Kathmandu" em rascunho (isto é, não
>> publicado para o público). Deixei ficar para se ver como é.
>>
>> 3. Aparentemente as traduções estão a funcionar. Parabéns a quem fez o
>> trabalho. Quem quiser contribuir para as traduções, as mesmas estão no
>> Transifex [3].
>>
>> 4. Para quem quiser ler um pouco sobre a ferramenta, há documentação no
>> wiki [4], mas a do LearnOSM é mais detalhada [5] e [6]. O MapGive [7]
>> também usa este Gestor de tarefas.
>>
>> 5. A ferramenta é open source [8]. Dá para "customizar" esta instalação
>> para Portugal (podemos por um logotipo ou umas cores diferentes...) e dá
>> para fazer alterações ao código. Se tiverem sugestões, apitem.
>>
>> Espero que a ferramenta seja útil e ajude a melhorarmos o nosso mapa.
>>
>> Bom trabalho,
>>
>> J. Gustavo
>>
>>
>> URL usados na mensagem:
>>
>> [1] http://tasks.hotosm.org/
>> [2] http://learnosm.org/en/coordination/tasking-manager-project-
>> admin/#logging-in-amp-access-levels
>> [3] https://www.transifex.com/hotosm/osm-tasking-manager2/
>> [4] http://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager
>> [5] http://learnosm.org/en/coordination/tasking-manager/
>> [6] http://learnosm.org/en/coordination/tasking-manager-project-admin/
>> [7] https://mapgive.state.gov/
>> [8] https://github.com/hotosm/osm-tasking-manager2
>>
>>
>> J. Gustavo
>> --
>> Jorge Gustavo Rocha
>> Departamento de Informática
>> Universidade do Minho
>> 4710-057 Braga
>> Tel: +351 253604480
>> Fax: +351 253604471
>> Móvel: +351 910333888
>> skype: nabocudnosor
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
>
>
>
> --
> Pedro Pereira
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-pt] HOT Tasking Manager: Gestor de tarefas para parties e outras atividades

2016-12-22 Thread Pedro Pereira

Boas,

Eu estou em condições de agendar uma party em Guimarães, na Vila das Taipas
(Caldelas), no entanto acho que é um pouco em cima agendar uma party até
final do ano, até porque eu queria envolver alunos da escola secundária e
talvez de geografia da Univ. Minho.
Poderemos pensar nisso para Janeiro, caso consigamos angariar um grupo
porreiro de membros experientes para orientar os mais inexperientes.

Abraço
Pedro

2016-12-22 23:58 GMT+00:00 Jorge Gustavo Rocha :

> Malta,
>
> Já vi algumas instalações do HOT Tasking Manager [1] e achei muito
> interessante para suportar algumas das nossas atividades de mapeamento.
>
> De uma forma sucinta, a ferramenta permite dividir uma área em tarefas,
> dar um conjunto de instruções sobre o que é prioritário para mapear, e
> depois os mapeadores escolhem as áreas onde querem trabalhar. A ferramenta
> ajuda a que uns não trabalhem em cima dos outros e dá umas estatísticas do
> que está feito e o que está por fazer. Acho uma ótima ferramenta para as
> nossas parties. Mas...
>
> Mas não tenho grande experiência com a ferramenta e precisava da vossa
> ajuda para aprendermos a usá-lo e para termos várias pessoas que o possam
> administrar.
>
> Instalei o software no endereço: http://tarefas.openstreetmap.pt
>
> 1. Aparentemente, por ter sido o primeiro a entrar, fiquei como
> "administrador". Entra-se com a conta existente do OpenStreetMap. Há três
> níveis de utilizadores [2]: user, project manager e administrator. Façam
> login e mandem-me um email (ou uma mensagem no skype) para vos passar para
> "project manager" ou "administrator", para poderem criar projetos e mudarem
> o perfil de outros utilizadores.
>
> 2. Primeiro projeto. Quem quer definir um primeiro projeto para
> experimentarmos a plataforma e fazermos alguma coisa de útil? Ou quem quer
> organizar uma party entre o Natal e o fim de ano?
> Independentemente de se criar um primeiro projeto "real", estejam à
> vontade para criarem projetos de teste.
> Com a instalação, já vem um projeto "Kathmandu" em rascunho (isto é, não
> publicado para o público). Deixei ficar para se ver como é.
>
> 3. Aparentemente as traduções estão a funcionar. Parabéns a quem fez o
> trabalho. Quem quiser contribuir para as traduções, as mesmas estão no
> Transifex [3].
>
> 4. Para quem quiser ler um pouco sobre a ferramenta, há documentação no
> wiki [4], mas a do LearnOSM é mais detalhada [5] e [6]. O MapGive [7]
> também usa este Gestor de tarefas.
>
> 5. A ferramenta é open source [8]. Dá para "customizar" esta instalação
> para Portugal (podemos por um logotipo ou umas cores diferentes...) e dá
> para fazer alterações ao código. Se tiverem sugestões, apitem.
>
> Espero que a ferramenta seja útil e ajude a melhorarmos o nosso mapa.
>
> Bom trabalho,
>
> J. Gustavo
>
>
> URL usados na mensagem:
>
> [1] http://tasks.hotosm.org/
> [2] http://learnosm.org/en/coordination/tasking-manager-project-
> admin/#logging-in-amp-access-levels
> [3] https://www.transifex.com/hotosm/osm-tasking-manager2/
> [4] http://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager
> [5] http://learnosm.org/en/coordination/tasking-manager/
> [6] http://learnosm.org/en/coordination/tasking-manager-project-admin/
> [7] https://mapgive.state.gov/
> [8] https://github.com/hotosm/osm-tasking-manager2
>
>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>



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

Re: [Talk-ca] Community Conduct

It may take a while for them to respond, due to the christmas holiday and
all.

On Dec 22, 2016 8:13 PM, "James"  wrote:

> Will do. If it needs to be reverted, I will do so.
>
> On Dec 22, 2016 8:11 PM, "Stewart C. Russell"  wrote:
>
>> On 2016-12-22 07:47 PM, James wrote:
>> > From what was told to me at the school,  Stewart, you are allowed to
>> > create derivative work/tracing, but not distribute the imagery.
>>
>> You may be able to create derivative work, but solely for teaching or
>> academic purposes. The most recent Carleton University Data Use
>> Agreement I can find
>> (> ataUseAgreement.pdf>)
>> says:
>>
>>   I am affiliated with Carleton University as a current
>>   faculty member, student or staff member and I agree to
>>   abide by the terms of the University’s contractual
>>   obligations to the owner of the data. Data obtained
>>   by this agreement is protected by copyright and remain
>>   the property of the data producer. I understand that:
>>
>>   * The data provided to me is for the exclusive purposes
>>   of teaching or academic research while I am a member
>>   of the Carleton University community and may not be
>>   used for any other purposes without the explicit prior
>>   written approval of the owner of the data.
>>
>>   * I am prohibited from using these data products in
>>   the pursuit of any commercial or income-generating
>>   venture either privately, with government, or under
>>   the auspices of Carleton University.
>>
>>   * The data is released to me as a working copy for my
>>   use only. The distribution, sale, donation, transfer,
>>   sharing or exchange of any portion of these data in
>>   any way is expressly prohibited.
>>
>>   * The data is accepted ”as is”, and that the
>>   owner makes no representations or warranties, either
>>   expressed or implied, as to the appropriateness and
>>   fitness for a particular purpose.
>>
>>   * All publications, paper printouts, or manuscripts
>>   containing the data must acknowledge explicitly the
>>   owner of the data.
>>
>>   * Licensed downloaded data files must be erased
>>   upon the completion of my research project, course
>>   assignment, or thesis work.
>>
>>   * Use of the data may be subject to audit by the data
>>   producer; so that in the event of audits, my use of
>>   the data may be disclosed to the producer.
>>
>>   Data covered by this agreement:
>>
>>   Data listed below is stored on the Library GIS network
>>   and is available only to Carleton University students,
>>   faculty and staff upon presentation of current
>>   university identification.
>>
>>   Licenced data include files from agencies of the
>>   Government of Canada, the Government of Ontario,
>>   the Government of Quebec, cities of Ottawa, Hamilton,
>>   London and Niagara, commercial providers such as DMTI,
>>   Teranet, and Landlnfo, and any other data providers
>>   which require authenticated access. A full list of
>>   data providers is available on the GIS website.
>>
>> I would say that this unequivocally prevents the data being used as an
>> OSM source. Again, I ask you to refrain from using it until the licence
>> is clarified by the Carleton library.
>>
>> Best Wishes,
>>  Stewart
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

Will do. If it needs to be reverted, I will do so.

On Dec 22, 2016 8:11 PM, "Stewart C. Russell"  wrote:

> On 2016-12-22 07:47 PM, James wrote:
> > From what was told to me at the school,  Stewart, you are allowed to
> > create derivative work/tracing, but not distribute the imagery.
>
> You may be able to create derivative work, but solely for teaching or
> academic purposes. The most recent Carleton University Data Use
> Agreement I can find
> ( DataUseAgreement.pdf>)
> says:
>
>   I am affiliated with Carleton University as a current
>   faculty member, student or staff member and I agree to
>   abide by the terms of the University’s contractual
>   obligations to the owner of the data. Data obtained
>   by this agreement is protected by copyright and remain
>   the property of the data producer. I understand that:
>
>   * The data provided to me is for the exclusive purposes
>   of teaching or academic research while I am a member
>   of the Carleton University community and may not be
>   used for any other purposes without the explicit prior
>   written approval of the owner of the data.
>
>   * I am prohibited from using these data products in
>   the pursuit of any commercial or income-generating
>   venture either privately, with government, or under
>   the auspices of Carleton University.
>
>   * The data is released to me as a working copy for my
>   use only. The distribution, sale, donation, transfer,
>   sharing or exchange of any portion of these data in
>   any way is expressly prohibited.
>
>   * The data is accepted ”as is”, and that the
>   owner makes no representations or warranties, either
>   expressed or implied, as to the appropriateness and
>   fitness for a particular purpose.
>
>   * All publications, paper printouts, or manuscripts
>   containing the data must acknowledge explicitly the
>   owner of the data.
>
>   * Licensed downloaded data files must be erased
>   upon the completion of my research project, course
>   assignment, or thesis work.
>
>   * Use of the data may be subject to audit by the data
>   producer; so that in the event of audits, my use of
>   the data may be disclosed to the producer.
>
>   Data covered by this agreement:
>
>   Data listed below is stored on the Library GIS network
>   and is available only to Carleton University students,
>   faculty and staff upon presentation of current
>   university identification.
>
>   Licenced data include files from agencies of the
>   Government of Canada, the Government of Ontario,
>   the Government of Quebec, cities of Ottawa, Hamilton,
>   London and Niagara, commercial providers such as DMTI,
>   Teranet, and Landlnfo, and any other data providers
>   which require authenticated access. A full list of
>   data providers is available on the GIS website.
>
> I would say that this unequivocally prevents the data being used as an
> OSM source. Again, I ask you to refrain from using it until the licence
> is clarified by the Carleton library.
>
> Best Wishes,
>  Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

2016-12-22 Thread Stewart C. Russell

On 2016-12-22 07:47 PM, James wrote:
> From what was told to me at the school,  Stewart, you are allowed to
> create derivative work/tracing, but not distribute the imagery.

You may be able to create derivative work, but solely for teaching or
academic purposes. The most recent Carleton University Data Use
Agreement I can find
()
says:

  I am affiliated with Carleton University as a current
  faculty member, student or staff member and I agree to
  abide by the terms of the University’s contractual
  obligations to the owner of the data. Data obtained
  by this agreement is protected by copyright and remain
  the property of the data producer. I understand that:

  * The data provided to me is for the exclusive purposes
  of teaching or academic research while I am a member
  of the Carleton University community and may not be
  used for any other purposes without the explicit prior
  written approval of the owner of the data.

  * I am prohibited from using these data products in
  the pursuit of any commercial or income-generating
  venture either privately, with government, or under
  the auspices of Carleton University.

  * The data is released to me as a working copy for my
  use only. The distribution, sale, donation, transfer,
  sharing or exchange of any portion of these data in
  any way is expressly prohibited.

  * The data is accepted ”as is”, and that the
  owner makes no representations or warranties, either
  expressed or implied, as to the appropriateness and
  fitness for a particular purpose.

  * All publications, paper printouts, or manuscripts
  containing the data must acknowledge explicitly the
  owner of the data.

  * Licensed downloaded data files must be erased
  upon the completion of my research project, course
  assignment, or thesis work.

  * Use of the data may be subject to audit by the data
  producer; so that in the event of audits, my use of
  the data may be disclosed to the producer.

  Data covered by this agreement:

  Data listed below is stored on the Library GIS network
  and is available only to Carleton University students,
  faculty and staff upon presentation of current
  university identification.

  Licenced data include files from agencies of the
  Government of Canada, the Government of Ontario,
  the Government of Quebec, cities of Ottawa, Hamilton,
  London and Niagara, commercial providers such as DMTI,
  Teranet, and Landlnfo, and any other data providers
  which require authenticated access. A full list of
  data providers is available on the GIS website.

I would say that this unequivocally prevents the data being used as an
OSM source. Again, I ask you to refrain from using it until the licence
is clarified by the Carleton library.

Best Wishes,
 Stewart

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

Re: [Talk-ca] Community Conduct

>From what was told to me at the school,  Stewart, you are allowed to create
derivative work/tracing, but not distribute the imagery.

On Dec 22, 2016 7:29 PM, "Stewart C. Russell"  wrote:

> On 2016-12-22 02:43 PM, Frederik Ramm wrote:
> >
> > http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947
> > …
> > But maybe I'm overreacting and I'm prepared to let the matter rest if
> > the Canadian community finds that normal.
>
> I don't find that normal, and I'm sorry you had to deal with it. OSM
> must be a welcoming and cooperative community, and some of the comments
> in that exchange were out of line. OSM is not a race to see who can add
> the most data.
>
> I have approached the GIS at Carleton team to ask about the licence for
> their air photos. I can neither access their images as a slippy map nor
> find a data licence text. The statement that “City of Ottawa Air Photos
> are available for direct download for Carleton University students,
> faculty and staff ONLY” (emphasis theirs) makes me concerned that the
> data is under a restricted academic licence.
>
> Until Carleton can confirm that the data is good to use, I'd like to
> request that Jamie and any others refrain from using it as a data
> source. It's like the Ottawa building import: the OSM community can't
> use data until its source and licence is verifiable by everyone.
>
> cheers,
>  Stewart
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

2016-12-22 Thread Stewart C. Russell

On 2016-12-22 02:43 PM, Frederik Ramm wrote:
> 
> http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947
> …
> But maybe I'm overreacting and I'm prepared to let the matter rest if
> the Canadian community finds that normal.

I don't find that normal, and I'm sorry you had to deal with it. OSM
must be a welcoming and cooperative community, and some of the comments
in that exchange were out of line. OSM is not a race to see who can add
the most data.

I have approached the GIS at Carleton team to ask about the licence for
their air photos. I can neither access their images as a slippy map nor
find a data licence text. The statement that “City of Ottawa Air Photos
are available for direct download for Carleton University students,
faculty and staff ONLY” (emphasis theirs) makes me concerned that the
data is under a restricted academic licence.

Until Carleton can confirm that the data is good to use, I'd like to
request that Jamie and any others refrain from using it as a data
source. It's like the Ottawa building import: the OSM community can't
use data until its source and licence is verifiable by everyone.

cheers,
 Stewart

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

Re: [Talk-ca] Community Conduct

2016-12-22 Thread Begin Daniel

Thank John

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Thursday, 22 December, 2016 19:00
To: James
Cc: Paul Norman; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Community Conduct

> no one maps Gatineau(seriously, maybe cause it's the French side?)
Tact my son tact, look the word up in the dictionary or you'll have Pierre 
descending on Ottawa demanding double Lattes.
Cheerio John

On 22 December 2016 at 18:40, James 
> wrote:
Paul, I am aware of conflicts may occur, but seeing as no one maps 
Gatineau(seriously, maybe cause it's the French side?) I'm not that scared to 
go on a mapping session all day long. In Toronto or Ottawa is a different 
story, in which I would commit more often.

On Thu, Dec 22, 2016 at 6:35 PM, Paul Norman 
> wrote:
On 12/22/2016 3:21 PM, James wrote:

As pnorman has said in the past( 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html):

 Uploaded in small enough parts that the changesets make sense. This means 
never uploading more than 50k objects at once, and typically fewer than 10k.

I try to keep my changes under 10k, but with buildings, nodes multiply quickly 
as there are minimum 4 per building(rare usually average 6-10 depending on 
complexity)

The numbers quoted are in the context of an import where the concerns are the 
ability to revert, working with the changeset in other tools, not leaving stray 
nodes in the database, not splitting one upload over multiple changesets, and 
not having a broken upload. I wouldn't recommend exceeding them for any work, 
but a non-import is out of the scope of the CanVec post linked.

Personally, I'd get worried about conflicts, lost work, and want to upload well 
before 1k changes, let alone 10k. Those often aren't a problem with an import, 
or if they are they can be easier to solve, but with normal mapping solving 
them often requires more thought.

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

--
外に遊びに行こう！

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

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

Re: [Talk-ca] Community Conduct

I didnt mean it that way, I ment compared to Montreal, Toronto and
OttawaGatineau is a commit wasteland

On Dec 22, 2016 7:00 PM, "john whelan"  wrote:

> > no one maps Gatineau(seriously, maybe cause it's the French side?)
>
> Tact my son tact, look the word up in the dictionary or you'll have Pierre
> descending on Ottawa demanding double Lattes.
>
> Cheerio John
>
> On 22 December 2016 at 18:40, James  wrote:
>
>> Paul, I am aware of conflicts may occur, but seeing as no one maps
>> Gatineau(seriously, maybe cause it's the French side?) I'm not that scared
>> to go on a mapping session all day long. In Toronto or Ottawa is a
>> different story, in which I would commit more often.
>>
>> On Thu, Dec 22, 2016 at 6:35 PM, Paul Norman  wrote:
>>
>>> On 12/22/2016 3:21 PM, James wrote:
>>>
>>> As pnorman has said in the past( https://lists.openstreetmap.or
>>> g/pipermail/talk-ca/2016-September/007260.html):
>>>
>>> * Uploaded in small enough parts that the changesets make sense. This
>>> means never uploading more than 50k objects at once, and typically fewer
>>> than 10k.*
>>>
>>>
>>> I try to keep my changes under 10k, but with buildings, nodes multiply
>>> quickly as there are minimum 4 per building(rare usually average 6-10
>>> depending on complexity)
>>>
>>>
>>> The numbers quoted are in the context of an *import *where the concerns
>>> are the ability to revert, working with the changeset in other tools, not
>>> leaving stray nodes in the database, not splitting one upload over multiple
>>> changesets, and not having a broken upload. I wouldn't recommend exceeding
>>> them for any work, but a non-import is out of the scope of the CanVec post
>>> linked.
>>>
>>> Personally, I'd get worried about conflicts, lost work, and want to
>>> upload well before 1k changes, let alone 10k. Those often aren't a problem
>>> with an import, or if they are they can be easier to solve, but with normal
>>> mapping solving them often requires more thought.
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

> no one maps Gatineau(seriously, maybe cause it's the French side?)

Tact my son tact, look the word up in the dictionary or you'll have Pierre
descending on Ottawa demanding double Lattes.

Cheerio John

On 22 December 2016 at 18:40, James  wrote:

> Paul, I am aware of conflicts may occur, but seeing as no one maps
> Gatineau(seriously, maybe cause it's the French side?) I'm not that scared
> to go on a mapping session all day long. In Toronto or Ottawa is a
> different story, in which I would commit more often.
>
> On Thu, Dec 22, 2016 at 6:35 PM, Paul Norman  wrote:
>
>> On 12/22/2016 3:21 PM, James wrote:
>>
>> As pnorman has said in the past( https://lists.openstreetmap.or
>> g/pipermail/talk-ca/2016-September/007260.html):
>>
>> * Uploaded in small enough parts that the changesets make sense. This
>> means never uploading more than 50k objects at once, and typically fewer
>> than 10k.*
>>
>>
>> I try to keep my changes under 10k, but with buildings, nodes multiply
>> quickly as there are minimum 4 per building(rare usually average 6-10
>> depending on complexity)
>>
>>
>> The numbers quoted are in the context of an *import *where the concerns
>> are the ability to revert, working with the changeset in other tools, not
>> leaving stray nodes in the database, not splitting one upload over multiple
>> changesets, and not having a broken upload. I wouldn't recommend exceeding
>> them for any work, but a non-import is out of the scope of the CanVec post
>> linked.
>>
>> Personally, I'd get worried about conflicts, lost work, and want to
>> upload well before 1k changes, let alone 10k. Those often aren't a problem
>> with an import, or if they are they can be easier to solve, but with normal
>> mapping solving them often requires more thought.
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
>
> --
> 外に遊びに行こう！
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

If you want me to commit in even smaller chunks I don't mind, I just hate
wasting "commit numbers" (see int64 limit, in which osm will have to change
their commit id schema or support int128)
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

Paul, I am aware of conflicts may occur, but seeing as no one maps
Gatineau(seriously, maybe cause it's the French side?) I'm not that scared
to go on a mapping session all day long. In Toronto or Ottawa is a
different story, in which I would commit more often.

On Thu, Dec 22, 2016 at 6:35 PM, Paul Norman  wrote:

> On 12/22/2016 3:21 PM, James wrote:
>
> As pnorman has said in the past( https://lists.openstreetmap.
> org/pipermail/talk-ca/2016-September/007260.html):
>
> * Uploaded in small enough parts that the changesets make sense. This
> means never uploading more than 50k objects at once, and typically fewer
> than 10k.*
>
>
> I try to keep my changes under 10k, but with buildings, nodes multiply
> quickly as there are minimum 4 per building(rare usually average 6-10
> depending on complexity)
>
>
> The numbers quoted are in the context of an *import *where the concerns
> are the ability to revert, working with the changeset in other tools, not
> leaving stray nodes in the database, not splitting one upload over multiple
> changesets, and not having a broken upload. I wouldn't recommend exceeding
> them for any work, but a non-import is out of the scope of the CanVec post
> linked.
>
> Personally, I'd get worried about conflicts, lost work, and want to upload
> well before 1k changes, let alone 10k. Those often aren't a problem with an
> import, or if they are they can be easier to solve, but with normal mapping
> solving them often requires more thought.
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Community Conduct

2016-12-22 Thread Paul Norman


On 12/22/2016 3:21 PM, James wrote:
As pnorman has said in the past( 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html):


/ Uploaded in small enough parts that the changesets make sense. This 
means never uploading more than 50k objects at once, and typically 
fewer than 10k./



I try to keep my changes under 10k, but with buildings, nodes multiply 
quickly as there are minimum 4 per building(rare usually average 6-10 
depending on complexity)


The numbers quoted are in the context of an *import *where the concerns 
are the ability to revert, working with the changeset in other tools, 
not leaving stray nodes in the database, not splitting one upload over 
multiple changesets, and not having a broken upload. I wouldn't 
recommend exceeding them for any work, but a non-import is out of the 
scope of the CanVec post linked.


Personally, I'd get worried about conflicts, lost work, and want to 
upload well before 1k changes, let alone 10k. Those often aren't a 
problem with an import, or if they are they can be easier to solve, but 
with normal mapping solving them often requires more thought.


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

Re: [talk-au] Local Government Areas without Councils

2016-12-22 Thread Warin

Lets have a while to think about it... no hurry?

My initial though is that it should be a broader description ..

"Border of a local government
or an authority
performing the functions of a local government
(e.g. Cobar Shire
, Municipality of
Strathfield
, North
Sydney Council ,
Unincorporated Far West
, ) "???

The examples are NSW only ... and should be expanded to other parts. But
is does include Shire, Municipality and Council examples.

It is a bit verbose.

On 23-Dec-16 09:50 AM, cleary wrote:

Thank you for the feedback about this issue.

I understand that Andrew would prefer non-council LGAs be negatively
mapped (i.e they constitute areas within a state that are not mapped
as council LGAs) but I didn't perceive that to be the view of other
respondents. It would also mean that the names of these areas would
not appear on the map, defeating one of the purposes of a map.

I suggest a simple one-word change in the wiki so that Level 6
administrative boundaries in Australia would read "Local Government
Area Border (e.g Shire/Council)" replacing "Local Government Authority
Border (e.g Shire/Council)" clarifying that we map the area rather
than the form of administration in the area.

I looked at the possibility of separating the areas into LGAs
administered by councils, LGAs administered by other bodies, and LGAs
without a single administering authority and mapping them with
different admin_levels but it seems a very clumsy solution.

I also looked again at the model for States and Territories. In that
category we have three different categories (1) States administered by
governments with powers independent of the Commonwealth, Territories
with governments with limited powers and ultimately subject to
Commonwealth control, and the Jervis Bay Territory which has no single
administering authority. All are mapped as admin_level=4 which I
think is appropriate. If we think an LGA should not be mapped because
it does not have an administering authority, would we also delete the
Jervis Bay Territory for the same reason? I would hope not.

Which brings me back to the simplest solution, changing the term
"Local Government Authority" to "Local Government Area" in the wiki.

Is this suggestion generally acceptable or could someone else suggest
a more acceptable solution to the question?

On Thu, Dec 22, 2016, at 08:48 AM, Warin wrote:

On 21-Dec-16 05:10 PM, Warin wrote:

Hummm
How about looking at it from a data consumers view point?
Who would use boundary level 6 and what for?

A resident/occupier/potential purchaser/developer may want to know
who is the relevant authority for a particular property ...
A new employee many want confirmation of the boundaries of the
authority they are working for.

I suppose you could ask a real estate agent (joke) or look in OSM ...
If you are in one of these 'unincorporated areas' then with
Andrew's' 'rule' you won't get an answer.. not much help.

I would think that the 'rule' is easily expanded to include
unincorporated areas.
What is/are the objection/s to this expansion? Other than 'it is
not in the wiki'.

On 21-Dec-16 11:35 AM, Andrew Davidson wrote:

It's pretty simple:

1. Admin level 6 boundaries are supposed to enclose a "Local
Government Authority".

2. In NSW the only form of "Local Government Authority" are
councils incorporated under the Local Government Act.

3. The areas covered by these councils are "incorporated areas".

4. The three polygons in the LPI dataset labelled "UNINCORPORATED"
represent areas that are not in the "incorporated areas" and
therefore have no "Local Government Authority".

5. You don't put boundaries around things that don't exist.

Unincorporated areas exit.
They form a similar role to 'Local Councils'.
The areas do not overlap, in fact sharing the same ways/part
boundaries.

There would be no data conflict in adding these to boundary level 6.

Looking
athttp://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries

the United kingdom for level 6 boundary has "administrative counties
/ Unitary authorities
, City of London"

And the wiki on Unitary authorities
says in part "type
of local authority that has a single tier and is responsible for all
local government
functions within its area"

QED.

The SA case is complicated by the existence of the Outback
Communities Authority. According to the

Re: [Talk-ca] Community Conduct

Especially with building tools(quick rectangles, predefined tags) and the
extruder tool(create areas : x as shortcut) it litterally takes me less
than 2 seconds to map a building, then it's on to the next one beside it.
More complexe ones(with arcs) may take me longer, but I still average a lot
faster than anything I could do in ID or manually(how I was doing it
before) with the line tool. It's not hard to map buildings, it's wether you
have the drive and determination to do such a mundane task or not.
Sometimes I get so focused a couple hours have passed, and then I decide to
commit. For me (goes with git commits aswell) I commit once or twice a day
or when a job is done and not go commit crazy (once every 10-20minutes).

As pnorman has said in the past(
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html
):

* Uploaded in small enough parts that the changesets make sense. This means
never uploading more than 50k objects at once, and typically fewer than
10k.*

I try to keep my changes under 10k, but with buildings, nodes multiply
quickly as there are minimum 4 per building(rare usually average 6-10
depending on complexity)

> On Thu, Dec 22, 2016 at 6:09 PM, James  wrote:
>
>> As Devonf has pointed out, if you want to see the carletonuniversity(cant
>> download I'm sorry) you can visit http://maps.ottawa.ca/geoottawa/ and
>> view the "2014" aerial ortho, which seems to be the same. I'm not trying to
>> hide anything, the fact that it's not available for download is out of my
>> control
>>
>> On Dec 22, 2016 4:30 PM, "Michael Reichert"  wrote:
>>
>>> Hi James,
>>>
>>> Am 22.12.2016 um 21:23 schrieb James:
>>> > And suddenly the osmcha disapproval from Nakaner(Michael has
>>> > disapearedI know he's on this list as he does popup from time to
>>> time
>>> > on this listvery suspicious indeed.
>>>
>>> Based on the information given in the changeset tags I concluded at the
>>> time I added the -1 flag that it is an import. If you trace buildings
>>> the number of added nodes per changeset might reach 1000. But in this
>>> changeset 8008 nodes were added. I was impossible to prove that Bing or
>>> Mapbox imagery was used.
>>>
>>> In the meanwhile you stated that you used other data sources for
>>> tracing. That's why I removed the flag.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>>
>>> --
>>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>>> ausgenommen)
>>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>

-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [talk-au] Local Government Areas without Councils

2016-12-22 Thread nwastra

Your suggestion of …
'the simplest solution, changing the term "Local Government Authority" to 
"Local Government Area" in the wiki. is acceptable’ 
is a good solution for me as all these areas need to appear on the map.
nevw 

> On 23 Dec 2016, at 8:50 AM, cleary  wrote:
> 
> 
> 
> Thank you for the feedback about this issue.
> 
> I understand that Andrew would prefer non-council LGAs be negatively mapped 
> (i.e they constitute areas within a state that are not mapped as council 
> LGAs) but I didn't perceive that to be the view of other respondents. It 
> would also mean that the names of these areas would not appear on the map, 
> defeating one of the purposes of a map.
> 
> I suggest a simple one-word change in the wiki so that Level 6 administrative 
> boundaries in Australia would read "Local Government Area Border (e.g 
> Shire/Council)" replacing "Local Government Authority Border (e.g 
> Shire/Council)" clarifying that we map the area rather than the form of 
> administration in the area.
> 
> I looked at the possibility of separating the areas into LGAs administered by 
> councils, LGAs administered by other bodies, and LGAs without a single 
> administering authority and mapping them with different admin_levels but it 
> seems a very clumsy solution.
> 
> I also looked again at the model for States and Territories. In that category 
> we have three different categories (1) States administered by governments 
> with powers independent of the Commonwealth, Territories with governments 
> with limited powers and ultimately subject to Commonwealth control, and the 
> Jervis Bay Territory which has no single administering authority.  All are 
> mapped as admin_level=4 which I think is appropriate.  If we think an LGA 
> should not be mapped because it does not have an administering authority, 
> would we also delete the Jervis Bay Territory for the same reason? I would 
> hope not.
> 
> Which brings me back to the simplest solution, changing the term "Local 
> Government Authority" to "Local Government Area" in the wiki.
> 
> Is this suggestion generally acceptable or could someone else suggest a more 
> acceptable solution to the question?
> 
> 
> 
> 
> On Thu, Dec 22, 2016, at 08:48 AM, Warin wrote:
>> On 21-Dec-16 05:10 PM, Warin wrote:
>>> Hummm 
>>> How about looking at it from a data consumers view point? 
>>> Who would use boundary level 6  and what for? 
>>> 
>>> A resident/occupier/potential purchaser/developer may want to know who is 
>>> the relevant authority for a particular property ... 
>>> A new employee many want confirmation of the boundaries of the authority 
>>> they are working for. 
>>>  I suppose you could ask a real estate agent (joke) or look in OSM ... 
>>> If you are in one of these 'unincorporated areas' then with Andrew's' 
>>> 'rule' you won't get an answer.. not much help. 
>>> 
>>> I would think that the 'rule' is easily expanded to include unincorporated 
>>> areas. 
>>> What is/are  the objection/s to this expansion? Other than 'it is not in 
>>> the wiki'. 
>>> 
>>>  On 21-Dec-16 11:35 AM, Andrew Davidson wrote: 
>>> 
 It's pretty simple: 
 
 1. Admin level 6 boundaries are supposed to enclose a "Local Government 
 Authority". 
 
 2. In NSW the only form of "Local Government Authority" are councils 
 incorporated under the Local Government Act. 
 
 3. The areas covered by these councils are "incorporated areas". 
 
 4. The three polygons in the LPI dataset labelled "UNINCORPORATED" 
 represent areas that are not in the "incorporated areas" and therefore 
 have no "Local Government Authority". 
 
 5. You don't put boundaries around things that don't exist. 
>>> 
>>> Unincorporated areas exit.
>>> They form a similar role to 'Local Councils'. 
>>> The areas do not overlap, in fact sharing the same ways/part boundaries. 
>>> There would be no data conflict in adding these to boundary level 6. 
>>> 
>> 
>> Looking 
>> athttp://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
>>  
>> 
>>  
>> the United kingdom for level 6 boundary has "administrative counties / 
>> Unitary authorities , City 
>> of London" 
>> 
>> And the wiki on Unitary authorities 
>>  says in part "type of local 
>> authority that has a single tier and is responsible for all local government 
>>  functions within its area" 
>> 
>> 
>> 
>> 
>>> 
 
 QED.
 
 The SA case is complicated by the existence of the Outback Communities 
 Authority. According to the Office of Local Government it's not included: 
 
 http://www.dpti.sa.gov.au/local_govt 
 .

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

On 22-12-16 23:18, Marc Gemis wrote:
> On Thu, Dec 22, 2016 at 10:54 PM, Glenn Plas  wrote:
>> Sometimes it's better to actually get a changeset dropped instead of
>> using the plugin.
> 
> I believe this can only done by the DWG and is only used in case of
> data that violates a license or for sensistive data. Never for
> vandalism or other mistakes.

Correct, you need to contact DWG for such cases.   And I believe Ben
Abelshausen is the DWG's primary contact, so passing this by him is
probably a good idea as well.

> 
> Furthermore the data is not deleted from any dataset that was taken
> from the main server before the "purge" is done. Not everybody
> realizes this (although I know Glenn does)

Like -every- preceding mapping mistake :)   Probably won't be an issue
for most consumers.

Glenn


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

Re: [Talk-ca] Community Conduct

Well I do have a logitech g9 gaming mouse, that is pretty awesome for
mapping and gamingbut I doubt that's the issue here.

On Dec 22, 2016 5:55 PM, "john whelan"  wrote:

Ask him to show you his gaming mouse with the Hyperglide teflon engineered
mouse skates.

Cheerio John

On 22 December 2016 at 16:28, Michael Reichert  wrote:

> Hi James,
>
> Am 22.12.2016 um 21:23 schrieb James:
> > And suddenly the osmcha disapproval from Nakaner(Michael has
> > disapearedI know he's on this list as he does popup from time to time
> > on this listvery suspicious indeed.
>
> Based on the information given in the changeset tags I concluded at the
> time I added the -1 flag that it is an import. If you trace buildings
> the number of added nodes per changeset might reach 1000. But in this
> changeset 8008 nodes were added. I was impossible to prove that Bing or
> Mapbox imagery was used.
>
> In the meanwhile you stated that you used other data sources for
> tracing. That's why I removed the flag.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>

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

Re: [Talk-ca] Community Conduct

Ask him to show you his gaming mouse with the Hyperglide teflon engineered
mouse skates.

Cheerio John

On 22 December 2016 at 16:28, Michael Reichert  wrote:

> Hi James,
>
> Am 22.12.2016 um 21:23 schrieb James:
> > And suddenly the osmcha disapproval from Nakaner(Michael has
> > disapearedI know he's on this list as he does popup from time to time
> > on this listvery suspicious indeed.
>
> Based on the information given in the changeset tags I concluded at the
> time I added the -1 flag that it is an import. If you trace buildings
> the number of added nodes per changeset might reach 1000. But in this
> changeset 8008 nodes were added. I was impossible to prove that Bing or
> Mapbox imagery was used.
>
> In the meanwhile you stated that you used other data sources for
> tracing. That's why I removed the flag.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [talk-au] Local Government Areas without Councils

2016-12-22 Thread cleary

Thank you for the feedback about this issue.

I understand that Andrew would prefer non-council LGAs be negatively
mapped (i.e they constitute areas within a state that are not mapped as
council LGAs) but I didn't perceive that to be the view of other
respondents. It would also mean that the names of these areas would not
appear on the map, defeating one of the purposes of a map.

I suggest a simple one-word change in the wiki so that Level 6
administrative boundaries in Australia would read "Local Government Area
Border (e.g Shire/Council)" replacing "Local Government Authority Border
(e.g Shire/Council)" clarifying that we map the area rather than the
form of administration in the area.

I looked at the possibility of separating the areas into LGAs
administered by councils, LGAs administered by other bodies, and LGAs
without a single administering authority and mapping them with different
admin_levels but it seems a very clumsy solution.

I also looked again at the model for States and Territories. In that
category we have three different categories (1) States administered by
governments with powers independent of the Commonwealth, Territories
with governments with limited powers and ultimately subject to
Commonwealth control, and the Jervis Bay Territory which has no single
administering authority.  All are mapped as admin_level=4 which I think
is appropriate.  If we think an LGA should not be mapped because it does
not have an administering authority, would we also delete the Jervis Bay
Territory for the same reason? I would hope not.

Which brings me back to the simplest solution, changing the term "Local
Government Authority" to "Local Government Area" in the wiki.

Is this suggestion generally acceptable or could someone else suggest a
more acceptable solution to the question?

On Thu, Dec 22, 2016, at 08:48 AM, Warin wrote:

> On 21-Dec-16 05:10 PM, Warin wrote:

>> Hummm 

>>  How about looking at it from a data consumers view point? 

>>  Who would use boundary level 6  and what for? 

>> 

>>  A resident/occupier/potential purchaser/developer may want to know
>>  who is the relevant authority for a particular property ...
>>  A new employee many want confirmation of the boundaries of the
>>  authority they are working for.
>>   I suppose you could ask a real estate agent (joke) or look in
>>   OSM ...
>>  If you are in one of these 'unincorporated areas' then with
>>  Andrew's' 'rule' you won't get an answer.. not much help.
>> 

>>  I would think that the 'rule' is easily expanded to include
>>  unincorporated areas.
>>  What is/are  the objection/s to this expansion? Other than 'it is
>>  not in the wiki'.
>> 

>>   On 21-Dec-16 11:35 AM, Andrew Davidson wrote: 

>> 

>>> It's pretty simple: 

>>> 

>>>  1. Admin level 6 boundaries are supposed to enclose a "Local
>>> Government Authority".
>>> 

>>>  2. In NSW the only form of "Local Government Authority" are
>>> councils incorporated under the Local Government Act.
>>> 

>>>  3. The areas covered by these councils are "incorporated areas". 

>>> 

>>>  4. The three polygons in the LPI dataset labelled "UNINCORPORATED"
>>> represent areas that are not in the "incorporated areas" and
>>> therefore have no "Local Government Authority".
>>> 

>>>  5. You don't put boundaries around things that don't exist. 

>> 

>> Unincorporated areas exit.

>>  They form a similar role to 'Local Councils'. 

>>  The areas do not overlap, in fact sharing the same ways/part
>>  boundaries.
>>  There would be no data conflict in adding these to boundary level 6.
>> 

> 

> Looking at
> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
>  the United kingdom for level 6 boundary has "administrative counties
>  / Unitary authorities[1], City of London"
> 

>  And the wiki on Unitary authorities[2] says in part "type of local
>  authority that has a single tier and is responsible for all local
>  government[3] functions within its area"
> 

> 

> 

> 

>> 

>>> 

>>> QED.

>>> 

>>>  The SA case is complicated by the existence of the Outback
>>>  Communities Authority. According to the Office of Local Government
>>>  it's not included:
>>> 

>>> http://www.dpti.sa.gov.au/local_govt. 

>>> 

>>>  Which is supported by the fact that the name includes the phrase
>>>  "unincorporated area".
>>> 

>>>  On 2016-12-21 09:15, cleary wrote: 

>>> 

 I have been adding administrative boundaries in NSW and SA
 using the
  Government data for which OSM has been given explicit permission.
  I am
  currently working on the "Pastoral Unincorporated Area" in SA and
  another mapper commented that it was inappropriate. I responded
  but my
  response appears not to have satisfied the other mapper.  I then
  found
  that the same mapper had deleted the "Unincorporated Area of New
  South
  Wales" because it was not administered by a

Re: [OSM-talk-fr] fiber=yes ?

2016-12-22 Thread Laurent Choisie

Bonsoir à tous,

Travaillant dans le métier des télécoms et en particulier dans celui des
déploiements de fibre optique, je me permets d'apporter quelques éléments
au débat.
Tout d'abord, mes réserves :
- je ne rentre pas dans le débat des réseaux HFC ou autre FttLA. Je ne
parle que de réseau FttH.
- je ne rentre pas non plus dans la question de comment tagguer tout ça
sous OSM. Je laisse ça aux spécialistes, mais oui il faudrait pouvoir
préciser "medium=fiber".

Ce que je veux vous dire c'est :
1. "Le Plan"
La France vit actuellement un déploiement massif de fibre optique, ayant
pour but de couvrir 100% des foyers d'ici 2022. Il s'agit du Plan France
Thrès Haut Débit http://www.francethd.fr/. Saluons l'initiative et ne nous
attardons pas sur les probables retards à terme.
Il s'agit de remplacer à terme le réseau Cuivre d'Orange.
On peut comparer ce déploiement à celui du réseau d'électricité, ou à celui
du réseau de téléphonie Cuivre de France Telecom à l'époque.

2. Les bonnes vielles recettes, et comment on s'est découpé le gâteau
Le territoire français a été découpé en plusieurs zones en fonction de leur
rentabilité :
- ZTD (Zone Très Dense) = une 100aine de communes (arrondissements de
Paris, Lyon, Strasbourg ...) représentant ~5 millions de foyers, pour
laquelle chaque opérateur peut déployer tout le réseau qu'il souhaite.
C'est rentable donc chacun peut déployer à sa guise. En gros c'est la libre
concurrence.
- Zone d'initiative privé = 3 600 communes dites "conventionnées" soit 57%
de la population et représentant un investissement de 6 à 7 milliards
d'euros. Ce sont les agglos, les préfectures, les sous-préf. Là 1 seul
opérateur privé investit (Orange ou SFR). Mais il a la garantie qu'il n'y
aura pas de concurrence sur les infras. Donc celui qui déploie la fibre
devra la commercialiser à tous de façon équitable, contrôlé par l'ARCEP.
- Zone RIP (Réseau d'Initiative Publique) = tout le reste du territoire,
soit plus de 30 000 communes mais représentant un investissement de 13 à 14
milliards. C'est du rural. Dans ce cas, pas de rentabilité. Donc l'Etat et
les Collectivités Locales co-investissent avec des acteurs privés. C'est le
principe des DSP (Délégation de Service Public), une bonne vieille recette
qui fonctionne pour l'eau, les transports en commun etc ...

3. Les infrastructures
D'un point de vue architecture, les points intéressants à cartographier,
selon moi, sont (en partant des GIX nationaux vers les client final) :
- les POP (PointOfPresence), les points d'échanges entre opérateurs,
souvent équivalents à des datacenters dans les grandes villes,
- les NRO (Noeud de Raccordement Optique), généralement un shelter ou un
petit local ou co-localisé dans un NRA d'Orange, dans lequel on va activer
= allumer la fibre optique. Dans le NRO, on trouve l'équipement OLT
équivalent du DSLAM en adsl.
- les SRO (Sous-Répartiteur Optique), ou PM (Point de Mutualisation), ou
armoire de brassage. C'est dans ces armoires qu'arrive chacune des fibres
des abonnés pour ensuite les brasser càd les renvoyer vers le NRO de
l'opérateur. Un bon moyen pour les distinguer est la présence d'un picto
"danger optique"
https://aua-signaletique.com/panneaux-iso-7010/4696-danger-rayonnement-optique-w027.html
. Un SRO alimente entre 500 et 1000 foyers. Donc on en trouve 1 par petite
commune rurale ou 1 par quartier résidentiel d'une ville.

4. Les adresses ...
Quand on commence l'étude d'une commune à déployer en fibre optique, le
premier problème est de savoir où sont les gens !
Le cadastre a une base, les impôts ont une base, les exploitants de réseaux
(ErDF, GrDF, Orange) ont chacun leur base, LaPoste a sa base, l'Insee a sa
base, l'IGN a sa base, OSM a la BANO mais personne n'a la vérité ... Donc
on paye des sous-traitants pour aller faire des relevés de
boîtes-aux-lettres. En 2016 ! ...A chaque fois que j'en parle, le sujet me
désespère. Bref.
Heureusement, la BAN est en cours de conception. Mais pas facile de
satisfaire tout le monde. Christian Quest saura mieux vous en parler.

J'ai essayé de faire court et espère avoir intéressé quelques-uns d'entre
vous.
Pour ma part, je commence à cartographier les SRO dès ce soir.

Cordialement,
Laurent CHOISIE

PS : Désolé pour tous ces acronymes.


Le 22 décembre 2016 à 00:55, François Lacombe  a
écrit :

> Bonjour Jean-Yvon,
>
> Le 18 décembre 2016 à 20:49,  a écrit :
>
>> Je vais te proposer de mettre fin à ton dilemme :
>> telecom:medium:fiber=yes
>> telecom:medium:coax=yes
>>
>> Pas de soucis pour les armoires à usage multiple.
>> Et comme il y a trois et non deux cas (yes, no, absence de tag)
>>
>
> En fait le dilemme se situait entre les listes à ; :
> telecom:medium=fiber;coax et les tag "yes" : telecom:medium:fiber=yes +
> telecom:medium:coax=yes
> J'avais d'ailleurs reproché ça à une proposition d'extension du modèle des
> écoles/universités en début d'année où trop de clés avec pour seule valeur
> yes

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

On Thu, Dec 22, 2016 at 10:54 PM, Glenn Plas  wrote:
> Sometimes it's better to actually get a changeset dropped instead of
> using the plugin.

I believe this can only done by the DWG and is only used in case of
data that violates a license or for sensistive data. Never for
vandalism or other mistakes.

Furthermore the data is not deleted from any dataset that was taken
from the main server before the "purge" is done. Not everybody
realizes this (although I know Glenn does)

m.

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

Re: [Talk-cz] Trasovani RUIAN - prosim poradne

2016-12-22 Thread Jan Macura

2016-12-20 10:03 GMT+01:00 Janda Martin :

> Dobry den,
>
>   je dobre ze dochazi k trasovani RUIAN ale mohu pozadat o trasovani
> kompletni a prosim bez posunuti proti referenci.
> Jako proklad davam: "Nedvědice pod Pernštejnem"
>
> https://www.openstreetmap.org/changeset/44534509#map=15/49.4611/16.3319
>
> Stare jiz natrasovane budovy jsou bez zmeny a nektere nove z RUIAN chybi.
> Coz znamena ze se budou muset vsechna nova mesta opet zkontrolovat.
>
> Prosim muzete se pretrasovana data kontrolovat.
>

Dobrý den,

v čem vidíte tu nepořádnost? V této konkrétní sadě změn já vidím
 jen spoustu
přidaných nových staveb oproti dřívějším pár domečkům, zřejmě jen přibližně
obkresleným z leteckých snímků.

Děkuji a s pozdravem
 J. Macura
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

On 22-12-16 19:57, Marc Gemis wrote:
> Depending on the case, you can immediately revert the change (e.g.
> with the revert plugin in JOSM), 

Keep in mind this is not taking away the changeset, it's just doing the
reversal but in a forward fashion.  It's not a real revert, just a way
to nullify the changes by applying the reverse actions.

Sometimes it's better to actually get a changeset dropped instead of
using the plugin.

That being said, always start with comments to get a better idea of the
situation you're trying to solve.

Glenn

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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Jan Macura

Ahoj, díky za nastínění problému.

2016-12-21 7:20 GMT+01:00 Marián Kyral :

> Ve zkratce, při převodu křováka (souřadnicový systém užívaný v
> katastrálních mapách) na WGS84 (souřadnicový systém GPS) používá ČÚZK
> program, který přepočet nějakým algoritmem koriguje. Aktuální  algoritmus
> ovšem není známý. Takže když pak Petr stáhne data z RUIAN a přepočítá
> souřadnice do WGS84, přepočtená data na některých místech republiky nesedí
> vůči KM. Čím dále od centra, tím je to horší. Nejvzdálenější jsou Beskydy,
> takže tam je to nejhorší. Co si matně vzpomínám, bavíme se o odchylce pár
> cm až půl metru. Viz: http://freegis.fsv.cvut.cz/gwi
> ki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK (tohle je sice
> opačný směr, ale problém je snad jasný ;-) )
>

Takže problém je, že vrstva vektorové KM opticky nesedí na vstvu budov
RÚIAN?
Zkusmo jsem si v JOSM otevřel Rožnov pod Radhoštěm, Uherský Brod, Valtice a
Karvinou. Nikde jsem nenaměřil větší rozdíl, než 0,3 m. O tom se tady
bavíme? O 30 cm? V momentě, kdy 40 % k.ú. má KMD se střední souřadnicovou
chybou 1 m (což odpovídá dopustné odchylce až 2,8 m), a za předpokladu, že
celá OSM vlastně vychází z GPS měření, který i v lepších navigačncíh
přístrojích (vůbec nepočítaje GPS čipy v mobilech) má přesnost +-metrovou v
otevřeném prostoru a +-metry až desítky metrů v zákrytech, případně vychází
z družicových snímků s prostorovým rozlišením 0,7 m v tom lepším případě,
12 m v tom horším (a to nepočítaje chybu posunutí, která bývá u Bingu až
několikametrová) mi přijde řešit 30 cm jako práce pro práci. 30 cm je v
tomhle kontextu jako plivnout do moře.

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

Re: [Talk-ca] Community Conduct

As Devonf has pointed out, if you want to see the carletonuniversity(cant
download I'm sorry) you can visit http://maps.ottawa.ca/geoottawa/ and view
the "2014" aerial ortho, which seems to be the same. I'm not trying to hide
anything, the fact that it's not available for download is out of my control

On Dec 22, 2016 4:30 PM, "Michael Reichert"  wrote:

> Hi James,
>
> Am 22.12.2016 um 21:23 schrieb James:
> > And suddenly the osmcha disapproval from Nakaner(Michael has
> > disapearedI know he's on this list as he does popup from time to time
> > on this listvery suspicious indeed.
>
> Based on the information given in the changeset tags I concluded at the
> time I added the -1 flag that it is an import. If you trace buildings
> the number of added nodes per changeset might reach 1000. But in this
> changeset 8008 nodes were added. I was impossible to prove that Bing or
> Mapbox imagery was used.
>
> In the meanwhile you stated that you used other data sources for
> tracing. That's why I removed the flag.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Marián Kyral

Dne 22.12.2016 v 20:51 Ha Noj napsal(a):
> > > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
> vlastně není a všichni jsou happy.
> > *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co
> nám vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
> > No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
> nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový
> plugin a do toho momentálně nejdu. Už tak mám na seznamu plno věcí,
> které bych chtěl někdy udělat. Třeba pár vylepšení na osmap.cz
> .
> *** a nebo pro poloha.net/budovy  napsat
> skript, který pro každou budovu vloží novou geometrii z WFS a není
> třeba nic měnit na tracer pluginu.
>

To by asi v ČÚZK nebyli moc rádi. Právě proto dávají k dispozici ty
importy, aby se zbytečně nepřetěžovaly jejich servery.

Marián

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

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

[Talk-ca] Community conduct / mapping

Just a gentle comment.

We do have mappers on the ground in Ottawa/Gatineau and we do talk face to
face believe it or not and we have been known to discuss things over coffee.

We have ways of disciplining tatty mappers, they get to buy the next round
of coffee.

Our local mappers have been known to physically check the location etc of
bus stops when there was some doubt.

We have the capability to look at buildings as well.  Not just look at
imagery.

If there are questions about a particular building perhaps they can be
directed to us to confirm rather than being zapped from afar?

OSM is supposed to be community mapping can we keep it that way please.

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

Re: [Talk-ca] Community Conduct

It's too bad I document everything before.
http://imgur.com/a/yedmc

On Thu, Dec 22, 2016 at 3:23 PM, James  wrote:

> And suddenly the osmcha disapproval from Nakaner(Michael has
> disapearedI know he's on this list as he does popup from time to time
> on this listvery suspicious indeed.
>
> On Thu, Dec 22, 2016 at 3:08 PM, James  wrote:
>
>> http://osmcha.mapbox.com/44545610/
>> I can see that it was our Friend Nakaner that has reported it to you, in
>> which there was a whole shit-show (sorry for the language) with Rps333 and
>> CanVEC imports in the north. You cannot deny that you and Nakaner have a
>> history with Rps333, Denis and I. So to ask so broadly without giving
>> history into the matter is quite an oversight and might be normal for me to
>> be defensive, because of our history together.
>>
>> I've done mass adds(by hand) on my new account and have gotten 0 flak,
>> but once "LogicalViolinist" is attached to the changeset, it is flagged,
>> which I'm tired of(thus the defensive attitude).
>>
>>
>> On Thu, Dec 22, 2016 at 2:46 PM, James  wrote:
>>
>>> Frederik, your email is very opinionated, when I have just showed you
>>> (pixel based) why I drew that building like that.
>>>
>>> On Thu, Dec 22, 2016 at 2:43 PM, Frederik Ramm 
>>> wrote:
>>>
 Hi,

I've been involved in a changeset discussion that I would like to
 bring to the attention of a wider audience:

 http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947

 I don't think I'm the right person to continue that discussion but I see
 several questionable attitudes here (e.g. the "I don't need to show
 sources for what I do" attitude, the "I have more edits than you so shut
 up" attitude).

 I was initially drawn to that changeset because it was flagged as a
 potential import, adding 1000 houses over a couple of hours. I'm still
 not sure if my suspicion was correct. It should be easy enough to
 disprove but instead we're seeing statements, attacks and excuses worthy
 of an US election twitter exchange.

 But maybe I'm overreacting and I'm prepared to let the matter rest if
 the Canadian community finds that nomal.

 Bye
 Frederik

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

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

>>>
>>>
>>>
>>> --
>>> 外に遊びに行こう！
>>>
>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>
>
>
> --
> 外に遊びに行こう！
>

-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Données du STIF sur Osmose

2016-12-22 Thread Noémie Lehuby


Bonsoir,

Je vote pour le retrait des arrêts de bus d'Osmose.

J'ai ajouté à la main les références sur une ligne (une soixantaine 
d'arrêts)
J'avais pré-filtré les références opendata sur la ligne en question pour 
ne pas être polluée par les arrêts des autres transporteurs qui ne 
m'intéressaient pas dans un premier temps.
Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt 
opendata le plus proche n'était pas le bon mais celui de l'autre côté de 
la route.


Je pense que si on intègre les ref juste avec Osmose, ce n'est pas 
possible de faire ça correctement, en particulier dès qu'on a plusieurs 
transporteurs qui partagent des arrêts.



Du coup, j'ai commencé un outil (qui fait le travail de pré-filtrer les 
arrêts opendata par ligne, en se basant sur les ref opendata des lignes 
qu'on a intégrées). Je le bêta-teste après les fêtes, et je vous tiens 
au jus.


Noémie


Date: Wed, 21 Dec 2016 10:47:17 +0100
From: Frédéric Rodrigo 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Données du STIF sur Osmose
Message-ID: <1b367f08-ee38-fd91-5be6-07c7b9868...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Le 21/12/2016 à 09:58, Florian LAINEZ a écrit :

Merci Fred, Noémie pour ces outils.
Je rejoins les critiques : c'est pour l'instant un peu galère voir
trompeur.
Je comprends néanmoins qu'on ne puisse faire mieux pour l'instant ...

En ce moment j'aborde le problème de qualité avec divers acteurs du
transport et j'ai fait un petit comparatif rapide sur deux quartiers
exemple : https://www.slideshare.net/secret/yhSSpQ6mzE6SH6
Des suggestions d'amélioration ?

Y aurait-il moyen de générer des stats plus poussées ? Je cherche par
exemple l'écart moyen de la distance entre les données STIF et OSM,
les valeurs max/min, voir l'écart-type.
Fred peut-être est-ce déjà intégré à OSMOSE ? Je n'ai pas trouvé.
Oui Osmose génère en même temps des CSV, mais je ne retrouve pas 
l'URL



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

Re: [Talk-ca] Community Conduct

And suddenly the osmcha disapproval from Nakaner(Michael has
disapearedI know he's on this list as he does popup from time to time
on this listvery suspicious indeed.

On Thu, Dec 22, 2016 at 3:08 PM, James  wrote:

> http://osmcha.mapbox.com/44545610/
> I can see that it was our Friend Nakaner that has reported it to you, in
> which there was a whole shit-show (sorry for the language) with Rps333 and
> CanVEC imports in the north. You cannot deny that you and Nakaner have a
> history with Rps333, Denis and I. So to ask so broadly without giving
> history into the matter is quite an oversight and might be normal for me to
> be defensive, because of our history together.
>
> I've done mass adds(by hand) on my new account and have gotten 0 flak, but
> once "LogicalViolinist" is attached to the changeset, it is flagged, which
> I'm tired of(thus the defensive attitude).
>
>
> On Thu, Dec 22, 2016 at 2:46 PM, James  wrote:
>
>> Frederik, your email is very opinionated, when I have just showed you
>> (pixel based) why I drew that building like that.
>>
>> On Thu, Dec 22, 2016 at 2:43 PM, Frederik Ramm 
>> wrote:
>>
>>> Hi,
>>>
>>>I've been involved in a changeset discussion that I would like to
>>> bring to the attention of a wider audience:
>>>
>>> http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947
>>>
>>> I don't think I'm the right person to continue that discussion but I see
>>> several questionable attitudes here (e.g. the "I don't need to show
>>> sources for what I do" attitude, the "I have more edits than you so shut
>>> up" attitude).
>>>
>>> I was initially drawn to that changeset because it was flagged as a
>>> potential import, adding 1000 houses over a couple of hours. I'm still
>>> not sure if my suspicion was correct. It should be easy enough to
>>> disprove but instead we're seeing statements, attacks and excuses worthy
>>> of an US election twitter exchange.
>>>
>>> But maybe I'm overreacting and I'm prepared to let the matter rest if
>>> the Canadian community finds that nomal.
>>>
>>> Bye
>>> Frederik
>>>
>>> --
>>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>
>
>
> --
> 外に遊びに行こう！
>



-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] question osmose/limite administrative


Le 21/12/2016 à 01:56, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

Moi ce que j'ai compris aux lois françaises sachant que je vis très 
loin de toute les mers et océans :) c'est ça :
tu parles beaucoup des eaux intérieurs mais j'ai l'impression que ce 
terme a une définition mais dans la réalité ne sert à rien. Rien ne 
s'applique qu'aux eaux intérieurs.

C'est essentiellement exact pour les eaux intérieures au sens légal.
Je parlais surtout des eaux intérieures au sens OSM (ce qui est à 
l'intérieur du trait de côte 95 natural=coastline).


> qui le reste (dans le domaine maritime public).
ou pas. Par exemple le port de commerce de Brest a été revu pour que 
tout soit sous la même administration. Car si une zone est 
définitivement perdue pour la mer, elle finit par changer de statut.
Par contre pour osm la ligne natural=coastline pour moi c'est pas 
claire du tout où elle se trouve.
C'est bien ça mon problème, tu vois un terrien peut bien intervenir sur 
le sujet (j'interviens bien sur des poubelles à Paris ;-)).


Dans le cas "normal" elle devrait être, d’après le wiki, au niveau de 
la "mean high water spring" (j'ai pas compris ce que c’était) ce qui 
correspond (toujours d’après le wiki) à la limite des débris que l'on 
voit sur les photo aérienne sur les plages.

Ça c'est presque simple : c'est la marée haute de coefficient 95.

Et pour le cas des estuaires, il n'y a pas de règle est des fois la 
limite est au niveau d'un pont ou s'enfonce pas du tout dans les terre 
ou s'enfonce beaucoup.

Exactement. Pas de critère objectif. *C'est bien ça que j'aimerais éviter.*
Et ce n'est pas un détail : les eaux intérieures n'apparaissent pas dans 
OpenStreetMapData  qui sert pour les 
petits niveaux de zoom.
Du coup on voit le fin-fond de certains abers mais la Loire de 
Saint-Nazaire à Nantes a disparu. Pourtant des bateaux de haute mer 
remontent le fleuve.


pour les communes littorales, ce que j'ai rapidement comprit c'est que 
au niveau des estuaires il n'y a pas d’obligation que la commune qui a 
quand même l'influence de la marée mais pas l’océan à ses frontières 
soit une commune littorales.
C'est assez vaseux (sans jeu de mot) et un pont a été cédé à une commune 
pour que l'autre ne soit plus une commune littorale. C'est ça. En 
général si la commune a un lien avec la mer (non anecdotique) elle est 
littorale. Quimperlé connaît bien les marées (inondations) mais n'est 
pas une commune littorale (l'eau n'est jamais salée même si le niveau de 
la Laïta varie lors des grandes marées).


J'ai lu sur le wiki par contre que limite de pays et limite des cote 
donc boundary=administrative au niveau du bord de mer n'est pas 
obligatoirement au même endroit que natural=coastline. (mais je trouve 
que c'est plus simple et clair d'avoir qu'une seul "frontière")

Là ce serait plutôt entre commune et état.
On voit que sur le cadastre à peu près à l'endroit indiqué 
 
sur les cadastres ils passent de deux communes séparées par un fleuve à 
une seule commune.

Ça me semble être un bon endroit pour le faire.

Pour objectiver un peu la manip' je propose que l'on s'arrête là où les 
cartes marines détaillées (mieux que 1:5) s'arrêtent.
Ici les cartes 7138 et 7140 : 
http://diffusion.shom.fr/searchproduct/product/configure/id/202.

Mais j'ajouterai les rives ouest de l'Elorn (Kerhuon : carte 7400).
Pas mal en phase !
On voit que les cartes détaillées incluent les embouchures de la Laïta 
et de la ria d'Etel, mais pas l'estuaire de la Loire.


D'autres avis ?
Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] site cadastre.openstreetmap.fr

2016-12-22 Thread Laurent Combe

merci
et
parfait pour moi

si un débutant sur Toulouse se plaint de la complexité de la page vous
me l'envoyez et je le formerai :-)

Laurent


Le 22 décembre 2016 à 18:24, Tyndare  a écrit :
>
> J'ai rajouté les liens que tu mentionnent sur
> http://cadastre.openstreetmap.fr/
>
> Mais Hélène Petit m'avais fait remarquer que cette page n'est pas très
> simple pour ceux qui la découvrent pour la première fois, et à force de
> rajouter des trucs ça ne s'améliore pas.
>
> Si quelqu'un a une proposition a faire qui rendrait cette page plus claire
> (quitte à découper en plusieurs sous pages), surtout n'hésitez pas.
>
>
>
> Le 22/12/2016 à 15:32, Laurent Combe a écrit :
>>
>> A partir de ce site
>> http://cadastre.openstreetmap.fr/
>> ou de
>> http://cadastre.openstreetmap.fr/fantoir
>>
>> je ne vois pas de lien vers les listes départementales (citées
>> récemment par nicolas)
>> http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html
>>
>> àm on humble avis, ce serait un plus d'avoir à partir du site accès à
>> l'ensemble des outils disponibles (par un simple lien)
>>
>> autre point
>> sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
>> lien vers le wiki mais qui pointe sur la page qui décrit l'historique
>> de nos relations avec la DgFiP
>>
>> il manque à mon avis un lien vers la page du wiki : comment contribuer à
>> la BANO
>> http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO
>>
>>
>> Laurent
>>
>> ___
>> 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: [Talk-ca] Community Conduct

http://osmcha.mapbox.com/44545610/
I can see that it was our Friend Nakaner that has reported it to you, in
which there was a whole shit-show (sorry for the language) with Rps333 and
CanVEC imports in the north. You cannot deny that you and Nakaner have a
history with Rps333, Denis and I. So to ask so broadly without giving
history into the matter is quite an oversight and might be normal for me to
be defensive, because of our history together.

I've done mass adds(by hand) on my new account and have gotten 0 flak, but
once "LogicalViolinist" is attached to the changeset, it is flagged, which
I'm tired of(thus the defensive attitude).

On Thu, Dec 22, 2016 at 2:46 PM, James  wrote:

> Frederik, your email is very opinionated, when I have just showed you
> (pixel based) why I drew that building like that.
>
> On Thu, Dec 22, 2016 at 2:43 PM, Frederik Ramm 
> wrote:
>
>> Hi,
>>
>>I've been involved in a changeset discussion that I would like to
>> bring to the attention of a wider audience:
>>
>> http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947
>>
>> I don't think I'm the right person to continue that discussion but I see
>> several questionable attitudes here (e.g. the "I don't need to show
>> sources for what I do" attitude, the "I have more edits than you so shut
>> up" attitude).
>>
>> I was initially drawn to that changeset because it was flagged as a
>> potential import, adding 1000 houses over a couple of hours. I'm still
>> not sure if my suspicion was correct. It should be easy enough to
>> disprove but instead we're seeing statements, attacks and excuses worthy
>> of an US election twitter exchange.
>>
>> But maybe I'm overreacting and I'm prepared to let the matter rest if
>> the Canadian community finds that nomal.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
>
> --
> 外に遊びに行こう！
>

-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Ha Noj

> Jsem si celkem jistý, že v databázi, ze které pouštím aktualizace
> administrativních hranic mám nějaký starší méně přesný grid... a vůbec
> bych se nedivil, kdyby to měl Petr na poloha.net taky tak.
*** není žádný starší méně přesný a nový přesnější. Jsou dva gridy starý
Ježek2008 XY a nový Seidl2014 XYZ, nic víc, o změně přesnosti nebyla řeč.

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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Ha Noj

> > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
vlastně není a všichni jsou happy.
> *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám
vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
> No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový plugin a
do toho momentálně nejdu. Už tak mám na seznamu plno věcí, které bych chtěl
někdy udělat. Třeba pár vylepšení na osmap.cz.
*** a nebo pro poloha.net/budovy napsat skript, který pro každou budovu
vloží novou geometrii z WFS a není třeba nic měnit na tracer pluginu.

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

Re: [Talk-ca] Community Conduct

Frederik, your email is very opinionated, when I have just showed you
(pixel based) why I drew that building like that.

On Thu, Dec 22, 2016 at 2:43 PM, Frederik Ramm  wrote:

> Hi,
>
>I've been involved in a changeset discussion that I would like to
> bring to the attention of a wider audience:
>
> http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947
>
> I don't think I'm the right person to continue that discussion but I see
> several questionable attitudes here (e.g. the "I don't need to show
> sources for what I do" attitude, the "I have more edits than you so shut
> up" attitude).
>
> I was initially drawn to that changeset because it was flagged as a
> potential import, adding 1000 houses over a couple of hours. I'm still
> not sure if my suspicion was correct. It should be easy enough to
> disprove but instead we're seeing statements, attacks and excuses worthy
> of an US election twitter exchange.
>
> But maybe I'm overreacting and I'm prepared to let the matter rest if
> the Canadian community finds that nomal.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>



-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Community Conduct

2016-12-22 Thread Frederik Ramm

Hi,

   I've been involved in a changeset discussion that I would like to
bring to the attention of a wider audience:

http://www.openstreetmap.org/changeset/44545610#map=16/45.4064/-75.7947

I don't think I'm the right person to continue that discussion but I see
several questionable attitudes here (e.g. the "I don't need to show
sources for what I do" attitude, the "I have more edits than you so shut
up" attitude).

I was initially drawn to that changeset because it was flagged as a
potential import, adding 1000 houses over a couple of hours. I'm still
not sure if my suspicion was correct. It should be easy enough to
disprove but instead we're seeing statements, attacks and excuses worthy
of an US election twitter exchange.

But maybe I'm overreacting and I'm prepared to let the matter rest if
the Canadian community finds that nomal.

Bye
Frederik

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

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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

2016-12-22 Thread Steven Clays

Thanks Mark, just in case... as I said, it did not really happen before.

Steven

2016-12-22 19:57 GMT+01:00 Marc Gemis :

> Depending on the case, you can immediately revert the change (e.g.
> with the revert plugin in JOSM), or first contact the other mapper to
> inform him/her about the problem. Informing the user is preferred as
> this give you insight in the reasoning about the mapping or might
> teach the other mapper about his/her mistakes.
>
> The immediate revert might be needed for larger changes and when you
> are sure that the mapping is wrong. If there are smaller problems, it
> might be more interesting to allow the other mapper to correct the
> mistakes. A revert becomes harder when other people start editing in
> that area as well.
>
> In some cases, you will not get an answer after a few days, you can
> still do a revert, or just update the data (which might be easier and
> faster than a revert).
>
> The preferred way to discuss a problem is via changeset comments. The
> Data Working Group always asks to do this, in case it turns into an
> edit war, they have something to follow.
>
> I do not always follow this rule of communication, especially when the
> same user keeps on making the same mistake or has not made an edit in
> a long time
>
> OSM is a community project, so communication is important.
>
> regards
>
> m
>
> On Thu, Dec 22, 2016 at 7:44 PM, Steven Clays 
> wrote:
> > Thanks! Is there a procedure for reverting outright errors or sabotage?
> Can
> > I do this myself?
> > (To be clear: it is a hypothetical question, untill now it did not
> happen!)
> >
> > 2016-12-22 19:15 GMT+01:00 Glenn Plas :
> >>
> >> On 22-12-16 17:36, Steven Clays wrote:
> >> > Hallo,
> >> >
> >> > dit is misschien een beetje een basisvraagje, maar ik vond het
> antwoord
> >> > nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
> >> > de aanpassingen die een andere gebruiker maakt aan de wijzigingen die
> je
> >> > zelf hebt toegevoegd?
> >> >
> >> > This is perhaps a basis question, but I cannot immediately find an
> >> > answer. Is there any possibility to get a notification when somebody
> >> > edits a feature / geometry / tag / / ... you submitted earlier?
> >>
> >> you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
> >> last objects your target has touched.  WhoDidIt uses a bounding box area
> >> you wish to monitor.  Very handy.  That's how I keep track of a few
> >> large areas.
> >>
> >> I recommend using an RSS feed reader (thunderbird for example) for both.
> >>  They both support getting this using RSS
> >>
> >> Glenn
> >>
> >>
> >> [1] http://osmose.openstreetmap.fr/en/byuser/
> >> [2] http://zverik.osm.rambler.ru/whodidit/
> >> >
> >> > Merci voor het antwoord!
> >> > Thanks for helping me out!
> >> >
> >> > Steven
> >> >
> >> >
> >> > ___
> >> > Talk-be mailing list
> >> > Talk-be@openstreetmap.org
> >> > https://lists.openstreetmap.org/listinfo/talk-be
> >> >
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-ca] Talk-ca Digest, Vol 106, Issue 5

2016-12-22 Thread Ellefsen, Bjenk (STATCAN)

this, but
   if not it's easy to copy/paste all the correct tags in one go under "Tags
   of new changeset".
   4. use source:geometry=
   <https://wiki.openstreetmap.org/wiki/Key:source:geometry> instead of
   source= tag. Thus if POI information is later added to the polygon, it's
   unambiguous as to what the source refers to.
   5. I think building replacements (deletions and additions) should be
   done within the same changeset to make it safer. Deleting all the buildings
   first caused a headache the first time this import was attempted and some
   buildings which were of better quality than the import were wiped out.
   6. split into non-existing and pre-existing buildings. Conflating with
   existing polygons will be more difficult and time consuming. Thus it would
   be good to keep that step in separate changesets with appropriate comments
   so it's easier to review each others work, and disagreements can be more
   easily rectified without touching undisputed work. I've noticed other
   
<https://wiki.openstreetmap.org/wiki/Helsinki_region_building_import#Import_Type_2>
   building imports have done this where they split the dataset into
   overlapping and non-overlapping polygons by script.
   7. be more specific in the instructions about deciding which footprints
   are added. Will they be compared to background imagery? Sometimes
   <http://www.openstreetmap.org/changeset/44545610> buildings are
   completely wrong (mixed up in their dataset). And picking between existing
   and imported data is subjective, thus more detailed instructions would be
   good to improve quality and consistency between users.
   8. I would also like to see instructions on checking and copying over
   tags in pre-existing buildings which are to be replaced. And discuss how to
   handle offsets. What's the quality of the building survey? Should the
   aerial imagery be aligned to the polygon, or vise versa?
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20161222/c39e63ba/attachment-0001.html>

--

Message: 3
Date: Thu, 22 Dec 2016 13:51:46 -0500
From: James <james2...@gmail.com>
To: Devon Fyson <devonfy...@gmail.com>
Cc: OSM Imports List <impo...@openstreetmap.org>, Talk-CA
OpenStreetMap <talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] [Imports] Fwd: [Import] Ottawa Buildings &
Addresses [Statistics Canada project]
Message-ID:
<cank4qi8ww3pacfskxht09spudr2-udavr1cj2ezahweytoa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi devon, those DWG files(if you were following the import thread, you
would already know this) are old and outdated, never to be updated again.
The newer file is an export of what they have to date.

On Thu, Dec 22, 2016 at 1:47 PM, Devon Fyson <devonfy...@gmail.com> wrote:

> Here's are my thoughts on it:
>
>1. Arn't the building polygons already available? I see large buildings
><http://data.ottawa.ca/dataset/large-buildings> and the topographic
>DWG file <http://data.ottawa.ca/dataset/cad-topographic-data> which
>contains buildings.
>2. If this
>
> <https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan%20is%20still%20the%20import%20plan>
>is still the import plan, it should be gone through and updated.
>3. Should make use of the changeset tags
><https://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags>
>Most importantly type and url. For example:
>
>comment=Import building polygons for Ottawa, Canada. Importing
>non-existant polygons  Conflating with existing polygons
>type=import
>url:en=https://wiki.openstreetmap.org/wiki/Canada:Ontario:
>Ottawa/Import/Plan
>source:date=are released>
>source=City of Ottawa (maybe should include the dataset such as CAD
>Topographic Mapping Data or Large Buildings)
>source:url=http://data.ottawa.ca/en/dataset/cad-topographic-data (not
>in the list, but I made a comment about it here
>
> <https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/changeset_tags#source:url.3D.2A>
>)
>source:license=City of Ottawa Open Data Licence 2.0
>
>I'm not sure if the tasking manager to JOSM pipeline supports this,
>but if not it's easy to copy/paste all the correct tags in one go under
>"Tags of new changeset".
>4. use source:geometry=
><https://wiki.openstreetmap.org/wiki/Key:source:geometry> instead of
>source= tag. Thus if POI information is later added to the polygon,
>it's unambiguous as to what the source refers to.
>5. I think building replacements (deletions and additions) should be
>done within the sa

Re: [Talk-ca] [Imports] Fwd: [Import] Ottawa Buildings & Addresses [Statistics Canada project]

*1. Arn't the building polygons already available? I see large buildings
> and the topographic DWG
file > which contains
buildings.*
See previous email




*   2. If this
>
is still the import plan, it should be gone through and updated.*
It will once data is released.
























*3. Should make use of the changeset tags
>
Most importantly type and url. For example:   comment=Import building
polygons for Ottawa, Canada. Importing   non-existant polygons 
Conflating with existing polygons   type=import
url:en=https://wiki.openstreetmap.org/wiki/Canada
:
Ontario:Ottawa/Import/Plan   source:date=   source=City of Ottawa (maybe
should include the dataset such as CAD   Topographic Mapping Data or Large
Buildings)
source:url=http://data.ottawa.ca/en/dataset/cad-topographic-data
 (not in   the list,
but I made a comment about it here
>
)   source:license=City of Ottawa Open Data Licence 2.0   I'm not sure if
the tasking manager to JOSM pipeline supports this, but   if not it's easy
to copy/paste all the correct tags in one go under "Tags   of new
changeset".*
If you are suggesting a proposed feature that isn't even supported in JOSM,
why are you making the process more complex?




*  4. use source:geometry=
> instead of
source= tag. Thus if POI information is later added to the polygon, it's
unambiguous as to what the source refers to.*
+1 Great Idea





*5. I think building replacements (deletions and additions) should be
done within the same changeset to make it safer. Deleting all the
buildings   first caused a headache the first time this import was
attempted and some   buildings which were of better quality than the import
were wiped out.*We've already addressed this via the replace geometry tool.










*6. split into non-existing and pre-existing buildings. Conflating with
existing polygons will be more difficult and time consuming. Thus it
would   be good to keep that step in separate changesets with appropriate
comments   so it's easier to review each others work, and disagreements can
be more   easily rectified without touching undisputed work. I've noticed
other
>
building imports have done this where they split the dataset into
overlapping and non-overlapping polygons by script.*Denis has modified the
data service to do this already via qa-tiles from mapbox, process will be
updated when files are released.








*7. be more specific in the instructions about deciding which footprints
are added. Will they be compared to background imagery? Sometimes
> buildings are
completely wrong (mixed up in their dataset). And picking between
existing   and imported data is subjective, thus more detailed instructions
would be   good to improve quality and consistency between users.*
Only a select few will be doing the import, comparisons will be done via
the imagery available. The change set you linked is in Gatineau and
unrelated to the Ottawa Import.





*8. I would also like to see instructions on checking and copying over
tags in pre-existing buildings which are to be replaced. And discuss how
to   handle offsets. What's the quality of the building survey? Should
the   aerial imagery be aligned to the polygon, or vise versa?*
Tags are automatically "copied" over with replace geometry tool(IF REPLACED
AT ALL) (Please refer to old import mailing list as these concerns have
already been addressed)


On Thu, Dec 22, 2016 at 1:47 PM, Devon Fyson  wrote:

> Here's are my thoughts on it:
>
>1. Arn't the building polygons already available? I see large buildings
> and the topographic
>DWG file  which
>contains buildings.
>2. If this
>
>

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

Depending on the case, you can immediately revert the change (e.g.
with the revert plugin in JOSM), or first contact the other mapper to
inform him/her about the problem. Informing the user is preferred as
this give you insight in the reasoning about the mapping or might
teach the other mapper about his/her mistakes.

The immediate revert might be needed for larger changes and when you
are sure that the mapping is wrong. If there are smaller problems, it
might be more interesting to allow the other mapper to correct the
mistakes. A revert becomes harder when other people start editing in
that area as well.

In some cases, you will not get an answer after a few days, you can
still do a revert, or just update the data (which might be easier and
faster than a revert).

The preferred way to discuss a problem is via changeset comments. The
Data Working Group always asks to do this, in case it turns into an
edit war, they have something to follow.

I do not always follow this rule of communication, especially when the
same user keeps on making the same mistake or has not made an edit in
a long time

OSM is a community project, so communication is important.

regards

m

On Thu, Dec 22, 2016 at 7:44 PM, Steven Clays  wrote:
> Thanks! Is there a procedure for reverting outright errors or sabotage? Can
> I do this myself?
> (To be clear: it is a hypothetical question, untill now it did not happen!)
>
> 2016-12-22 19:15 GMT+01:00 Glenn Plas :
>>
>> On 22-12-16 17:36, Steven Clays wrote:
>> > Hallo,
>> >
>> > dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
>> > nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
>> > de aanpassingen die een andere gebruiker maakt aan de wijzigingen die je
>> > zelf hebt toegevoegd?
>> >
>> > This is perhaps a basis question, but I cannot immediately find an
>> > answer. Is there any possibility to get a notification when somebody
>> > edits a feature / geometry / tag / / ... you submitted earlier?
>>
>> you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
>> last objects your target has touched.  WhoDidIt uses a bounding box area
>> you wish to monitor.  Very handy.  That's how I keep track of a few
>> large areas.
>>
>> I recommend using an RSS feed reader (thunderbird for example) for both.
>>  They both support getting this using RSS
>>
>> Glenn
>>
>>
>> [1] http://osmose.openstreetmap.fr/en/byuser/
>> [2] http://zverik.osm.rambler.ru/whodidit/
>> >
>> > Merci voor het antwoord!
>> > Thanks for helping me out!
>> >
>> > Steven
>> >
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

On 22-12-16 19:44, Steven Clays wrote:
> Thanks! Is there a procedure for reverting outright errors or sabotage?
> Can I do this myself?
> (To be clear: it is a hypothetical question, untill now it did not happen!)

To revert changes you have a few options:

 - Use the revert plugin (which restores rather than reverts a
changeset).  It's hard to use on ages edit's.  You need to use conflict
resolution in JOSM and that's not easy.
 - Report the malicious edit to get it reverted.

You can find more info here https://wiki.openstreetmap.org/wiki/Vandalism

Glenn

> 
> 2016-12-22 19:15 GMT+01:00 Glenn Plas  >:
> 
> On 22-12-16 17:36, Steven Clays wrote:
> > Hallo,
> >
> > dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
> > nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
> > de aanpassingen die een andere gebruiker maakt aan de wijzigingen die je
> > zelf hebt toegevoegd?
> >
> > This is perhaps a basis question, but I cannot immediately find an
> > answer. Is there any possibility to get a notification when somebody
> > edits a feature / geometry / tag / / ... you submitted earlier?
> 
> you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
> last objects your target has touched.  WhoDidIt uses a bounding box area
> you wish to monitor.  Very handy.  That's how I keep track of a few
> large areas.
> 
> I recommend using an RSS feed reader (thunderbird for example) for both.
>  They both support getting this using RSS
> 
> Glenn
> 
> 
> [1] http://osmose.openstreetmap.fr/en/byuser/
> 
> [2] http://zverik.osm.rambler.ru/whodidit/
> 
> >
> > Merci voor het antwoord!
> > Thanks for helping me out!
> >
> > Steven
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be
> 
> >
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

C'est prévu dans la liste des améliorations de n'afficher que les 
niveaux qui ont un intérêt pour l'utilisateur final (dans la version de 
base) ;-)


Cordialement.


Le 22/12/2016 à 19:19, osm.sanspourr...@spamgourmet.com a écrit :

Et aussi pour l'exemple à ne pas imiter :
http://dev.openlevelup.net/?l=0#18/48.85987/2.33761
Plusieurs salles portent le même nom, il faudrait mieux définir un 
multipolygone avec un seul nom.


Au fait, Christian, c'est sympa pour les aveugles, tu as fait une 
carte en braille :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.85987/2.33761

Adrien, quand il y a plusieurs niveaux superposés on aimerait savoir 
s'il y a une information pertinente.
Par exemple à côté il y a l'Église Saint-Leu - Saint-Gilles 
http://www.openstreetmap.org/way/53933240 par exemple qui apparaît à 
plusieurs niveaux mais il n'y a aucune information spécifique.
Donc présenter les niveaux 3 et 4 qui sont identiques n'apporte guère 
d'info (3-4 suffirait).
LevelUp c'est super quand diverses couches se superposent. Si c'est 
juste l'épaisseur d'une couche, sauf à prendre une vue 3D (isométrique 
par exemple) ça n'a pas un intérêt fou pour l'utilisateur final (au 
plus un +/- sur les bâtiments pour savoir ceux qui continuent au 
dessus/en dessous???).
Oui, je me vois ici comme utilisateur, je laisse l'algorithmique de 
côté ;-).


Jean-Yvon



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

Re: [Talk-ca] [Imports] Fwd: [Import] Ottawa Buildings & Addresses [Statistics Canada project]

Hi devon, those DWG files(if you were following the import thread, you
would already know this) are old and outdated, never to be updated again.
The newer file is an export of what they have to date.

On Thu, Dec 22, 2016 at 1:47 PM, Devon Fyson  wrote:

> Here's are my thoughts on it:
>
>1. Arn't the building polygons already available? I see large buildings
> and the topographic
>DWG file  which
>contains buildings.
>2. If this
>
> 
>is still the import plan, it should be gone through and updated.
>3. Should make use of the changeset tags
>
>Most importantly type and url. For example:
>
>comment=Import building polygons for Ottawa, Canada. Importing
>non-existant polygons  Conflating with existing polygons
>type=import
>url:en=https://wiki.openstreetmap.org/wiki/Canada:Ontario:
>Ottawa/Import/Plan
>source:date=are released>
>source=City of Ottawa (maybe should include the dataset such as CAD
>Topographic Mapping Data or Large Buildings)
>source:url=http://data.ottawa.ca/en/dataset/cad-topographic-data (not
>in the list, but I made a comment about it here
>
> 
>)
>source:license=City of Ottawa Open Data Licence 2.0
>
>I'm not sure if the tasking manager to JOSM pipeline supports this,
>but if not it's easy to copy/paste all the correct tags in one go under
>"Tags of new changeset".
>4. use source:geometry=
> instead of
>source= tag. Thus if POI information is later added to the polygon,
>it's unambiguous as to what the source refers to.
>5. I think building replacements (deletions and additions) should be
>done within the same changeset to make it safer. Deleting all the buildings
>first caused a headache the first time this import was attempted and some
>buildings which were of better quality than the import were wiped out.
>6. split into non-existing and pre-existing buildings. Conflating with
>existing polygons will be more difficult and time consuming. Thus it would
>be good to keep that step in separate changesets with appropriate comments
>so it's easier to review each others work, and disagreements can be more
>easily rectified without touching undisputed work. I've noticed other
>
> 
>building imports have done this where they split the dataset into
>overlapping and non-overlapping polygons by script.
>7. be more specific in the instructions about deciding which
>footprints are added. Will they be compared to background imagery?
>Sometimes  buildings
>are completely wrong (mixed up in their dataset). And picking between
>existing and imported data is subjective, thus more detailed instructions
>would be good to improve quality and consistency between users.
>8. I would also like to see instructions on checking and copying over
>tags in pre-existing buildings which are to be replaced. And discuss how to
>handle offsets. What's the quality of the building survey? Should the
>aerial imagery be aligned to the polygon, or vise versa?
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

2016-12-22 Thread Steven Clays

Thanks! Is there a procedure for reverting outright errors or sabotage? Can
I do this myself?
(To be clear: it is a hypothetical question, untill now it did not happen!)

2016-12-22 19:15 GMT+01:00 Glenn Plas :

> On 22-12-16 17:36, Steven Clays wrote:
> > Hallo,
> >
> > dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
> > nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
> > de aanpassingen die een andere gebruiker maakt aan de wijzigingen die je
> > zelf hebt toegevoegd?
> >
> > This is perhaps a basis question, but I cannot immediately find an
> > answer. Is there any possibility to get a notification when somebody
> > edits a feature / geometry / tag / / ... you submitted earlier?
>
> you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
> last objects your target has touched.  WhoDidIt uses a bounding box area
> you wish to monitor.  Very handy.  That's how I keep track of a few
> large areas.
>
> I recommend using an RSS feed reader (thunderbird for example) for both.
>  They both support getting this using RSS
>
> Glenn
>
>
> [1] http://osmose.openstreetmap.fr/en/byuser/
> [2] http://zverik.osm.rambler.ru/whodidit/
> >
> > Merci voor het antwoord!
> > Thanks for helping me out!
> >
> > Steven
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Petr Morávek [Xificurk]

Dne 20.12.2016 v 11:40 Ha Noj napsal(a):
> 2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/
> http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid

Ahoj,

tohle je třeba pro mne nové info - přiznám se, že jsem to tu poslední
dobou moc nesledoval, tak nevím jestli jsem zmínku o tomto gridu jen
přehlédl, nebo sem opravdu doputovala až teď.

Jsem si celkem jistý, že v databázi, ze které pouštím aktualizace
administrativních hranic mám nějaký starší méně přesný grid... a vůbec
bych se nedivil, kdyby to měl Petr na poloha.net taky tak.

Každopádně díky za info, aspoň si mám s čím přes vánoce hrát :-)

Zdraví,
Petr Morávek aka Xificurk

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !


Et aussi pour l'exemple à ne pas imiter :
http://dev.openlevelup.net/?l=0#18/48.85987/2.33761
Plusieurs salles portent le même nom, il faudrait mieux définir un 
multipolygone avec un seul nom.


Au fait, Christian, c'est sympa pour les aveugles, tu as fait une carte 
en braille :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.85987/2.33761

Adrien, quand il y a plusieurs niveaux superposés on aimerait savoir 
s'il y a une information pertinente.
Par exemple à côté il y a l'Église Saint-Leu - Saint-Gilles 
http://www.openstreetmap.org/way/53933240 par exemple qui apparaît à 
plusieurs niveaux mais il n'y a aucune information spécifique.
Donc présenter les niveaux 3 et 4 qui sont identiques n'apporte guère 
d'info (3-4 suffirait).
LevelUp c'est super quand diverses couches se superposent. Si c'est 
juste l'épaisseur d'une couche, sauf à prendre une vue 3D (isométrique 
par exemple) ça n'a pas un intérêt fou pour l'utilisateur final (au plus 
un +/- sur les bâtiments pour savoir ceux qui continuent au dessus/en 
dessous???).
Oui, je me vois ici comme utilisateur, je laisse l'algorithmique de côté 
;-).


Jean-Yvon

Le 22/12/2016 à 18:02, PanierAvide - panierav...@riseup.net a écrit :

Le 22/12/2016 à 17:24, Christian Quest a écrit :
Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle, 
entrée... ça me démange de rendre ça visible ;)


Genre comme ça :
http://dev.openlevelup.net/?l=1#19/48.86059/2.33575

#placement produit :-)

Cordialement,

PanierAvide.


___
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-ca] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

2016-12-22 Thread Ellefsen, Bjenk (STATCAN)


Hello everyone,

As James wrote yesterday, the City of Ottawa has approved the release of a 
large building footprints file for their Open Data portal.
We have been working in close collaboration with the City of Ottawa on that 
front and it is a major contribution. 

We are tracking progress and will communicate the changes to the map soon. 

We want to thank everyone for your feedback and please continue sending us your 
suggestions! A new version of the adapted version of iD is live. This updated 
version was redone to restore the built-in login process of iD and the app 
doesn’t load in an iframe anymore. This new version is also using the available 
built-in functions for a number of things. This has improved performance and it 
is working in all browsers.

If you see any bugs if you have any comments to improve it, let us know! 
(http://www.crowdid.osmcanada.ca)

We wish the best holidays with your families and friends!

Bjenk
Crowdsourcing team at Statistics Canada 

Website: http://www.statcan.gc.ca/eng/crowdsourcing?HPA=1
Email: bjenk.ellef...@canada.ca
Project email for feedback: statcan.crowdsource.stat...@canada.ca / 
statcan.approcheparticipative.stat...@canada.ca



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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

On 22-12-16 17:36, Steven Clays wrote:
> Hallo,
> 
> dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
> nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
> de aanpassingen die een andere gebruiker maakt aan de wijzigingen die je
> zelf hebt toegevoegd?
> 
> This is perhaps a basis question, but I cannot immediately find an
> answer. Is there any possibility to get a notification when somebody
> edits a feature / geometry / tag / / ... you submitted earlier?

you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
last objects your target has touched.  WhoDidIt uses a bounding box area
you wish to monitor.  Very handy.  That's how I keep track of a few
large areas.

I recommend using an RSS feed reader (thunderbird for example) for both.
 They both support getting this using RSS

Glenn


[1] http://osmose.openstreetmap.fr/en/byuser/
[2] http://zverik.osm.rambler.ru/whodidit/
> 
> Merci voor het antwoord!
> Thanks for helping me out!
> 
> Steven
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [Talk-GB] Local Authority rights of way information

2016-12-22 Thread Barry Cornelius

It's not all gloom as some local authorities do advertise their licence on 
their website.  Examples are Brecon Beacons NPA, Bucks, Derbyshire, Gateshead, 
Hampshire, Manchester, North York Moors NPA, Norfolk, Nottingham, Oldham, 
Oxfordshire, Redcar and Cleveland, Salford, Stockton, Trafford, Wirral.

On 22 December 2016 16:45:41 WET, SK53  wrote:
>Hi Barry,
>
>This is all very useful and clarifies some issues for various datasets.
>
>I and others have indeed been using rowmaps data in the way you
>suggest: as
>a tool for planning surveys.
>
>I still think it's a shame that councils are so reluctant to clearly
>state
>the nature of licences on their own websites, and rely on you to
>perform
>this service with the inevitable issues of introducing more steps which
>is
>already complicated by the different roles of LAs/OSGB.
>
>Regards,
>
>Jerry
>
>On 22 December 2016 at 15:53, Barry Cornelius
>
>wrote:
>
>> I've received a tweet drawing my attention to a thread with the
>subject
>> "Local Authority rights of way information". I wasn't receiving the
>emails
>> for this list and I can't see a way of replying to an e-mail if you
>didn't
>> receive it. So I guess I'm starting a new thread which is annoying.
>>
>> On Wed Dec 21 11:17:17, Chris Hill wrote:
>> > Row maps is definitely not based on OGL data.
>>
>> If you go to:
>> http://www.rowmaps.com/datasets
>> and then go to the pages for each of North Lincolnshire, Oldham,
>> Portsmouth, Salford, Wigan and the Wirral, you'll see that these
>datasets
>> are released with the OGL.
>>
>> The datasets for most of the other local authorities were released
>under
>> terms equivalent to the OS OpenData Licence. When I e-mailed the
>Ordnance
>> Survey about the local authorities that had, during the last few
>years,
>> successfully obtained an exemption from the Public Sector Mapping
>Agreement
>> and released their data under terms equivalent to the OS OpenData
>Licence,
>> Richard Mortara [Public Sector Contracts Manager, Ordnance Survey]
>replied:
>> "All data exempted by Ordnance Survey is now covered by the Open
>Government
>> Licence (OGL), which superseded its own OS OpenData licence in April
>2015."
>>
>> > [Row maps] includes E Yorks and Hull data that both councils have
>> explicitly refused to release as OGL.
>>
>> Actually the website www.rowmaps.com does not yet provide data for
>Hull.
>>
>> As far as East Yorkshire is concerned, I received an e-mail from
>Judith
>> Rockliff [Engineer (Definitive Map), Asset Strategy, Planning and
>Economic
>> Regeneration, East Riding of Yorkshire Council] on 10th January 2013
>that
>> said "I am pleased to be able to tell you that a request from East
>Riding
>> of Yorkshire Council for a derived data exemption in relation to its
>Public
>> Rights of Way (PRoW) datasets has now been approved. As a
>consequence, the
>> terms equivalent to OS OpenData (see http://www.ordnancesurvey.co.
>> uk/oswebsite/opendata/docs/os-opendata-licence.pdf ) may now also be
>> applied to the dataset being released."
>>
>> When I requested an update in 2014, I received a reply from Gordon
>Grimley
>> [Assistant Engineer (Definitive Map), Asset Strategy (AS 67),
>Planning and
>> Economic Regeneration, East Riding of Yorkshire Council] on 27th
>February
>> 2014 saying "Attached is the most recent copy of the shapefile. All
>the
>> same licences etc apply."
>>
>> > I have asked Barry for his sources and there has been a stoney
>silence.
>>
>> I don't normally ignore e-mails. So maybe your e-mail didn't get to
>me.
>>
>> > If anyone has used rowmaps as a source for OSM edits I would revert
>that
>> edit.
>>
>> Although I don't do the hard grind of adding to OSM, it has always
>been my
>> view that's it's irrelevant as to what licence the data has been
>released
>> with. As others have pointed out in this thread, the data from
>> www.rowmaps.com can best be used to identify a PROW that needs
>surveying:
>> what's in the data may be quite different from what happens on the
>ground.
>> And this disclaimer that www.rowmaps.com shows alongside any map is
>also
>> appropriate: "An authority's Definitive Map is the authoritative
>source of
>> their rights of way. The details of the public rights of way network
>> contained in an authority's data are for information only, and are an
>> interpretation of the Definitive Map, not the Definitive Map itself,
>and
>> should not be relied on for determining the position or alignment of
>any
>> public right of way. For legal purposes, an authority's data does not
>> replace their Definitive Map. And changes may have been made to the
>> Definitive Map that are not included in their data."
>> --
>> Barry Cornelius
>> http://www.northeastraces.com/
>> http://www.oxonraces.com/
>> http://www.rowmaps.com/
>> http://www.thehs2.com/
>> http://www.oxonpaths.com/
>> http://www.barrycornelius.com/
>>
>> ___
>> Talk-GB mailing

Re: [OSM-talk-fr] cartes.xyz / bad request

2016-12-22 Thread Vincent Bergeot


Bonjour,
suite à nos échanges privés, le résultat pour tout le monde néanmoins !

Le 22/12/2016 à 17:19, Florian LAINEZ a écrit :
Y a-t-il moyen de définir une image pour chaque POI individuellement ? 
En attendant que cela soit géré dynamiquement ;)


c'est le cas, en faisant un appel de l'image avec la valeur du tag 
mapillary :

![](https://d1cuyjsrcm0gby.cloudfront.net/{mapillary}/thumb-640.jpg)

Visible ici : https://www.cartes.xyz/t/2519bc-Les_bornes_trilib_pour_Florian

bonnes fêtes :)

--
Vincent Bergeot


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

Re: [OSM-talk-fr] site cadastre.openstreetmap.fr

2016-12-22 Thread Tyndare



J'ai rajouté les liens que tu mentionnent sur 
http://cadastre.openstreetmap.fr/


Mais Hélène Petit m'avais fait remarquer que cette page n'est pas très 
simple pour ceux qui la découvrent pour la première fois, et à force de 
rajouter des trucs ça ne s'améliore pas.


Si quelqu'un a une proposition a faire qui rendrait cette page plus 
claire (quitte à découper en plusieurs sous pages), surtout n'hésitez pas.



Le 22/12/2016 à 15:32, Laurent Combe a écrit :

A partir de ce site
http://cadastre.openstreetmap.fr/
ou de
http://cadastre.openstreetmap.fr/fantoir

je ne vois pas de lien vers les listes départementales (citées
récemment par nicolas)
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

àm on humble avis, ce serait un plus d'avoir à partir du site accès à
l'ensemble des outils disponibles (par un simple lien)

autre point
sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
lien vers le wiki mais qui pointe sur la page qui décrit l'historique
de nos relations avec la DgFiP

il manque à mon avis un lien vers la page du wiki : comment contribuer à la BANO
http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO


Laurent

___
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] Rendu FR, bientôt en version 2017 !


Le 22/12/2016 à 17:24, Christian Quest a écrit :
Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle, 
entrée... ça me démange de rendre ça visible ;)


Genre comme ça :
http://dev.openlevelup.net/?l=1#19/48.86059/2.33575

#placement produit :-)

Cordialement,

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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

2016-12-22 Thread Guy Vanvuchelen

Als je in JOSM een sleutel (key) selecteert en je drukt op CTRL H dan krijg je 
de historie van deze sleutel….  maar dat is waarschijnlijk niet wat je wil. 

 

Guy VV

 

Van: Steven Clays [mailto:steven.cl...@gmail.com] 
Verzonden: donderdag 22 december 2016 17:36
Aan: OpenStreetMap Belgium
Onderwerp: [OSM-talk-be] Aanpassingsmeldingen / Notifications

 

Hallo,

dit is misschien een beetje een basisvraagje, maar ik vond het antwoord 
nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van de 
aanpassingen die een andere gebruiker maakt aan de wijzigingen die je zelf hebt 
toegevoegd?

This is perhaps a basis question, but I cannot immediately find an answer. Is 
there any possibility to get a notification when somebody edits a feature / 
geometry / tag / / ... you submitted earlier?

Merci voor het antwoord!

Thanks for helping me out!

Steven

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

[Talk-it] OSM in GEOmedia speciale emergenze

2016-12-22 Thread Marco Minghini

Ciao a tutti,

per chi non lo avesse già visto, segnalo che è uscito lo speciale del
magazine GEOmedia dedicato alla cartografia per le emergenze con focus sul
terremoto nel centro Italia [1]. Ci sono diversi articoli su OSM,  tra cui
quello che ho scritto insieme a Flavio Lupia, Maurizio Napolitano,
Alessandro Palmas e Alessandro Sarretta (che approfitto per ri-ringraziare
della disponibilità). La rivista è sfogliabile online, per semplicità
trovate qui [2] il link al pdf dell'articolo di cui sopra.

Buone feste a tutti!

Marco


[1]
http://www.rivistageomedia.it/2016122010101/dati-geografici/online-lo-speciale-del-magazine-geomedia-dedicato-alla-cartografia-per-le-emergenze

[2]
https://www.researchgate.net/profile/Marco_Minghini/publication/311716850_VGI_ed_emergenze/links/5857ac2908ae8f695559f32e.pdf

Marco Minghini, Ph.D.
GEOlab, Politecnico di Milano - Como Campus
via Valleggio 11, 22100 Como (Italy)
+39 031 3327540
marco.mingh...@polimi.it
@MarcoMinghini 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Local Authority rights of way information

2016-12-22 Thread SK53

Hi Barry,

This is all very useful and clarifies some issues for various datasets.

I and others have indeed been using rowmaps data in the way you suggest: as
a tool for planning surveys.

I still think it's a shame that councils are so reluctant to clearly state
the nature of licences on their own websites, and rely on you to perform
this service with the inevitable issues of introducing more steps which is
already complicated by the different roles of LAs/OSGB.

Regards,

Jerry

On 22 December 2016 at 15:53, Barry Cornelius 
wrote:

> I've received a tweet drawing my attention to a thread with the subject
> "Local Authority rights of way information". I wasn't receiving the emails
> for this list and I can't see a way of replying to an e-mail if you didn't
> receive it. So I guess I'm starting a new thread which is annoying.
>
> On Wed Dec 21 11:17:17, Chris Hill wrote:
> > Row maps is definitely not based on OGL data.
>
> If you go to:
> http://www.rowmaps.com/datasets
> and then go to the pages for each of North Lincolnshire, Oldham,
> Portsmouth, Salford, Wigan and the Wirral, you'll see that these datasets
> are released with the OGL.
>
> The datasets for most of the other local authorities were released under
> terms equivalent to the OS OpenData Licence. When I e-mailed the Ordnance
> Survey about the local authorities that had, during the last few years,
> successfully obtained an exemption from the Public Sector Mapping Agreement
> and released their data under terms equivalent to the OS OpenData Licence,
> Richard Mortara [Public Sector Contracts Manager, Ordnance Survey] replied:
> "All data exempted by Ordnance Survey is now covered by the Open Government
> Licence (OGL), which superseded its own OS OpenData licence in April 2015."
>
> > [Row maps] includes E Yorks and Hull data that both councils have
> explicitly refused to release as OGL.
>
> Actually the website www.rowmaps.com does not yet provide data for Hull.
>
> As far as East Yorkshire is concerned, I received an e-mail from Judith
> Rockliff [Engineer (Definitive Map), Asset Strategy, Planning and Economic
> Regeneration, East Riding of Yorkshire Council] on 10th January 2013 that
> said "I am pleased to be able to tell you that a request from East Riding
> of Yorkshire Council for a derived data exemption in relation to its Public
> Rights of Way (PRoW) datasets has now been approved. As a consequence, the
> terms equivalent to OS OpenData (see http://www.ordnancesurvey.co.
> uk/oswebsite/opendata/docs/os-opendata-licence.pdf ) may now also be
> applied to the dataset being released."
>
> When I requested an update in 2014, I received a reply from Gordon Grimley
> [Assistant Engineer (Definitive Map), Asset Strategy (AS 67), Planning and
> Economic Regeneration, East Riding of Yorkshire Council] on 27th February
> 2014 saying "Attached is the most recent copy of the shapefile. All the
> same licences etc apply."
>
> > I have asked Barry for his sources and there has been a stoney silence.
>
> I don't normally ignore e-mails. So maybe your e-mail didn't get to me.
>
> > If anyone has used rowmaps as a source for OSM edits I would revert that
> edit.
>
> Although I don't do the hard grind of adding to OSM, it has always been my
> view that's it's irrelevant as to what licence the data has been released
> with. As others have pointed out in this thread, the data from
> www.rowmaps.com can best be used to identify a PROW that needs surveying:
> what's in the data may be quite different from what happens on the ground.
> And this disclaimer that www.rowmaps.com shows alongside any map is also
> appropriate: "An authority's Definitive Map is the authoritative source of
> their rights of way. The details of the public rights of way network
> contained in an authority's data are for information only, and are an
> interpretation of the Definitive Map, not the Definitive Map itself, and
> should not be relied on for determining the position or alignment of any
> public right of way. For legal purposes, an authority's data does not
> replace their Definitive Map. And changes may have been made to the
> Definitive Map that are not included in their data."
> --
> Barry Cornelius
> http://www.northeastraces.com/
> http://www.oxonraces.com/
> http://www.rowmaps.com/
> http://www.thehs2.com/
> http://www.oxonpaths.com/
> http://www.barrycornelius.com/
>
> ___
> 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: [OSM-talk] Building Detection using Machine Learning

2016-12-22 Thread Mikel Maron

Frederik, all
> an editor plugin were to help the mapper trace buildings that the mapper 
>identifies or at least individually verifies, that would probably be ok
This feels like the consensus across the board -- machine learning has 
potential to be useful when integrated into a human editor workflow. Maybe we 
can work on guidelines that encapsulates this. With something written up, we'll 
be able to stop "spinning wheels" on whether this is useful or not, and focus 
on experimenting and implementing promising approaches.
-Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Wednesday, December 21, 2016 7:59 PM, Frederik Ramm 
 wrote:

 Hi,

On 12/22/2016 01:10 AM, john whelan wrote:
> Do we have any guidelines in the wiki etc?

Nothing specific, no.

Automated editing and/or import guidelines would apply to any such
process and I would ask everyone who overhears discussions about
"uploading" machine-detected data to OSM to point this out to those
discussing. We've already had to revert a couple hundred thousand such
edits (roads though, not buildings).

If, OTOH, an editor plugin were to help the mapper trace buildings that
the mapper identifies or at least individually verifies, that would
probably be ok, at least until HOT trains an army of monkeys with
typewriters, er keyboards, to rubber-stamp everything the algorithm puts
out ;)

More generally speaking, in my opinion the human-centered aspect of
mapping is a key property that sets us apart from other map databases.
You can safely assume that any algorithm we can run to detect buildings,
Google can run 1000 times faster and with a fraction of the error rate,
leading to 1000 times more and 10 times better data of that kind than we
can accumulate. This is not a field in which we can, or should attempt
to, compete.

Bye
Frederik

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

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

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

[OSM-talk-be] Aanpassingsmeldingen / Notifications

2016-12-22 Thread Steven Clays

Hallo,

dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van de
aanpassingen die een andere gebruiker maakt aan de wijzigingen die je zelf
hebt toegevoegd?

This is perhaps a basis question, but I cannot immediately find an answer.
Is there any possibility to get a notification when somebody edits a
feature / geometry / tag / / ... you submitted earlier?

Merci voor het antwoord!
Thanks for helping me out!

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

Re: [OSM-talk-fr] Contributeur du mois: Philippe Verdy

2016-12-22 Thread Marc SIBERT


Bonjour,

Je n'aurais qu'un mot : édifiant.

A+

On 22/12/2016 16:46, Marc Gemis wrote:

Bonsoir,

Dans notre série "Contributeur du mois" [1] nous avons une entrevue
avec Philippe Verdy:
http://www.openstreetmap.org/user/escada/diary/40120

m.

[1] 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Belgian_Mapper_of_the_Month

___
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] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Christian Quest

Le 22 décembre 2016 à 17:16, Christian Quest  a
écrit :

> Le 22 décembre 2016 à 15:19, Florian LAINEZ  a écrit :
>
>>
>> Autre remarque : afficher les entrance sans visualiser les espaces
>> intérieurs, ça donne ça sur Montparnasse : http://umap.openstreetmap.fr/f
>> r/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062
>>
>> Tu remarqueras que je me plains sans apporter de solution !
>>
>>
> Effectivement, ça pique un peu, mais bon, c'est pas nouveau. :(
>


Humm... ça pique vraiment:
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.86067/2.33558

Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle,
entrée... ça me démange de rendre ça visible ;)


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

Re: [OSM-talk-fr] cartes.xyz / bad request

2016-12-22 Thread Florian LAINEZ

Merci, j'ai mis à jour la requête
https://www.cartes.xyz/t/fcd984-Bornes_Trilib#
Les données devraient apparaitre lorsque le cache se mettra à jour ... y
a-t-il moyen de forcer cela ? ça serait très utile ...

Je profite de ce fil de discussion sur MapContrib pour vous dire que la
version 1.0.0 pourrait arriver par la cheminée ce week-end

Huge !! Encore bravo pour ce boulot extra Guillaume.

Question subsidiaire : je n'arrive pas à afficher une image pour chaque
type de POI, comme tu l'avais fait la dernière fois pour mon exemple du
covoiturage. Où est-ce caché ?
Y a-t-il moyen de définir une image pour chaque POI individuellement ? En
attendant que cela soit géré dynamiquement ;)
Merci


Le 21 décembre 2016 à 20:55, Guillaume AMAT  a écrit :

> Pas mieux, merci Éric pour la réponse.
>
> Je profite de ce fil de discussion sur MapContrib pour vous dire que la
> version 1.0.0 pourrait arriver par la cheminée ce week-end, mais chut ^^
>
> Bon réveillon à tous,
> Guillaume
>
> Le 21/12/2016 à 20:39, Éric Gillet a écrit :
>
> Le 21 décembre 2016 à 19:53, Florian LAINEZ  a écrit :
>
>> Désolé de relancer le sujet mais j'ai créé une nouvelle carte des bornes
>> Trilib' à Paris https://www.cartes.xyz/t/fcd984-Bornes_Trilib
>> Cette fois j'ai bien retenu la leçon et je n'ai pas mis de requête
>> overpass-turbo mais bien une requête API overpass.
>> J'ai toujours le même soucis : bad request ... help !
>>
>
> Il faut mettre la requête Overpass en elle-même et pas une URL vers l'API
> Overpass :
> https://www.cartes.xyz/t/34563d-MapContrib
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Christian Quest

Le 22 décembre 2016 à 15:19, Florian LAINEZ  a écrit :

> Bon boulot Christian, ravi de voir que le rendu avance.
>
> Concernant le indoor tu dis que les objets en sous-sol ont disparus mais
> je vois toujours la gare sous-terraine de Magenta ;)
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
> 740#17/48.88077/2.35857
> Les données sont pourtant bien tagguées avec un level négatif.
>
>

Les shop=* n'avaient pas droit à ce traitement, mais pour le reste j'ai
vérifié avec les données et ça estompe bien si level<0.




> Autre remarque : afficher les entrance sans visualiser les espaces
> intérieurs, ça donne ça sur Montparnasse : http://umap.openstreetmap.fr/f
> r/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062
>
> Tu remarqueras que je me plains sans apporter de solution !
>
>
Effectivement, ça pique un peu, mais bon, c'est pas nouveau. :(



> sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
> afficher
>
> +1
>
>
On continue sur l'autre fil pour ça...


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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Marián Kyral

Dne 22.12.2016 v 13:32 Ha Noj napsal(a):
> > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
> vlastně není a všichni jsou happy.
> *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co
> nám vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
>

No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový plugin
a do toho momentálně nejdu. Už tak mám na seznamu plno věcí, které bych
chtěl někdy udělat. Třeba pár vylepšení na osmap.cz.

Marián


> ha
> hanoj
>

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

[Talk-GB] Local Authority rights of way information

2016-12-22 Thread Barry Cornelius

I've received a tweet drawing my attention to a thread with the subject "Local 
Authority rights of way information". I wasn't receiving the emails for this 
list and I can't see a way of replying to an e-mail if you didn't receive it.  
So I guess I'm starting a new thread which is annoying.

On Wed Dec 21 11:17:17, Chris Hill wrote:
> Row maps is definitely not based on OGL data.

If you go to:
   http://www.rowmaps.com/datasets
and then go to the pages for each of North Lincolnshire, Oldham, Portsmouth, 
Salford, Wigan and the Wirral, you'll see that these datasets are released with 
the OGL.

The datasets for most of the other local authorities were released under terms 
equivalent to the OS OpenData Licence.  When I e-mailed the Ordnance Survey 
about the local authorities that had, during the last few years, successfully 
obtained an exemption from the Public Sector Mapping Agreement and released 
their data under terms equivalent to the OS OpenData Licence, Richard Mortara 
[Public Sector Contracts Manager, Ordnance Survey] replied: "All data exempted 
by Ordnance Survey is now covered by the Open Government Licence (OGL), which 
superseded its own OS OpenData licence in April 2015."

> [Row maps] includes E Yorks and Hull data that both councils have explicitly 
> refused to release as OGL.

Actually the website www.rowmaps.com does not yet provide data for Hull.

As far as East Yorkshire is concerned, I received an e-mail from Judith 
Rockliff [Engineer (Definitive Map), Asset Strategy, Planning and Economic 
Regeneration, East Riding of Yorkshire Council] on 10th January 2013 that said 
"I am pleased to be able to tell you that a request from East Riding of 
Yorkshire Council for a derived data exemption in relation to its Public Rights 
of Way (PRoW) datasets has now been approved. As a consequence, the terms 
equivalent to OS OpenData (see 
http://www.ordnancesurvey.co.uk/oswebsite/opendata/docs/os-opendata-licence.pdf 
) may now also be applied to the dataset being released."

When I requested an update in 2014, I received a reply from Gordon Grimley 
[Assistant Engineer (Definitive Map), Asset Strategy (AS 67), Planning and 
Economic Regeneration, East Riding of Yorkshire Council] on 27th February 2014 
saying "Attached is the most recent copy of the shapefile.  All the same 
licences etc apply."

> I have asked Barry for his sources and there has been a stoney silence.

I don't normally ignore e-mails.  So maybe your e-mail didn't get to me.

> If anyone has used rowmaps as a source for OSM edits I would revert that edit.

Although I don't do the hard grind of adding to OSM, it has always been my view 
that's it's irrelevant as to what licence the data has been released with.  As 
others have pointed out in this thread, the data from www.rowmaps.com can best 
be used to identify a PROW that needs surveying: what's in the data may be 
quite different from what happens on the ground.  And this disclaimer that 
www.rowmaps.com shows alongside any map is also appropriate: "An authority's 
Definitive Map is the authoritative source of their rights of way. The details 
of the public rights of way network contained in an authority's data are for 
information only, and are an interpretation of the Definitive Map, not the 
Definitive Map itself, and should not be relied on for determining the position 
or alignment of any public right of way. For legal purposes, an authority's 
data does not replace their Definitive Map. And changes may have been made to 
the Definitive Map that are not included in their data."
-- 
Barry Cornelius
http://www.northeastraces.com/
http://www.oxonraces.com/
http://www.rowmaps.com/
http://www.thehs2.com/
http://www.oxonpaths.com/
http://www.barrycornelius.com/
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-fr] Contributeur du mois: Philippe Verdy

Bonsoir,

Dans notre série "Contributeur du mois" [1] nous avons une entrevue
avec Philippe Verdy:
http://www.openstreetmap.org/user/escada/diary/40120

m.

[1] 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Belgian_Mapper_of_the_Month

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Jean-Claude Repetto

Le 22/12/2016 à 15:40, JB a écrit :
> Salut Christian,
> Sacré boulot que tu fais là !
> Par contre, en zone rurale (mon dada), le rendu international a bien
> avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale
> : la réorganisation des tirets selon le tracktype serait très bienvenue,
> la progression actuelle étant incohérente pour le tracktype=grade4.
> JB.
> 

Bonjour,

En ce qui concerne les pistes(highway=track), je pense que la priorité
serait de leur donner une épaisseur, comme sur la carte
http://maps.refuges.info/ .
En effet, la représentation filaire actuelle est trompeuse et devrait
être réservée aux sentiers (highway=path).

Jean-Claude


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread JB


Salut Christian,
Sacré boulot que tu fais là !
Par contre, en zone rurale (mon dada), le rendu international a bien 
avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale 
: la réorganisation des tirets selon le tracktype serait très bienvenue, 
la progression actuelle étant incohérente pour le tracktype=grade4. 
(Sinon, le boulot fait sur les path/footway est intéressant aussi)
Voilà voilà, n'hésite pas à différencier encore un peu plus les locality 
des autres lieu-dits (j'aurais mis un coup de font-stretch ou son 
équivalent s'il existe sur mapnik sur les locality, par exemple).

JB.

Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
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

[OSM-talk-fr] site cadastre.openstreetmap.fr

2016-12-22 Thread Laurent Combe

A partir de ce site
http://cadastre.openstreetmap.fr/
ou de
http://cadastre.openstreetmap.fr/fantoir

je ne vois pas de lien vers les listes départementales (citées
récemment par nicolas)
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

àm on humble avis, ce serait un plus d'avoir à partir du site accès à
l'ensemble des outils disponibles (par un simple lien)

autre point
sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
lien vers le wiki mais qui pointe sur la page qui décrit l'historique
de nos relations avec la DgFiP

il manque à mon avis un lien vers la page du wiki : comment contribuer à la BANO
http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO


Laurent

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Florian LAINEZ

Bon boulot Christian, ravi de voir que le rendu avance.

Concernant le indoor tu dis que les objets en sous-sol ont disparus mais je
vois toujours la gare sous-terraine de Magenta ;)
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.88077/2.35857
Les données sont pourtant bien tagguées avec un level négatif.

Autre remarque : afficher les entrance sans visualiser les espaces
intérieurs, ça donne ça sur Montparnasse :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062

Tu remarqueras que je me plains sans apporter de solution !

sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
afficher

+1

Le 22 décembre 2016 à 13:11,  a écrit :

> Le 22/12/2016 à 02:53, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Le 21 décembre 2016 à 23:56,  a écrit :
>
> Niveau 11
>> 
>> :
>>
>> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
>> Lann-Bihoué mais sur Guidel-Plages.
>>
>
> ?? lien ??
>
> Voir ci-dessus !
> Tiens on pourrait ajouter B.A.N. en abréviation de Base d'aéronautique
> navale
>
>
>
>> Pourtant le nom déborde de la zone militaire.
>>
>
> ça , les noms peuvent déborder si la forme est très allongée. La taille du
> texte varie avec la surface du polygone, mais pas en prenant compte sa
> largeur et/ou hauteur.
>
> Sauf que pour Guidel-Plages il y a repliement de ligne et pas pour "Base
> d'aéronautique navale de Lann-Bihoué" qui est particulièrement long.
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
>> 740#17/48.38764/-4.46565
>>
>
> Difficile avec les voies à chaussées séparées. Ce sont deux lignes
> distinctes et pas facile de les fusionner en une seule...
>
> Bah, on va bien trouver quelqu'un pour nous pondre un schéma highway V2
> incompatible avec le précédent ;-).
> Mais en dessous la Rue de Kiel n'est pas à chaussée-séparée.
>
>
> Aller dans le détail des intersections comme tu le suggère n'est pas
> simple non plus... j'imagine la complexité des requêtes pour obtenir ces
> infos !
>
> Ne nous abaissons pas à un simple problème d'algorithmique :-D
> Oui, pour que ça marche bien il faut laisser le client afficher au moins
> la partie textuelle par un tuilage vectoriel.
>
> > Un polygone englobant toute l'emprise du collège est bien sûr la
> solution parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est une
> cour, un parking, des terrains de sport, etc... j'ai corrigé.
> Merci.
>
>
>
>> Rendu ou données incorrectes ?
>> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
>> 740#19/48.39896/-4.40997
>> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>>
>>
> Là je sèche...
>
> Beaucoup de considérations à celui ou celle qui trouvera !
>
> Au sud-ouest du rond-point : "Collège Priv. Diwan Penn ar Bed".
> Pourquoi cette abréviation qui ne fait guère gagner de place ? De plus la
> version "longue" tenait largement dans l'emplacement.
> Et en plus Diwan aurait bien aimé être public, mais c'est une autre
> histoire.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [OSM-talk-be] Belgium maxheight railway=level_crossing

On 22-12-16 14:19, Jakka wrote:
> Rechtzetting, deze opmerkingen tot plaatsen lijkt overbodig daar de wet
> in België bepaalt de de maximale lading in hoogte de 4 meter niet mag
> overschrijden. De ongevallen incidenten zijn oorzaak van nalatigheid
> kraan/laadbak omhoog en gebruik of lading normen.

Wettelijk oversized transport vind deze indicaties nog steeds handig om
te weten.

Maximale lading is idd wel 4 meter maar een brug is niet altijd vierkant
dus met te weten hoe hoog ze is het midden kunnen chauffeurs beter
inschatten of ze onder eventuele bogen kunnen rijden.  Vlak voor men
deur ligt zo een brug, daar is deze zomer nog tegen gereden.  Midden is
wel 4m hoog, maar aan de kanten niet.

> 
> Correction: semble superflu puisque la loi en Belgique, la charge ne
> doit pas dépasser la hauteur maximale de 4 mètres ces observations
> lieux. Les incidents sont des accidents causés par la négligence grue /
> camion et l'utilisation ou les normes de chargement.
> 
> Op 22/12/2016 om 11:31 schreef Jakka:
>> Hoi,
>> Naar aanleiding recent incident lijn Oudenaarde: Vrachtwagen rukt
>> bovenleiding af.(3)
>> Zouden we niet standaard voor België de maxheight op stukje highway
>> zetten op plaats van OW trein overweg met bovenleiding?
>> Moeilijker maar niet onmogelijk voor steden met tramleidingen ?(4)
>> Wiki (toevoeging?) is er geen sprake van maxheight aan overwegen waar
>> bovenleiding aanwezig is.(1)(1a)
>> Daar is standaard de hoogte beperkt om 4.5 meter controle portieken (2)
>>
>> (online translate)
>> En raison de l'incident récent à Oudenaarde:le caténaire arracher...(3)
>> Mettre standard le maxheigt en Belgique sur morceau highway sur le
>> passage a niveau qui à une ligne électrifié ?
>> Plus difficile mais faisable les rues avec tram?(4)
>> Les wikis (ajouter ?) rien trouver (1)(1a)
>> Le maxheight standard serai 4.5 m portiek de securité/controle (2)
>>
>> (1) http://wiki.openstreetmap.org/wiki/Key:maxheight
>> (1a) http://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
>> (2) Zie
>> https://www.infrabel.be/nl/chauffeurs-sensibiliseren-rond-afgerukte-bovenleidingen
>>
>>
>> (3)
>> http://www.hln.be/hln/nl/957/Binnenland/article/detail/3034585/2016/12/19/Truck-beschadigt-bovenleiding-geen-treinen-tussen-Kortrijk-en-Oudenaarde.dhtml
>>
>>
>> (4)
>> http://www.hln.be/hln/nl/957/Binnenland/article/detail/2624386/2016/02/22/Tramverkeer-in-Antwerpen-verstoord-door-losgerukte-bovenleiding.dhtml
>>
>>
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be


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

Re: [OSM-talk-be] Belgium maxheight railway=level_crossing

2016-12-22 Thread Jakka

Rechtzetting, deze opmerkingen tot plaatsen lijkt overbodig daar de wet 
in België bepaalt de de maximale lading in hoogte de 4 meter niet mag 
overschrijden. De ongevallen incidenten zijn oorzaak van nalatigheid 
kraan/laadbak omhoog en gebruik of lading normen.


Correction: semble superflu puisque la loi en Belgique, la charge ne 
doit pas dépasser la hauteur maximale de 4 mètres ces observations 
lieux. Les incidents sont des accidents causés par la négligence grue / 
camion et l'utilisation ou les normes de chargement.


Op 22/12/2016 om 11:31 schreef Jakka:

Hoi,
Naar aanleiding recent incident lijn Oudenaarde: Vrachtwagen rukt
bovenleiding af.(3)
Zouden we niet standaard voor België de maxheight op stukje highway
zetten op plaats van OW trein overweg met bovenleiding?
Moeilijker maar niet onmogelijk voor steden met tramleidingen ?(4)
Wiki (toevoeging?) is er geen sprake van maxheight aan overwegen waar
bovenleiding aanwezig is.(1)(1a)
Daar is standaard de hoogte beperkt om 4.5 meter controle portieken (2)

(online translate)
En raison de l'incident récent à Oudenaarde:le caténaire arracher...(3)
Mettre standard le maxheigt en Belgique sur morceau highway sur le
passage a niveau qui à une ligne électrifié ?
Plus difficile mais faisable les rues avec tram?(4)
Les wikis (ajouter ?) rien trouver (1)(1a)
Le maxheight standard serai 4.5 m portiek de securité/controle (2)

(1) http://wiki.openstreetmap.org/wiki/Key:maxheight
(1a) http://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
(2) Zie
https://www.infrabel.be/nl/chauffeurs-sensibiliseren-rond-afgerukte-bovenleidingen

(3)
http://www.hln.be/hln/nl/957/Binnenland/article/detail/3034585/2016/12/19/Truck-beschadigt-bovenleiding-geen-treinen-tussen-Kortrijk-en-Oudenaarde.dhtml

(4)
http://www.hln.be/hln/nl/957/Binnenland/article/detail/2624386/2016/02/22/Tramverkeer-in-Antwerpen-verstoord-door-losgerukte-bovenleiding.dhtml





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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2016-12-22 Thread Ha Noj

> Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
vlastně není a všichni jsou happy.
*** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám
vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !


Le 22/12/2016 à 02:53, Christian Quest - cqu...@openstreetmap.fr a écrit :

Le 21 décembre 2016 à 23:56, > a écrit :


Niveau 11


:

et sans doute ailleurs : pas de repliement de ligne sue la BAN de
Lann-Bihoué mais sur Guidel-Plages.


?? lien ??

Voir ci-dessus !
Tiens on pourrait ajouter B.A.N. en abréviation de Base d'aéronautique 
navale**



Pourtant le nom déborde de la zone militaire.


ça , les noms peuvent déborder si la forme est très allongée. La 
taille du texte varie avec la surface du polygone, mais pas en prenant 
compte sa largeur et/ou hauteur.
Sauf que pour Guidel-Plages il y a repliement de ligne et pas pour "Base 
d'aéronautique navale de Lann-Bihoué" qui est particulièrement long.




http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.38764/-4.46565




Difficile avec les voies à chaussées séparées. Ce sont deux lignes 
distinctes et pas facile de les fusionner en une seule...
Bah, on va bien trouver quelqu'un pour nous pondre un schéma highway V2 
incompatible avec le précédent ;-).

Mais en dessous la Rue de Kiel n'est pas à chaussée-séparée.


Aller dans le détail des intersections comme tu le suggère n'est pas 
simple non plus... j'imagine la complexité des requêtes pour obtenir 
ces infos !

Ne nous abaissons pas à un simple problème d'algorithmique :-D
Oui, pour que ça marche bien il faut laisser le client afficher au moins 
la partie textuelle par un tuilage vectoriel.


> Un polygone englobant toute l'emprise du collège est bien sûr la 
solution parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est 
une cour, un parking, des terrains de sport, etc... j'ai corrigé.

Merci.


Rendu ou données incorrectes ?

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39896/-4.40997


http://www.openstreetmap.org/#map=19/48.39886/-4.40977



Là je sèche...

Beaucoup de considérations à celui ou celle qui trouvera !

Au sud-ouest du rond-point : "Collège Priv. Diwan Penn ar Bed".
Pourquoi cette abréviation qui ne fait guère gagner de place ? De plus 
la version "longue" tenait largement dans l'emplacement.
Et en plus Diwan aurait bien aimé être public, mais c'est une autre 
histoire.


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

Re: [OSM-talk-fr] pulic_transport et rendu...

Nicolas, quand tu as fini avec l'Hérault, tu peux passer à un autre 
département ;-).


Je pense que Christian a voulu dire : si on a les deux informations, à 
un niveau où on ne voit pas les trottoirs, autant mettre un seul point 
pour les deux arrêts au niveau de la rue.


Sinon je suis d'accord avec vous : stop_position ne sert pas au grand 
public.


Jean-Yvon


Le 22/12/2016 à 10:21, Francescu GAROBY - windu...@gmail.com a écrit :
Je rejoins PanierAvide sur l'inversion stop_position/platform, pour la 
même raison que lui.
D'ailleurs, indiquer où le bus/tram/... s'arrête ne me paraît pas 
vraiment utile, sur une carte généraliste.


Francescu

Le 22 décembre 2016 à 10:06, PanierAvide > a écrit :


J'aurais inversé stop_position et platform, d'un point de vue
information usager c'est plus important de savoir où attendre
(platform) plutôt que où le bus va s'arrêter (stop_position).

Cordialement,

PanierAvide.


Le 22/12/2016 à 09:56, Christian Quest a écrit :

J'ai regardé plus en détail la logique du modèle public_transport
et comment en tirer le meilleur pour le rendu.

On a donc 4 objets (du plus général au plus fin):
- stop_area
- station
- stop_position
- platform

En fonction du niveau de zoom du rendu, on devrait pouvoir se
limiter à certains objets:
- station pour les premiers niveaux (pour n'avoir que les gares,
donc des sites importants)
- stop_area pour les zoom intermédiaires
- stop_position pour zoom élevés (en gros là où les arrêts de bus
commencent à être rendus)
- platform pour le/les tout derniers zoom de détail

Est-ce que ceci vous semble cohérent ?

Le problème ensuite est de trouver la cohérence avec les tags
"classiques".

-- 
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
 


--
Francescu

___
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] Building Detection using Machine Learning

and that makes a lot of sense.

Thanks John

On 21 December 2016 at 19:58, Frederik Ramm  wrote:

> Hi,
>
> On 12/22/2016 01:10 AM, john whelan wrote:
> > Do we have any guidelines in the wiki etc?
>
> Nothing specific, no.
>
> Automated editing and/or import guidelines would apply to any such
> process and I would ask everyone who overhears discussions about
> "uploading" machine-detected data to OSM to point this out to those
> discussing. We've already had to revert a couple hundred thousand such
> edits (roads though, not buildings).
>
> If, OTOH, an editor plugin were to help the mapper trace buildings that
> the mapper identifies or at least individually verifies, that would
> probably be ok, at least until HOT trains an army of monkeys with
> typewriters, er keyboards, to rubber-stamp everything the algorithm puts
> out ;)
>
> More generally speaking, in my opinion the human-centered aspect of
> mapping is a key property that sets us apart from other map databases.
> You can safely assume that any algorithm we can run to detect buildings,
> Google can run 1000 times faster and with a fraction of the error rate,
> leading to 1000 times more and 10 times better data of that kind than we
> can accumulate. This is not a field in which we can, or should attempt
> to, compete.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Nicolas Moyroud



J'aurais aimé caser ça avant Noël, mais de façon plus réaliste ce sera 
pour la rentrée.
Le petit papa Vincent sera donc un peu en retard par rapport à son 
homologue vêtu de rouge. Alors ce sera un cadeau de nouvelle année ! ;-)

J'ai d'autres trucs pour m'occuper de toute façon...

Nicolas

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Jérôme Amagat

Le 22 déc. 2016 03:03, "Christian Quest"  a écrit :

Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
écrit :

> on parle beaucoup des transport public en ce moment, ça serait bien que
> les arrets de bus, tram metro ... soit rendu qu'avec des tag
> public_transport= et aussi si ce n'est pas un node mais un way ou
> multipolygon.
>

>

Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
adopter un modèle bien complexe pour le contributeur lambda.


Oups, je me suis mal exprimé. Je voulais dire qu'il faudrait que les arrêts
qu'avec le nouveau schéma public transport soit rendu comme ceux avec les
plus anciens tags. Et oui garder le rendu pour les anciens tags.


Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
outils de QA comme osmose, pas avec un rendu assez généraliste.


Pour la prise en compte des polygones, je vais regarder ce qu'il est
possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
prendre en compte le schéma public_transport au niveau du rendu.

On met quoi sur le rendu ? public_transport=stop_position ou
public_transport=platform ?

Si on a un highway=bus_stop comment on évite d'avoir un doublon ?

Heureusement que postgis a maintenant de quoi générer des cluster... ça va
peut être être la solution: on met tout ensemble et on fait un cluster ;)

-- 
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

[OSM-talk-be] Belgium maxheight railway=level_crossing

2016-12-22 Thread Jakka


Hoi,
Naar aanleiding recent incident lijn Oudenaarde: Vrachtwagen rukt 
bovenleiding af.(3)
Zouden we niet standaard voor België de maxheight op stukje highway 
zetten op plaats van OW trein overweg met bovenleiding?

Moeilijker maar niet onmogelijk voor steden met tramleidingen ?(4)
Wiki (toevoeging?) is er geen sprake van maxheight aan overwegen waar 
bovenleiding aanwezig is.(1)(1a)

Daar is standaard de hoogte beperkt om 4.5 meter controle portieken (2)

(online translate)
En raison de l'incident récent à Oudenaarde:le caténaire arracher...(3)
Mettre standard le maxheigt en Belgique sur morceau highway sur le 
passage a niveau qui à une ligne électrifié ?

Plus difficile mais faisable les rues avec tram?(4)
Les wikis (ajouter ?) rien trouver (1)(1a)
Le maxheight standard serai 4.5 m portiek de securité/controle (2)

(1) http://wiki.openstreetmap.org/wiki/Key:maxheight
(1a) http://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
(2) Zie 
https://www.infrabel.be/nl/chauffeurs-sensibiliseren-rond-afgerukte-bovenleidingen
(3) 
http://www.hln.be/hln/nl/957/Binnenland/article/detail/3034585/2016/12/19/Truck-beschadigt-bovenleiding-geen-treinen-tussen-Kortrijk-en-Oudenaarde.dhtml
(4) 
http://www.hln.be/hln/nl/957/Binnenland/article/detail/2624386/2016/02/22/Tramverkeer-in-Antwerpen-verstoord-door-losgerukte-bovenleiding.dhtml

--
Met vriendelijke groeten,

Jakka


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

[Talk-de] 20 City-Zonen in Westfalen

2016-12-22 Thread Roland Olbricht


Hallo zusammen,

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


Ab August 2017 wird in Westfalen ein neuer Gemeinschaftstarif 
eingeführt. Um Fragen für die Zugänglichkeit als Open Data der 
Tarifzonen gleich im Ansatz zu lösen, überlegen die beteiligten Städte 
und Kreise bzw. Verkehrsunternehmen, die Geographie direkt in OSM 
einzutragen.


Bei den meisten der 300 Tarifzonen gibt es dazu nichts zu tun, weil sie 
mit den Gemeindegrenzen identisch sind. Rund 20 Tarifzonen weichen aber 
davon ab, entweder als Sammlung von Stadtteilen oder als Straßenliste. 
Details habe ich noch nicht.


Wir würden daher gerne den Sachbearbeitern eine Empfehlung zum Taggen 
geben. Bisher würde ich dazu neigen


- an bestehenden Gemeindegrenzen ein Tag "westfalentarif:zone"= 
zu ergänzen


- bei den 20 abweichenden Tarifgebieten jeweils ein Multipolygon 
möglichst unter Nutzung bestehender Grenz-Ways mit

-- type=boundary
-- boundary=public_transport
-- westfalentarif:zone=
anzulegen.

Zur Unterstützung der Themenstruktur für die Mailinglisten rege ich an, 
das auf der nahverkehr@-Liste zu diskutieren. Gerne kann jemand auch im 
Forum darauf hinweisen, dann böte es sich an, den Link hier zu posten.


Viele Grüße,

Roland (dienstlich)

--
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: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Vincent de Château-Thierry


Salut Nicolas et tous,

Le 22/12/2016 à 10:31, Nicolas Moyroud a écrit :


Tant qu'à signaler un petit souci dans les outils d'aide à la
contribution, j'en profite aussi au passage pour demander une
amélioration concernant l'outil "voies récentes manquantes"
(http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html).
Dans la liste par département, ça affiche les 50 occurrences les plus
récentes, mais on ne peut malheureusement pas naviguer vers la suite. Le
problème c'est que maintenant dans l'Hérault je suis presque à la fin de
la liste parce qu'il y a plein de rues que je n'ai jamais réussi à
trouver (même en cherchant beaucoup) et donc que je ne peux pas faire.
Donc je vais bientôt être bloqué. Si c'était possible de prévoir un
bandeau de navigation "page suivante / page précédente" ce serait super !


J'aurais aimé caser ça avant Noël, mais de façon plus réaliste ce sera 
pour la rentrée.


vincent

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Nicolas Moyroud


Salut,

Merci Christian pour ce travail de fou sur le rendu FR !

Une remarque qui n'est pas directement liée au rendu FR, mais plutôt à 
la couche "zones à mapper" sur tile fr. Il y a toujours des communes qui 
s'affichent avec le rond vert/bleu des bâtiments manquants alors qu'elle 
sont totalement renseignées en bati. Exemples :

http://tile.openstreetmap.fr/?zoom=15=43.73936=3.8602=B000TF
http://tile.openstreetmap.fr/?zoom=16=43.56325=3.28654=B000TF
http://tile.openstreetmap.fr/?zoom=15=43.62998=3.24387=B000TF
Le problème c'est que dans l'Hérault il ne reste plus beaucoup de 
communes à faire. Du coup, avec tout ce bruit la couche n'aide plus à 
savoir où il reste vraiment du travail...


Tant qu'à signaler un petit souci dans les outils d'aide à la 
contribution, j'en profite aussi au passage pour demander une 
amélioration concernant l'outil "voies récentes manquantes" 
(http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html).
Dans la liste par département, ça affiche les 50 occurrences les plus 
récentes, mais on ne peut malheureusement pas naviguer vers la suite. Le 
problème c'est que maintenant dans l'Hérault je suis presque à la fin de 
la liste parce qu'il y a plein de rues que je n'ai jamais réussi à 
trouver (même en cherchant beaucoup) et donc que je ne peux pas faire. 
Donc je vais bientôt être bloqué. Si c'était possible de prévoir un 
bandeau de navigation "page suivante / page précédente" ce serait super !


Nicolas


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

Re: [OSM-talk-fr] pulic_transport et rendu...

2016-12-22 Thread Francescu GAROBY

Je rejoins PanierAvide sur l'inversion stop_position/platform, pour la même
raison que lui.
D'ailleurs, indiquer où le bus/tram/... s'arrête ne me paraît pas vraiment
utile, sur une carte généraliste.

Francescu

Le 22 décembre 2016 à 10:06, PanierAvide  a écrit :

> J'aurais inversé stop_position et platform, d'un point de vue information
> usager c'est plus important de savoir où attendre (platform) plutôt que où
> le bus va s'arrêter (stop_position).
>
> Cordialement,
>
> PanierAvide.
>
> Le 22/12/2016 à 09:56, Christian Quest a écrit :
>
> J'ai regardé plus en détail la logique du modèle public_transport et
> comment en tirer le meilleur pour le rendu.
>
> On a donc 4 objets (du plus général au plus fin):
> - stop_area
> - station
> - stop_position
> - platform
>
> En fonction du niveau de zoom du rendu, on devrait pouvoir se limiter à
> certains objets:
> - station pour les premiers niveaux (pour n'avoir que les gares, donc des
> sites importants)
> - stop_area pour les zoom intermédiaires
> - stop_position pour zoom élevés (en gros là où les arrêts de bus
> commencent à être rendus)
> - platform pour le/les tout derniers zoom de détail
>
> Est-ce que ceci vous semble cohérent ?
>
> Le problème ensuite est de trouver la cohérence avec les tags "classiques".
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] osmose et adresses bis

2016-12-22 Thread Philippe Verdy

La seule raison réglementaire qui vaille c'est pour le fisc: il taxe
séparément les propriétés/copropriétés (pour la taxe foncière) et les
résidents individuels (taxes locatives, redevance télé). Les collectivités
en général taxent la copropriété concernant le ramassage des ordures
ménagères ou l'assainissement, et c'est la copro qui refecture les
résidents dans leurs charges sur la base des quantièmes.

La loi obligeant maintenant d'avoir des compteurs individuels pour l'eau et
l'énergie, les résidents sont identifiés séparément de la copropriété pour
leurs propre consommation. Cependant la copropriété peut encore être
facturée de l'ensemble, les résidents payant ensuite leur consommation
propre dans leurs charges. Mais souvent ils demandent de pouvoir choisir
leur fournisseur d'énergie, et dans ce cas l'électricité ou le gaz sont
séparés (il y a encore des consommations partagées dans les charges
concernant les parties communes ou l'eau utilisée pour l'entretien des
parties communes ou des extérieurs).

Mais ces infos d'individualisation sont des infos privées liant les
résidents à leur fournisseur (et indirectement au réseau de distribution)
et ne sont pas des données publiques qu'on peur utiliser dans OSM. Il ne
reste donc que les numéros de portes des résidents professionnels disposant
d'un accueil du public (commerces, cabinets médicaux et services divers),
dont on connaitre le numéro de porte uniquement parce qu'ils le publient ou
parce qu'on peut aller le voir sur place. Mais on ne verra pas ça dans le
cadastre.


Le 21 décembre 2016 à 19:19, Christian Quest  a
écrit :

> Un peu d'explication: Rennes Métropole différencie en fait la notion
> d'adresse et de bâtiment aussi pour une raison réglementaire très simple:
> - les numéros d'adresses (y compris bis/ter) sont attribué officiellement
> par le maire de la commune
> - les autres extensions (A/B/C/D pour différencier des bâtiments) ne sont
> pas forcément attribuées par le maire.
>
> Est-ce que des A/B/C/D sont attribués par des maires ? OUI, aussi, donc on
> ne peut pas généraliser ce qui se fait à Rennes.
>
> Il n'y a aucun règle en la matière, malheureusement.
>
>
> Le 21 décembre 2016 à 16:50, Julien Lepiller  a écrit :
>
>> Bon, ça ne m'avance pas tellement tout ça... Si je comprends bien, il n'y
>> a pas de consensus concernant l'espace ou non. Concernant l'import depuis
>> les données de Rennes Métropole, il faudrait le corriger pour qu'il inclue
>> aussi les lettres (A, B, ...) des bâtiments. Dans l'immédiat, est-il
>> possible de rendre osmose insensible aux espaces dans le numéro ?
>>
>> En parlant d'adresses en double et d'anecdote, je connais un cas où
>> plusieurs bâtiments distincts ont la même adresse postale.
>> https://www.openstreetmap.org/way/269025821 et
>> https://www.openstreetmap.org/way/26902 sont tous les deux situés au
>> 420, chemin des chaussièyes ainsi que les bâtiments voisins. Ce n'est
>> d'ailleurs même pas le nom du chemin auquel ces bâtiments sont rattachés,
>> mais d'un autre plus loin. Les boîtes aux lettres sont toutes regroupées
>> plus loin, au niveau du croisement entre le chemin du Pélissier et le
>> chemin sans nom qui donne à ces maisons. Comment devrais-je m'y prendre
>> pour ajouter ces adresses ? Un point par maison, ou un seul point au niveau
>> des boîtes aux lettres ?
>>
>> Le 2016-12-21 16:07, Mathias Jérôme a écrit :
>>
>>> Bien sûr des contre exemples il y aura à la pelle..j'énonçais
>>> seulement des généralités et on aura aussi les 10-1 , 10-2 , 10-3 ,
>>> 10-4 à la place de ce que voulez.
>>> Ce qui est sûr c'est que c'est de la numérotation dans tous les cas,
>>> ce qui plaide pour le mettre tout ce qui est numérotation avec la
>>> numérotation (ou dans le même "mot" ce qui reviens au même).
>>>
>>> -
>>>  DE : Florian_G 
>>> À : Discussions sur OSM en français 
>>> ENVOYÉ LE : Mercredi 21 décembre 2016 14h20
>>> OBJET : Re: [OSM-talk-fr] osmose et adresses bis
>>>
>>> Hello,
>>>
>>> Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :
>>>
>>> Les bis, ter etc... sont des indices de répétitions, mais les
 A,B,C etc... sont plutôt ce que j'appellerais des indices de
 déclinaisons (dans le cas du 36bis c'est que le 36 existe (ou
 existait) et est (était)  vraiment distinct, tandis que le 36A il
 est souvent situé au situé au 36, de même que le 36B se situera
 aussi au 36 , de fait les A,B,C,etc... sont souvent de la
 numérotation d'ordre "privative" : accès ou cages d'escaliers).

>>>
>>> Petit contre-exemple :
>>>
>>> *
>>> OSM :
>>> http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980
>>> * Google :
>>> https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.2
>>> 6h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!7i1
>>> 3312!8i6656!6m1!1e1
>>>
>>> Ce 13 A aurait pu être un 13 bis, mais c'est bien un 13 A,

Re: [OSM-talk-fr] pulic_transport et rendu...

J'aurais inversé stop_position et platform, d'un point de vue 
information usager c'est plus important de savoir où attendre (platform) 
plutôt que où le bus va s'arrêter (stop_position).


Cordialement,

PanierAvide.


Le 22/12/2016 à 09:56, Christian Quest a écrit :
J'ai regardé plus en détail la logique du modèle public_transport et 
comment en tirer le meilleur pour le rendu.


On a donc 4 objets (du plus général au plus fin):
- stop_area
- station
- stop_position
- platform

En fonction du niveau de zoom du rendu, on devrait pouvoir se limiter 
à certains objets:
- station pour les premiers niveaux (pour n'avoir que les gares, donc 
des sites importants)

- stop_area pour les zoom intermédiaires
- stop_position pour zoom élevés (en gros là où les arrêts de bus 
commencent à être rendus)

- platform pour le/les tout derniers zoom de détail

Est-ce que ceci vous semble cohérent ?

Le problème ensuite est de trouver la cohérence avec les tags 
"classiques".


--
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: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

2016-12-22 Thread Francescu GAROBY

Je trouve moi aussi que c'est très bien, cette estompe pour les choses
"souterraines" !
1 remarque toutefois : le rendu d'une voie souterraine n'a pas la même
couleur, selon que le bâtiment en surface a des murs ou pas ! Cf. la voie
souterraine, à coté du texte "Communauté d'agglomération Caen-la-Mer"
.
Je me rends bien compte que cela doit être dû à la couleur de la zone sans
mur "qui est l'allée principale de la galerie commerciale), mais du coup,
ça fait ressortir un tronçon...

Autre remarque : les entrées (entrance=main) ont un rendu qui n'est pas
clair : un simple point noir.



Francescu

Le 22 décembre 2016 à 09:51, PanierAvide  a écrit :

> Youpi, le premier rendu à considérer un minimum les objets indoor est le
> rendu FR :-) C'est pas mal l'idée d'estomper, moins agressif que le binaire
> afficher/cacher, tout en cachant quand même un peu ces objets qui ne sont
> pas au niveau du sol.
>
> Ce serait également pertinent d'adapter le rendu pour les routes/chemins
> avec un level > 0 (à voir si c'est faisable), exemple du parking aérien sur
> 2 niveaux :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.08312/-1.67948
>
> Cordialement,
>
> PanierAvide.
>
> Le 21/12/2016 à 19:45, Christian Quest a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] osmose et adresses bis

2016-12-22 Thread Philippe Verdy

Plusieurs batiments à la même adresse postale (et cadastrale... mais pas
forcément fiscale!) ça s'appelle une résidence et c'est pour des
copropriétés. Elles ont alors leur propre numérotation interne des
résidents avec des numéros de portes, noms ou lettres de
batiments/escaliers/halls.

Pour la base adresse ces diférents points sont des assignations privées,
qui ne seront pas dans la base BANO qui ne connaitra que le numéro
postal/cadastral.

Le fisc cependant a besoin d'identifier les résidents et utilise alors les
autres indications: numéro d'appartement/porte, batiment/escalier/hall,
étage.

Mais en général on trouve presque toujours un numéro de porte/appartement,
lequel figure aussi sur les boites à lettres individuelles souvent (mais
pas toujours) regroupées au même endroit pour la même adresse postale
(certaines résidences regroupent les boites hall d'entrée par hall, la
numérotation interne de la résidence assigne des tranches de numéros
d'appartement selon le hall, souvent par centaines, les étages numérotant
les portes par dizaines et tout le monde s'y retrouve sans même avoir à
utiliser sur les adresses postales les noms/lettres d'immeubles ou halls
d'entrée...).

Ces numérotations étant privées, internes à la résidence/copropriété, ne
devraient même pas être dans OSM, sauf s'il y a un accès public (par
exemple pour géolocaliser un cabinet médiacal installé dans la résidence et
accessible aux visiteurs à ses heures d'ouverture. Mais on ne cartographie
pas directement les autres résidences privées non accessibles au public.
S'il y a un pas de porte commercial accessible en périphérie de la
copropriété avec son accès distinct, il suffit de mettre le POI mais il
n'est pas nécessaire du tout d'indiquer le numéro de porte privé: le seul
point d'adresse commun à la copro suffit.

S'il y a des cheminements accessibles au public (parkings privés, allées
piéton) on peut les mettre tout en indiquant que ce sont des accès privés
(ne pas oublier les restrictions): highway=service + service=alley par
exemple pour les accès en véhicule, et access=private (il peut y avoir
aussi un portail à ajouter, ouvert en journée mais fermé le soir ou le
week-end avec un automate pour l'ouvrir uniquement par les résidents.

Situation comparable à celle de nombre de centres commerciaux ou de
stations service (qui cependant ont rarement un portail, d'autant plus que
la plupart des stations ont des pompes automatiques 24/24 qui restent
ouvertes la nuit quand la station est fermée (paiement par CB uniquement
avec autorisation préalable avant de pouvoir se servir, et souvent avec une
télésurveillance qui détecte et photographie les véhicules ou piétons qui
entrent dans la zone privée de la station, la télésurveillance devant être
légalement signalée par un affichage près des pompes, et destinée à
prévenir des actes de malveillance).



Le 21 décembre 2016 à 16:50, Julien Lepiller  a écrit :

> Bon, ça ne m'avance pas tellement tout ça... Si je comprends bien, il n'y
> a pas de consensus concernant l'espace ou non. Concernant l'import depuis
> les données de Rennes Métropole, il faudrait le corriger pour qu'il inclue
> aussi les lettres (A, B, ...) des bâtiments. Dans l'immédiat, est-il
> possible de rendre osmose insensible aux espaces dans le numéro ?
>
> En parlant d'adresses en double et d'anecdote, je connais un cas où
> plusieurs bâtiments distincts ont la même adresse postale.
> https://www.openstreetmap.org/way/269025821 et
> https://www.openstreetmap.org/way/26902 sont tous les deux situés au
> 420, chemin des chaussièyes ainsi que les bâtiments voisins. Ce n'est
> d'ailleurs même pas le nom du chemin auquel ces bâtiments sont rattachés,
> mais d'un autre plus loin. Les boîtes aux lettres sont toutes regroupées
> plus loin, au niveau du croisement entre le chemin du Pélissier et le
> chemin sans nom qui donne à ces maisons. Comment devrais-je m'y prendre
> pour ajouter ces adresses ? Un point par maison, ou un seul point au niveau
> des boîtes aux lettres ?
>
> Le 2016-12-21 16:07, Mathias Jérôme a écrit :
>
>> Bien sûr des contre exemples il y aura à la pelle..j'énonçais
>> seulement des généralités et on aura aussi les 10-1 , 10-2 , 10-3 ,
>> 10-4 à la place de ce que voulez.
>> Ce qui est sûr c'est que c'est de la numérotation dans tous les cas,
>> ce qui plaide pour le mettre tout ce qui est numérotation avec la
>> numérotation (ou dans le même "mot" ce qui reviens au même).
>>
>> -
>>  DE : Florian_G 
>> À : Discussions sur OSM en français 
>> ENVOYÉ LE : Mercredi 21 décembre 2016 14h20
>> OBJET : Re: [OSM-talk-fr] osmose et adresses bis
>>
>> Hello,
>>
>> Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :
>>
>> Les bis, ter etc... sont des indices de répétitions, mais les
>>> A,B,C etc... sont plutôt ce que j'appellerais des indices de
>>> déclinaisons (dans le cas du 36bis c'est que le 36 existe (ou
>>> existait) et

Re: [talk-au] When is a road, not a road?

2016-12-22 Thread Warin


On 22-Dec-16 05:19 PM, Sam Wilson wrote:

I've found that there are quite a few MRWA road centre-lines that bear
no relation to where the actual road is. Usually because there are big
lumps of granite in the way, or quarries, or other physical reasons to
re-route the road. (I guess the road-builders don't tell MRWA that they
changed things?)


Humm these might be 'private' roads - e.g. constructed by a mining company for 
their use.
So they might be highway=unclassified etc but access=private.




But yeah, I'm taking MRWA's geometries as a guide only, and certainly
not assuming their data is 100% complete. :-) So, I'd assume that any
non-track highway that is in OSM but not in MRWA is as-currently-mapped,
and leave it be.

Also, around towns there are often MRWA residential roads with names and
classifications etc. but which haven't actually (yet) been built. These
are sometimes currently firebreaks, but sometimes just scrub.


Similar problems occurs with the LPI base map ...
though sometimes I think that the LPI base map might be more up to date than 
the satellite imagery:-\
Generally I leave these out as they may not exist yet. If you can see them as 
firebreaks then you could enter them as tracks.



:-)

Of course, really what we should do it get out there for some
ground-truthing to solve these questions! :-)


Yes. Thought there is rather a lot of ground to cover8-)



—Sam

On Thu, 22 Dec 2016, at 01:11 PM, Andrew Davidson wrote:

The metadata says that it includes roads maintained by Main Roads and
"all roads controlled by Local Government (Local Roads) that are
assigned road numbers", which is great. It also has "other centreline is
also included for paths and unknown roads" which is a bit vague as to
how complete the data set is. What do the missing roads look like on
aerial imagery?

On 22/12/16 16:06, Warin wrote:

On 22-Dec-16 03:59 PM, Warren wrote:

I suspect the answer to this question  is simple.

Following Sam Wilson's post about the data sources available for
Western Australian Roads, and using Sam's approach I have begun adding
and checking road names in WA.  In  the area that I am currently
working there are a number of named "roads" on  OSM (usually Highway:
unclassified), that do not appear on the Main roads data.

If a road is not on the Main roads database does it automatically
become a named track (Highway: Track)?

I'd leave it alone... someone thinks otherwise ... contact them for
their view.

The 'Main roads database' may not include roads maintained by local
councils ... that does not make them OSM 'highway=track'.

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

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

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




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

[OSM-talk-fr] pulic_transport et rendu...

2016-12-22 Thread Christian Quest

J'ai regardé plus en détail la logique du modèle public_transport et
comment en tirer le meilleur pour le rendu.

On a donc 4 objets (du plus général au plus fin):
- stop_area
- station
- stop_position
- platform

En fonction du niveau de zoom du rendu, on devrait pouvoir se limiter à
certains objets:
- station pour les premiers niveaux (pour n'avoir que les gares, donc des
sites importants)
- stop_area pour les zoom intermédiaires
- stop_position pour zoom élevés (en gros là où les arrêts de bus
commencent à être rendus)
- platform pour le/les tout derniers zoom de détail

Est-ce que ceci vous semble cohérent ?

Le problème ensuite est de trouver la cohérence avec les tags "classiques".

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !