Re: [OSM-talk-fr] Cartes papiers (A3/A2) avec ajout données locales : suites logicielles et conseils

[Etienne Trimaille]

Il y a déjà plusieurs essais dans le rendu topo :
* https://opentopomap.org
* Par makina corpus : https://github.com/makinacorpus/osm-topo
* Un projet perso que j'avais commencé, mais je n'ai plus le temps en ce
moment : https://github.com/Gustry/osm-topo basé sur sur le style
OSM-Bright https://github.com/mapbox/osm-bright
* et d'autres sur le net ...

Le 2 mai 2016 à 20:42, Valentin Surrel  a écrit :

> Bon, après mûre réflexion, je pense partir :
>
> - Maperitive/R25 pour commencer et avoir un résultat plutôt bon à
> relativement court terme.
>
> - Tweaker un style Mapnik pour converger dans N mois à un rendu proche de
> la solution Maperitive/R25
>
> Pourqoi ? J'aime bien avoir le contrôle de ma chaîne de production de
> manière intégrale. La pérennité de composant comme Maperitive étant
> aléatoire (tout comme les briques Mapbox CartoCSS/TileMill), je vais donc
> me restreindre à des composants éprouvés et opensource.
>
> L'idée étant d'arriver, un jour peut-être, à un francetopo-like mais avec
> le style en licence ouverte.
>
> Bougez pas, je reviens dans 24 mois :D
>
> A+
>
> Valentin
>
> Le 2016-05-01 12:51, JB a écrit :
>
>> - Point vectoriel : les retours que j'ai de mapnik indiquent des
>> fichiers très difficilement utilisables. Maperitive semble faire un
>> peu mieux. De mon coté, le petit imprimeur avec qui j'avais bossé une
>> petite fois me disait qu'au-dessus de 300-400dpi (natif au format), il
>> n'avait pas forcément d'intérêt à passer au vectoriel (par contre, il
>> a des clients qui récupèrent une image sur internet et la modifient
>> pour arriver à 300dpi… et arrivent avec un fichier qui fait 3 ou 4
>> centimètres de coté). Du coup, je t'encourage de regarder ce que ça
>> peut donner sous Inkscape, je suis intéressé par tes retours. (Et au
>> fait, quels travail vas-tu faire sous Inkscape ?)
>>
>> - Malgré la libération de .NET par Microsoft, les bibliothèques
>> graphiques n'avaient pas encore été intégrées par Mono. Je ne sais pas
>> si ça a évolué, mais les exports sous Linux étaient d'assez mauvaise
>> qualité sur les rendus de couleurs et de transparences (voir notamment
>> les éléments rouges touristiques).
>>
>> - Quelqu'un avait abordé l'idée de passer R25 en CSS, je lui avais dit
>> que j'étais curieux du boulot que ça donnerait mais le projet semble
>> avoir été abandonné depuis longtemps. R25, c'est actuellement plus de
>> 5000 lignes, sous une syntaxe très différente du CSS… donc du boulot,
>> du boulot. L'idée avait été évoquée de monter un petit serveur pour
>> produire des cartes à la demande, mais comme je n'ai pas les
>> compétences et qu'on n'avait pas monté d'équipe, c'est resté au stade
>> de l'idée. (Et de mon coté, je ne coderai pas le style en carto-CSS
>> pour diverses raisons).
>>
>> JB.
>>
>>
> ___
> 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] Fwd: [OSM-talk] Upcoming Planned outage - 9th May 2016

[Marc Gemis]

-- Forwarded message --
From: Grant Slater 
Date: Mon, May 2, 2016 at 10:46 PM
Subject: [OSM-talk] Upcoming Planned outage - 9th May 2016
To: Talk Openstreetmap , OSM Dev List
, annou...@openstreetmap.org


Hi All,

On the 9th of May 2016 the primary OpenStreetMap database will be
read-only for important maintenance. Editing the map will not be
possible during the maintenance.

Full announcement is available here:
https://blog.openstreetmap.org/2016/05/02/planned-server-outage-9th-may/

The Operations Working Group are in the process of planning some
hardware moves as a result of maintenance at our primary datacentre.
The plans are subject to change, but these moves are expected to take
place on Monday 9th May (a week from today), and this will mean a
period of read only operation lasting for up to 24 hours (into
Tuesday).

The read-only period will mean the OpenStreetMap website and map is
still available, but no map editing will be possible during this time.

The https://wiki.openstreetmap.org/wiki/2016_May_server_maintenance
wiki page has some more technical details, and will be updated with
more precise timing information as the plans are finalised in the
coming days.

We’re putting out this announcement to give some advanced notice, but
we appreciate some people will be wanting to know more about the exact
timings of the read-only period. Please have patience. The Operations
Working Group are busy making plans, and will aim to firm things up in
the coming days.

Kind regards,

Grant

on behalf of the OSM operations team

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

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

Re: [Talk-cz] Stromy pod kontrolou

[Marián Kyral]

Tak v pointinfu s dalšími moduly počítám, takže stačí, když bude někde web 
servis, který dodá požadovaná data.
Případně na to ještě navázána nějaká vizualizační vrstva, aby člověk věděl, 
kam má smysl klikat.

Marián


-- Původní zpráva --
Od: Michal Pustějovský 
Komu: OpenStreetMap Czech Republic 
Datum: 2. 5. 2016 23:18:17
Předmět: Re: [Talk-cz] Stromy pod kontrolou

"Já bych byl pro 'klikátko' na styl PointInfa, které by umělo doplnit 
informace jako třeba typ porostu. Geometrii bych nechal na pokoji, do jisté 
míry ji opravil lpis import a ruční úpravy.

Michal

2. května 2016 20:25:04 CEST, jzvc  napsal:
>Cus
>
>Dne 1.5.2016 v 9:25 Pavel Machek napsal(a):
>> Ahoj!
>>
>>> Takže se vás chci zeptat:
>>> * v jakém formátu by to pro nás bylo nejlepší?
>>> * zda ta data co jsem napsal stačí? - za mě bych přidal výšku a
>průměr
>>> * něco jiného co by vás napadlo?
>>
>> Listnaty/jehlicnaty?
>>
>> Jinak...
>>
>> Nebyl by cas udelat znovu (a lip) import lesu? Mensi generalizace,
>> importovat informaci listnaty/jehlicnaty...
>>
>> Pavel
>>
>
>Byl bych velice opatrny s jakymkoli re-importem. Znicis tim spousty 
>prace. Mozna tak v podobe traceru a vizualni kontroly. Vsichni vime jak
>
>"kvalitni" data nase stat(d?)ni sprava (ne)spravuje ...
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz

-- 
Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím 
moji stručnost.

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

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Gerald Weber]

Tenho objeção a conduzir a votação desta maneira, isto é uma votação
induzida.

Nenhuma das duas alternativas que foram propostas refletem o meu
entendimento sobre o assunto.

Primeiro temos que definir cenários que resumem o entendimento do grupo e
as suas consequências. Não cabe votar uma pergunta específica fora de
contexto.

Gerald
On 2 May 2016 09:22, "Leonardo Brondani Schenkel" 
wrote:

> Alguns voluntários da comunidade OSM Brasil (entre eles o autor desta
> votação) têm defendido na lista talk-br que o uso de
> `boundary=administrative` para as mesorregiões e microregiões criadas pelo
> IBGE não é apropriado, já que tais regiões têm fins apenas estatísticos e
> não administrativos; usar `boundary=administrative` para regiões que não
> são administrativas vai contra a definição e a intenção da tag.
>
> A discussão aconteceu em abril de 2006 sob o tópico de "Limites de cidades
> com distritos", arquivada em:
> https://lists.openstreetmap.org/pipermail/talk-br/2016-April/thread.html
>
> O objetivo desta votação é apenas para sondar o posicionamento da lista
> talk-br, do fórum brasileiro e portanto da comunidade OSM como um todo
> sobre esta questão. Caso haja um certo consenso que a representação não é
> apropriada, o próximo passo será a escrita de uma ou mais propostas formais
> de representação alternativa que não utilizem `boundary=administrative` e
> que serão apresentadas/discutidas na lista e colocadas em votação.
>
> O que está em votação aqui é __única e exclusivamente__ se é apropriado o
> uso do `boundary=administrative` para as regiões do IBGE. Outros assuntos
> relacionados que foram mencionados na lista __não__ estão no escopo desta
> votação, entre eles:
>
> - como representar sub-distritos
> - como representar distritos
> - como representar bairros
> - como representar regiões (N/NE/CO/SE/S)
> - se o Brasil deve ter 10 ou 11 valores para `admin_level`
> - se os limites/bordas em si estão corretos
>
> Em especial, esta votação __também não__ está propondo nenhuma solução
> específica nem uma alteração imediata de qualquer natureza nos dados.
>
> Estas são justificativas que foram apresentadas na lista talk-br para
> colocar a questão em votação:
>
> - As mesorregiões e microregiões do IBGE são apenas estatísticas e não têm
> função administrativa, conforme páginas do próprio governo [1] e [2],
> conforme o relato (de segunda mão) da opinião de um membro da comunidade
> que é funcionário do próprio IBGE [3], e conforme o mapa político (cuja
> função é mostrar as divisões administrativas) do próprio IBGE [4]. Outro
> voluntário na lista talk-br citou a própria publicação do IBGE em 1989 que
> criou as divisões [5], onde se menciona a função estatística e não há
> menção da função administrativa. Além disso, ninguém na lista até o momento
> aparesentou um exemplo de mapa político/rodoviário (online ou não) onde
> tais regiões estão representadas.
>
>   [1]
> http://metadados.ana.gov.br/geonetwork/srv/pt/metadata.show?id=68=simple
> :
>
>   > As microrregiões integram a organização, o planejamento e a execução de
>   > funções públicas de interesse comum, definidas por lei complementar
>   > estadual. Entretanto, raras são as microrregiões assim definidas.
>   > Consequentemente, o termo é muito mais conhecido em função de seu uso
>   > prático pelo IBGE que, para fins estatísticos e com base em
>   > similaridades econômicas e sociais, divide os diversos estados da
>   > federação brasileira em microrregiões.
>
>   [2]
> http://www.geografia.seed.pr.gov.br/modules/galeria/detalhe.php?foto=1586=8
> :
>
>   > Mesorregião é uma subdivisão dos estados brasileiros que congrega
>   > diversos municípios de uma área geográfica com similaridades econômicas
>   > e sociais, que por sua vez, são subdivididas em microrregiões. Foi
>   > criada pelo IBGE e é utilizada para fins estatísticos e não constitui,
>   > portanto, uma entidade política ou administrativa.
>
>   [3]
> https://lists.openstreetmap.org/pipermail/talk-br/2016-April/011302.html:
>
>   > Estive conversando com um exímio mapeador aqui do OSM BR, que também
>   > trabalha no IBGE. No entender dele e conforme seus conhecimentos na
>   > área, micro e meso não são administrativos. Mas essa é a opinião dele.
>   > Ele também concorda que subdistritos são sim níveis administrativos.
>
>   [4]
> ftp://geoftp.ibge.gov.br/mapas_tematicos/mapas_murais/Brasil2500_2014/
>
>   [5]
> https://lists.openstreetmap.org/pipermail/talk-br/2016-April/011310.html
>
> - A documentação do `boundary=administrative` explica que o mesmo foi
> criado para representar limites __administrativos__ apenas [1], como diz
> claramente o primeiro parágrafo:
>
>   [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative:
>
>   > An administrative boundary. Subdivisions of
> areas/territories/jurisdictions
>   > recognised by governments or other organisations for administrative
> purposes.
>   > [Um limite administrativo. 

Re: [Talk-gb-westmidlands] Next meeting: Atherstone

[Rob Nickerson]

Thursday works better for me too so let's go for that.

Do we have mapping properties? Location for food/drinks?

Rob
On 27 Apr 2016 11:47 a.m., "Brian Prangle"  wrote:

> I can only do Thursday
>
> On 26 April 2016 at 23:12, Rob Nickerson 
> wrote:
>
>> Hi all,
>>
>> The next Midlands meeting is at Atherstone. Normally this would be
>> Wednesday 4th May however we have an opportunity to move this to the
>> Thursday 5th May.
>>
>> If you are hoping to join us in Atherstone can you please reply with your
>> preferred date.
>>
>> Rob
>>
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
>>
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Sérgio V .]

Obrigado Wille, vou testar esta calculadora no QGIS,

valeu!


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

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

[OSM-co] Nuevas imágenes Mapbox

[hyan...@gmail.com]

Hola maperos!

Recientemente fueron adicionadas nuevas imágenes de Mapbox

https://www.mapbox.com/blog/three-million-km/?utm_source=may_newsletter_medium=email_content=satellite_campaign=may_newsletter

Aunque la mayoría para latitud norte; vale la pena chequear en sus áreas.

Saludos,

Humberto Yances
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[Talk-de] beschränkte Verfügbarkeit OSM-Server voraussichtlich am 9.5.

[Frederik Ramm]

Hi,

   auf der talk-Liste wurde gerade angekündigt, dass voraussichtlich am
9.5. der Haupt-Datenbank-Server readonly sein wird. Details hier

https://blog.openstreetmap.org/2016/05/02/server-wartungsarbeiten-am-9-mai-geplant/?lang=de

Bye
Frederik

PS Sind hier gestern und heute wirklich keine Postings gekommen, oder
ist die Liste nun doch von den Forengnomen sabotiert ;)

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

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

Re: [Talk-cz] Stromy pod kontrolou

[Michal Pustějovský]

Já bych byl pro 'klikátko' na styl PointInfa, které by umělo doplnit informace 
jako třeba typ porostu. Geometrii bych nechal na pokoji, do jisté míry ji 
opravil lpis import a ruční úpravy.

Michal

2. května 2016 20:25:04 CEST, jzvc  napsal:
>Cus
>
>Dne 1.5.2016 v 9:25 Pavel Machek napsal(a):
>> Ahoj!
>>
>>> Takže se vás chci zeptat:
>>>* v jakém formátu by to pro nás bylo nejlepší?
>>>* zda ta data co jsem napsal stačí? - za mě bych přidal výšku a
>průměr
>>>* něco jiného co by vás napadlo?
>>
>> Listnaty/jehlicnaty?
>>
>> Jinak...
>>
>> Nebyl by cas udelat znovu (a lip) import lesu? Mensi generalizace,
>> importovat informaci listnaty/jehlicnaty...
>>
>>  Pavel
>>
>
>Byl bych velice opatrny s jakymkoli re-importem. Znicis tim spousty 
>prace. Mozna tak v podobe traceru a vizualni kontroly. Vsichni vime jak
>
>"kvalitni" data nase stat(d?)ni sprava (ne)spravuje ...
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz

-- 
Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji 
stručnost.

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

[OSM-talk-ie] Registration is Now Open for State of the Map!

[Rob Nickerson]

Hi all,

Tickets for State of the Map 2016 are now on sale. Get yours before the
price goes up (to EUR 100)!

https://blog.openstreetmap.org/2016/05/02/registration-is-now-open-for-state-of-the-map/

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

[Talk-gb-westmidlands] Registration is Now Open for State of the Map!

[Rob Nickerson]

Hi all,

Tickets for State of the Map 2016 are now on sale. Get yours before the
price goes up (to EUR 100)!

https://blog.openstreetmap.org/2016/05/02/registration-is-now-open-for-state-of-the-map/

Best,
*Rob*
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-GB] Registration is Now Open for State of the Map!

[Rob Nickerson]

Hi all,

Tickets for State of the Map 2016 are now on sale. Get yours before the
price goes up (to EUR 100)!

https://blog.openstreetmap.org/2016/05/02/registration-is-now-open-for-state-of-the-map/

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

[OSM-talk] Upcoming Planned outage - 9th May 2016

[Grant Slater]

Hi All,

On the 9th of May 2016 the primary OpenStreetMap database will be
read-only for important maintenance. Editing the map will not be
possible during the maintenance.

Full announcement is available here:
https://blog.openstreetmap.org/2016/05/02/planned-server-outage-9th-may/

The Operations Working Group are in the process of planning some
hardware moves as a result of maintenance at our primary datacentre.
The plans are subject to change, but these moves are expected to take
place on Monday 9th May (a week from today), and this will mean a
period of read only operation lasting for up to 24 hours (into
Tuesday).

The read-only period will mean the OpenStreetMap website and map is
still available, but no map editing will be possible during this time.

The https://wiki.openstreetmap.org/wiki/2016_May_server_maintenance
wiki page has some more technical details, and will be updated with
more precise timing information as the plans are finalised in the
coming days.

We’re putting out this announcement to give some advanced notice, but
we appreciate some people will be wanting to know more about the exact
timings of the read-only period. Please have patience. The Operations
Working Group are busy making plans, and will aim to firm things up in
the coming days.

Kind regards,

Grant

on behalf of the OSM operations team

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

Re: [OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Romain MEHUT]

Oui j'ai vu également. Mais ça me fait penser que je connais quelqu'un qui
travaille à VNF. Je vais demander pour voir...

Romain

Le 2 mai 2016 à 17:02, Jean-Claude Repetto  a écrit :

> Le 02/05/2016 15:45, Romain MEHUT a écrit :
> > Bonjour,
> >
> > Le contributeur http://www.openstreetmap.org/user/malcolmh intègre
> > depuis peu des données liées à la navigation fluviale. Je lui ai demandé
> > quelle était sa source. Il m'a répondu "The data was extracted from
> > http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page
> > http://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la
> > licence ODbL.
> >
> > Quelqu'un pour confirmer ?
>
> Apparemment, il vient de lancer une série de "revert", avec comme
> commentaire : "Non ODBL data".
>
>
> ___
> 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] Intégration de données issues de Voies Navigables de France

[osm . sanspourriel]

> "Non ODbL compatible data" OSM peut accueillir autre chose que de 
l'ODbL ;)


Il y deux types de données sur internet : celles compatibles avec OSM et 
celle par encore compatibles.


Christian, le stagiaire du CEREMA, candidats pour leur demander 
l'autorisation ?


Peut-être faut-il demander par la voie postale si on peut les contacter 
par la voie électronique ;-).


Certaines cellules se trouvent sur : 
https://www.elwis.de/Service/Inland-ENC-der-WSV/index.html



 /Inland-ENC der WSV/

//

/Die Wasser- und Schifffahrtsverwaltung des Bundes (//WSV//) gibt ihre 
Geodaten gemäß Geodatenzugangsgesetz (//GeoZG//) in Verbindung mit der 
Verordnung zur Festlegung der Nutzungsbestimmungen für die 
Bereitstellung von Geodaten des Bundes (//GeoNutzV//) 
//*geldleistungsfrei*//ab./


//

/Ein Quellenvermerk gemäß GeoNutzV ist //*nicht*//anzubringen./

Traduction rapide :
/Cartes électroniques des voies navigable du WSV./

/L'agence allemande de gestion des voies navigables WSV met à 
disposition //*gratuitement*//ses données géolocalisées selon la loi sur 
l'accès aux données déolocalisées (GeoZG) en lien avec le décret sur la 
mise à disposition des données geolocalisées de l'Allemafne (GeoNutzV)./


/La citation de la source selon GeoNutZ //*n*//'est //*pas*//obligatoire.//
/

Avec ça côté allemand il doit y avoir moyen de négocier cela côté français.

Jean-Yvon

Le 2016-05-02 à 17:10, Christian Quest - cqu...@openstreetmap.fr a écrit :


"Non ODbL compatible data" OSM peut accueillir autre chose que de 
l'ODbL ;)



Le 02/05/2016 à 17:02, Jean-Claude Repetto a écrit :

Le 02/05/2016 15:45, Romain MEHUT a écrit :

Bonjour,

Le contributeurhttp://www.openstreetmap.org/user/malcolmh  intègre
depuis peu des données liées à la navigation fluviale. Je lui ai demandé
quelle était sa source. Il m'a répondu "The data was extracted from
http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page
http://www.vnf.fr/ecdis/  je doute que cela soit compatible avec la
licence ODbL.

Quelqu'un pour confirmer ?


Apparemment, il vient de lancer une série de "revert", avec comme
commentaire : "Non ODBL data".


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



--
Christian Quest - OpenStreetMap France


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


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

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Leonardo Brondani Schenkel]

Acho que é relevante para a votação e reproduzo o que escrevi no fórum:
http://forum.openstreetmap.org/viewtopic.php?pid=591013#p591013

Assim alguém com conhecimento do assunto pode contribuir.
---
Vou postar um link de algo que descobri recentemente que possa servir de 
clarificação, pelo menos eu não estava ciente:

http://ojs.fsg.br/index.php/direito/article/viewFile/600/479

O texto acima cobre especificamente o Rio Grande do Sul e um pouco de 
São Paulo, mas aborda pontos importantes que são gerais. Confesso que 
não me considero expert e não vou me surpreender caso tenha feito uma 
interpretação errada, mas conforme o texto acima:


1. A Constituição de 1988 (art. 25, § 3º) delegou aos Estados a 
competência de definir "instituir  regiões  metropolitanas, 
aglomerações urbanas e microrregiões,  constituídas por agrupamentos  de 
municípios limítrofes, para integrar a organização, o planejamento e a 
execução de funções públicas de interesse comum".


2. Os argumentos acima são definidos única e exclusivamente pelos 
Estados através de lei complementar aprovada pela assembléia 
legislativa. Apenas o Estado pode definir tais regiões; desde a 
Constituição de 1998 não compete mais à União defini-las.


3. Os Estados PODEM definir tais regiões por leis complementares, mas 
não significa que eles DEVEM ou mesmo VÃO.


4. A Constituição do RS definiu até um novo tipo de sub-divisão chamado 
"redes de Municípios" que basicamente é um agrupamento para fins 
administrativos de municípios não-limítrofes (já que a Constituição 
Federal define as divisões definidas por ela como sendo limítrofes).


Agora, considerando o acima note o seguinte:

5. A lista de meso e microrregiões do IBGE vem de uma publicação de 1989.

6. De acordo com a própria Constituição, a competência única de definir 
"sub-divisões" das UFs são das assembléias legislativas estaduais. A 
lista do IBGE portanto não define uma sub-divisão "oficial" ou 
"administrativa" pois não é de sua competência (claro que para critérios 
estatísticos o IBGE pode fazer o que quiser).


7. Note que o RS de acordo com o IBGE tem 35 micrroregiões desde 1989. 
Como então é possível que em 13 de dezembro de 2011 a Assembléia do RS 
aprovou a lei complementar que criou a primeira microrregião do Estado, 
chamada "Celeiro", que nem está na lista do IBGE? [1] [2] [3]


[1] 
http://www.al.rs.gov.br/legis/M010/M0100099.ASP?Hid_Tipo=TEXTO_TodasNormas=57949=_IDNorma=57949
[2] 
http://www2.al.rs.gov.br/noticias/ExibeNoticia/tabid/5374/IdOrigem/1/IdMateria/302013/language/pt-BR/Default.aspx
[3] 
http://al-rs.jusbrasil.com.br/noticias/2965462/assembleia-aprova-criacao-da-microrregiao-celeiro


8. De novo, o próprio IBGE diz que suas regiões não são na práticas 
usadas para fim administrativos conforme as referências já citadas.


9. Nada impede que um Estado defina uma microrregião que já foi definida 
pelo IBGE, mas é importante salientar que neste caso a microrregião foi 
criada pela Assembléia Legislativa daquele Estado e não pelo IBGE.


O ponto que eu quero fazer, o que não era óbvio para mim até 
recentemente, é que microrregiões administrativas definidas na 
Constituição e microrregiões do IBGE __não são a mesma coisa__ embora 
tenham o mesmo nome. São coisas diferentes. É isso que confunde muita 
gente (inclusive eu).


De novo: esta votação é sobre as __regiões definidas pelo IBGE__, não 
sobre como representar as regiões definidas pelos Estados (que acredito 
que nem existam no OSM) — isso fica para outra discussão .


On 02/05/16 17:17, Leonardo Brondani Schenkel wrote:

Uma clarificação: como postado por Nelson na talk-br [1], os Estados
têm, de acordo com definido pela Constituição no art. 25 §3º [2] a
competência para definir via lei complementar estadual suas próprias
"sub-divisões" para fins administrativos. Estas sub-divisões podem ou
não concidir com as divisões definidas pelo IBGE. Esta votação se refere
__apenas aos limites definidos pelo IBGE para fins estatísticos__, não a
quaisquer limites definidos por lei complementar estadual para fins
administrativos.

[1] https://lists.openstreetmap.org/pipermail/talk-br/2016-May/011328.html

[2]
http://www.jusbrasil.com.br/topicos/10717153/paragrafo-3-artigo-25-da-constituicao-federal-de-1988:


Os Estados poderão, mediante lei complementar, instituir regiõe
metropolitanas, aglomerações urbanas e microrregiões, constituídas
por agrupamentos de municípios limítrofes, para integrar
organização, o planejamento e a execução de funções públicas de
interesse comum.


// Leonardo.


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




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

Re: [OSM-talk-fr] Cartes papiers (A3/A2) avec ajout données locales : suites logicielles et conseils

[Valentin Surrel]

Bon, après mûre réflexion, je pense partir :

- Maperitive/R25 pour commencer et avoir un résultat plutôt bon à 
relativement court terme.


- Tweaker un style Mapnik pour converger dans N mois à un rendu proche 
de la solution Maperitive/R25


Pourqoi ? J'aime bien avoir le contrôle de ma chaîne de production de 
manière intégrale. La pérennité de composant comme Maperitive étant 
aléatoire (tout comme les briques Mapbox CartoCSS/TileMill), je vais 
donc me restreindre à des composants éprouvés et opensource.


L'idée étant d'arriver, un jour peut-être, à un francetopo-like mais 
avec le style en licence ouverte.


Bougez pas, je reviens dans 24 mois :D

A+

Valentin

Le 2016-05-01 12:51, JB a écrit :

- Point vectoriel : les retours que j'ai de mapnik indiquent des
fichiers très difficilement utilisables. Maperitive semble faire un
peu mieux. De mon coté, le petit imprimeur avec qui j'avais bossé une
petite fois me disait qu'au-dessus de 300-400dpi (natif au format), il
n'avait pas forcément d'intérêt à passer au vectoriel (par contre, il
a des clients qui récupèrent une image sur internet et la modifient
pour arriver à 300dpi… et arrivent avec un fichier qui fait 3 ou 4
centimètres de coté). Du coup, je t'encourage de regarder ce que ça
peut donner sous Inkscape, je suis intéressé par tes retours. (Et au
fait, quels travail vas-tu faire sous Inkscape ?)

- Malgré la libération de .NET par Microsoft, les bibliothèques
graphiques n'avaient pas encore été intégrées par Mono. Je ne sais pas
si ça a évolué, mais les exports sous Linux étaient d'assez mauvaise
qualité sur les rendus de couleurs et de transparences (voir notamment
les éléments rouges touristiques).

- Quelqu'un avait abordé l'idée de passer R25 en CSS, je lui avais dit
que j'étais curieux du boulot que ça donnerait mais le projet semble
avoir été abandonné depuis longtemps. R25, c'est actuellement plus de
5000 lignes, sous une syntaxe très différente du CSS… donc du boulot,
du boulot. L'idée avait été évoquée de monter un petit serveur pour
produire des cartes à la demande, mais comme je n'ai pas les
compétences et qu'on n'avait pas monté d'équipe, c'est resté au stade
de l'idée. (Et de mon coté, je ne coderai pas le style en carto-CSS
pour diverses raisons).

JB.



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

Re: [Talk-pt] Peça jornalística que utiliza o OSM

[Alexandre Neto]

:-) adoro quando os grandes começam a usar open source e openstreetmap.

Obrigado pela partilha.

A seg, 2/05/2016, 14:51, Rui Oliveira  escreveu:

> Carissimos.
>
> Deixo aqui o link para uma peça jornalística do público  que na minha
> opinião está muito bem interessante, sobretudo pela integração bastante bem
> conseguida do OSM (através do uso da Leaflet) no tópico em questão :)
>
>
>
> http://www.publico.pt/multimedia/interactivo/memorias-de-um-porto-operario-e-anarquista
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-br] RES: Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Arlindo Pereira]

Concordo: regiões do IBGE não são administrativas e usar
`boundary=administrative` está errado

[]s

2016-05-02 13:56 GMT-03:00 Blademir Andrade de Lima 
:

> Concordo: Limites censitários já existem nos EUA (Census-designated Places
> [CDP]), e então já existe uma prerrogativa para serem também usados no
> Brasil.
>
>
>
> Att,
>
> Blademir de Lima (BladeTC)
>
>
>
> Enviado do Email  para
> Windows 10
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-cz] Stromy pod kontrolou

[jzvc]

Cus

Dne 1.5.2016 v 9:25 Pavel Machek napsal(a):

Ahoj!


Takže se vás chci zeptat:
   * v jakém formátu by to pro nás bylo nejlepší?
   * zda ta data co jsem napsal stačí? - za mě bych přidal výšku a průměr
   * něco jiného co by vás napadlo?


Listnaty/jehlicnaty?

Jinak...

Nebyl by cas udelat znovu (a lip) import lesu? Mensi generalizace,
importovat informaci listnaty/jehlicnaty...

Pavel



Byl bych velice opatrny s jakymkoli re-importem. Znicis tim spousty 
prace. Mozna tak v podobe traceru a vizualni kontroly. Vsichni vime jak 
"kvalitni" data nase stat(d?)ni sprava (ne)spravuje ...


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

[Talk-us] New MeetUp OSM group in Los Angeles

[Charlotte Wolter]

Hello,

I'm trying to get an OSM group up and running in Los 
Angeles. The former Southern California group, formerly operated by 
ESRI, was going to shut down, but I thought I would see if I can get it going.
There are many exciting projects we could do, in addition to 
learning how to use OpenStreetMap (iD and JOSM alike).
--As this is the 100-year birthday of the National Park 
Service, we could spruce up the local national and state parks
--We could work on validating the ongoing import of building 
outlines for LA County
--There is a database of all the food banks in LA County, 
which needs help to be added to OSM.
More important is what do the group members want to do? What 
projects will they think are important for Los Angeles?
So, it you're interested, please send me an email or go to 
MeetUp and look for "OSM Southern California."

Hope to hear from you soon.

Charlotte


Charlotte Wolter
927 18th Street Suite A
Santa Monica, California
90403
+1-310-597-4040
techl...@techlady.com
Skype: thetechlady



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

Re: [OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Philippe Verdy]

une autre licence oui, mais seulement si elle est compatible (ce n'est pas
le cas de l'ancienne licence d'OSM et cela a conduit à des suppressions
massives des données dont les utilisateurs n'avaient pas accepté la
nouvelle licence dans le délai imparti). Les données sont toutes
redistribuées en OdBL uniquement même si leur licence d'origine n'était pas
celle-là (ces données ont été acceptées du moement qu'elles étaient
compatibles, exemples les données LO/OL, celles sous des licences du style
MIT, et les données des domaines publics de divers pays come TIGER, les
données sous certaines licences Creative Commons ou GNU mais pas toutes).

OSM impose de pouvoir redistribuer directement en OdBL uniquement et
d'oublier la licence d'origine (OSM ne garde que les attributions d'auteur,
essentiellement par les historiques de contribution, mais aussi par sa page
wiki "Sources" qui mentionne les contributions majeures). En fait OSM est
moins permissif que Wikimedia qui permet la multiplicité des licences (et
même accepte certaines clauses non libres sur certains wikis (par exemple
pour les logos dont l'usage est restreint à certaines pages relatives à
leurs ayant-droits, et pour le "fair use américain" utilisable uniquement
sur la Wikipédie anglophone: ce n'est pas sans problème car certaines
parties de la Wikipédie anglophone ne peuvent alors pas être légalement
exportées, et cela impose un filtrage comme le fait Google pour montrer des
extraits sans les images à problème: Google les remplace par d'autres
images dont il a les droits, sinon il élimine l'article à problème, y
compris dans les résultats de recherche selon les pays).

Nous on veut une carte qui soit libre et accessible par tous, on n'a pas de
filtres pour les cartes ou requêtes de données selon le pays du demandeur,
ou selon sa qualité, sa langue ou ses opinions, en revanche on tentera de
lui donner les moyens de pouvoir choisir lui-même (on ne le fait pas assez
et on a encore trop de choix imposés qui masquent d'autres données qui
pourrait lui être utiles, par exemple dans Nominatim qui est très "fermé"
dans ses choix un peu trop arbitraires et approximatifs; c'est moins gênant
en revanche pour les rendus car on a maintenant le choix avec de bonnes
performances et aussi le choix de faire un rendu soi-même; Overpass est en
revanche très encourageant pour des besoins spécifiques, malgré ses
performances limitées et sa fréquente instabilité technique).

Le 2 mai 2016 à 17:10, Christian Quest  a écrit :

> "Non ODbL compatible data" OSM peut accueillir autre chose que de
> l'ODbL ;)
>
> Le 02/05/2016 à 17:02, Jean-Claude Repetto a écrit :
>
> Le 02/05/2016 15:45, Romain MEHUT a écrit :
>
> Bonjour,
>
> Le contributeur http://www.openstreetmap.org/user/malcolmh intègre
> depuis peu des données liées à la navigation fluviale. Je lui ai demandé
> quelle était sa source. Il m'a répondu "The data was extracted 
> fromhttp://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette 
> pagehttp://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la
> licence ODbL.
>
> Quelqu'un pour confirmer ?
>
>
>
> Apparemment, il vient de lancer une série de "revert", avec comme
> commentaire : "Non ODBL data".
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Manuel Lladosa]

Me parece una iniciativa genial, porque la verdad que habían carreteras 
"Trunk" en un estado bastante lamentable.


En general lo veo todo bien, pero tengo una pregunta, con "enlaces a 
distinto/mismo nivel", ¿te refieres a cruces a distinto/mismo nivel? Así 
lo he entendido yo, pienso que la gente entenderá mejor la palabra 
cruces, por lo menos a mí la palabra enlace me sugiere incorporación a 
autovía.


Un saludo.

El 02/05/16 a les 14:00, talk-es-requ...@openstreetmap.org ha escrit:

Después de un proceso de debate con parte de la comunidad OSM de España
vía Telegram y de la necesidad de reformulación de la Normalización de vías
interurbanas os presento como quedaría en la wiki. Es un apartado de la
wiki que además de expresar las diversas categorías de la normalización
basada más en ser física que administrativa también tiene en cuenta las
diversas planificaciones de las administraciones que tienen competencias en
carreteras, desde gobiernos autonómicos a consejos insulares, algunas vías
de los cuales son modernas y por lo tanto pueden cumplir con categorías
físicas más importantes que las que les da una clasificación administrativa.
  El texto está abierto a debate, es inclusivo y requerirá de la
participación activa de la comunnidad ya que se se tienen en cuenta casos
específicos para determinados lugares con determinados usos (a más uso más
importancia ergo más categoría). Esperemos que esta nueva normalización
haga que nuestros mapas sean más reales y más útiles si cabe.

  La dirección para consultarla es
http://wiki.openstreetmap.org/wiki/User:Yopaseopor y en un futuro ocupará
el apartado de vías interubanas y de comunidades autónomas de
http://wiki.openstreetmap.org/wiki/Normalizaci%C3%B3n

  ¿Qué opinais? ¿Cómo lo veis? ¿Qué mejoraríais?
  Salud y Normalización
  Yopaseopor




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

Re: [Talk-se] Nyare Mapbox satellitbilder

[Andreas Vilén]

Yay, hela norra skåne också!!

Skickat från min iPhone

> 2 maj 2016 kl. 12:36 skrev Kristoffer Malmström :
> 
> Längs gävle och upplands kusten finns tyärr inga nya mapbox bilder.
> 
> Med vänliga hälsningar
> Kristoffer Malmström
> Tel: 0733690161
> 
> Den 2 maj 2016 09:04 skrev Martin Norbäck Olivers :
>> Tack för tipset! Det finns jättefina mapbox-bilder på mina kvarter nu!
>> 
>> Passningen verkar också i det närmaste perfekt.
>> 
>> Hälsningar Martin
>> 
>> Den 2 maj 2016 08:36 skrev Christian Asker :
>>> Hej på er. Jag såg precis att det runt min hemort har kommit fräschare 
>>> Mapbox-satellitbilder. Förut var dom nästan helt oanvändbara, men nu är dom 
>>> nästan hyfsade. Dessvärre är det svårt att justera in en bra offset 
>>> eftersom jag inte riktigt vet vilka punkter i OSM-datat som är mest 
>>> tillförlitliga.
>>> Ni som också saknat bra Mapbox-satellitbilder kan ju kika ifall ni också 
>>> har fått fräschare bilder.
>>> 
>>> Jag tror att jag ska göra en liten lokal mätkampanj där jag mäter upp ett 
>>> par korsningar eller liknande ett antal gånger. Sen kan jag passa in 
>>> satellitbildernas offset mot dessa.
>>> 
>>> Mvh Christian
>>> 
>>> ___
>>> Talk-se mailing list
>>> Talk-se@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-se
>> 
>> 
>> 
>> -- 
>> Martin Norbäck Olivers
>> IT-konsult, Masara AB
>> Telefon: +46 703 22 70 12
>> E-post: mar...@norpan.org
>> Kärrhöksvägen 4
>> 656 72 Skattkärr
>> 
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-be] OSM newsletter

[joost schouppe]

All help still welcome for the newsletter plan. The text is finally taking
shape. If you like it, you could translate it to Dutch or French.

https://hackpad.com/First-message-on-the-newsletter-0VV4Ftu482s
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[Talk-br] RES: Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Blademir Andrade de Lima]

Concordo: Limites censitários já existem nos EUA (Census-designated Places 
[CDP]), e então já existe uma prerrogativa para serem também usados no Brasil.

Att,
Blademir de Lima (BladeTC)

Enviado do Email para Windows 10
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Brad Neuhauser]

What about just combining the relations for selected states where the AT
crosses back and forth across the state border, like TN/NC and VA/WV?

On Mon, May 2, 2016 at 11:05 AM, Martijn van Exel  wrote:

>
> > On May 2, 2016, at 9:49 AM, Mike N  wrote:
> >
> > On 5/2/2016 11:41 AM, Elliott Plack wrote:
> >> This got me thinking, is there any specific need to have the route
> >> broken up by state? Unlike interstate highways, where maintenance
> >> changes across state lines, at the border, the AT maintenance is handled
> >> by a trifecta of federal agencies and a non-profit. There are also 31
> >> clubs that share some of the maintenance on some sections.
> >
> >  The advantage of breaking up a relation into smaller relations is to
> minimize the probability of edit conflicts.  I don't know how often things
> change, or more detail is added on the Appalachian Trail.   My tendency
> would be to leave it separated, but I have no strong opinion either way.
>
> I am with Mike here. The state boundary offers an obvious and visible
> opportunity to slice up potentially unwieldy relations into smaller chunks.
> Huge relations make editing trickier (conflicts, relation member
> management, loading times) and data processing potentially more time and
> memory consuming.
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Martijn van Exel]

> On May 2, 2016, at 9:49 AM, Mike N  wrote:
> 
> On 5/2/2016 11:41 AM, Elliott Plack wrote:
>> This got me thinking, is there any specific need to have the route
>> broken up by state? Unlike interstate highways, where maintenance
>> changes across state lines, at the border, the AT maintenance is handled
>> by a trifecta of federal agencies and a non-profit. There are also 31
>> clubs that share some of the maintenance on some sections.
> 
>  The advantage of breaking up a relation into smaller relations is to 
> minimize the probability of edit conflicts.  I don't know how often things 
> change, or more detail is added on the Appalachian Trail.   My tendency would 
> be to leave it separated, but I have no strong opinion either way.

I am with Mike here. The state boundary offers an obvious and visible 
opportunity to slice up potentially unwieldy relations into smaller chunks. 
Huge relations make editing trickier (conflicts, relation member management, 
loading times) and data processing potentially more time and memory consuming.


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

Re: [Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Wille]

oi, Sérgio!

1) Sabem se no QGIS há uma maneira de filtrar isto (por área ou por 
somatório de comprimento de linha)?



Tem, mas talvez necessite converter para um SRID que permita cálculo de 
área em metros ou hectares.


2) No QGIS fiz a troca na tabela de dados dos "nomes dos campos "para 
as "KEYS" compatíveis com o OSM (ex: de "CLASSE" para "bulding").


Mas quanto aos "valores" dos  atributos ("VALUES"), sabem se há uma 
maneira dentro do QGIS de substituir todos os "valores" idênticos na 
tabela de dados (ex.: tudo que for "ESCOLA" para "school")?


Ou tem que editar o .DBF fora do QGIS, subsituir os "values", e depois 
acoplar novamente (mas e o risco de dar bagunça no SHP)? Se sim, com 
qual software?



Tem uma calculadora de campo no QGIS. Acredito que por ela é possível 
fazer essas substituições.



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

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[David Crochet]

Bonjour

Le 02/05/2016 17:39, adrien a écrit :

  faut-il que j'ajoute une relation par type de
déplacement, sachant que c'est le même circuit ?


oui

Cordialement

--
David Crochet

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

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Mike N]

On 5/2/2016 11:41 AM, Elliott Plack wrote:

This got me thinking, is there any specific need to have the route
broken up by state? Unlike interstate highways, where maintenance
changes across state lines, at the border, the AT maintenance is handled
by a trifecta of federal agencies and a non-profit. There are also 31
clubs that share some of the maintenance on some sections.


  The advantage of breaking up a relation into smaller relations is to 
minimize the probability of edit conflicts.  I don't know how often 
things change, or more detail is added on the Appalachian Trail.   My 
tendency would be to leave it separated, but I have no strong opinion 
either way.


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

[OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[adrien]

Bonjour,

J'aimerais ajouter une promenade de ma commune dans OSM. La balade peut
se faire à pied, à vélo et à cheval.

Lorsque j'ajoute une relation avec plusieurs types (foot, bicycle,
horse), seul un seul s'affiche dans http://hiking.waymarkedtrails.org
Sinon comment faire ? faut-il que j'ajoute une relation par type de
déplacement, sachant que c'est le même circuit ?

Bonne journée

Adrien

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

[Talk-us] Per-State relations for the Appalachian Trail

[Elliott Plack]

I've been doing some mapping along the Maryland portions of the Appalachian
Trail lately and noticed many issues along Maryland's section as well as
nearby Virginia and West Virginia where the route relations were not
continuous or overlapped other states'. Strava's slide has been quite
helpful in this effort, as has my own walking of the trail.

This got me thinking, is there any specific need to have the route broken
up by state? Unlike interstate highways, where maintenance changes across
state lines, at the border, the AT maintenance is handled by a trifecta of
federal agencies and a non-profit. There are also 31 clubs that share some
of the maintenance on some sections.

Given that it is clearly a challenge to keep all of the routes in order,
would there be any objection from the community to combining all of the
relations into one single route? Any technical issues or limitations here?
I think that having one long relation would make the continuity easier to
manage. (And I could be wrong! If so, let's figure out how to manage the
relation together.)

I've also noticed that most renderers do not seem to consider the hiking
route, but rather the tags on the individual segments, thus adding to the
complexity of normalizing some of the tagging across the country.

Current super-relation:
http://www.openstreetmap.org/relation/156553#map=5/45.587/-61.941

Thanks,

Elliott
-- 
Elliott Plack
http://elliottplack.me
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Leonardo Brondani Schenkel]

Uma clarificação: como postado por Nelson na talk-br [1], os Estados 
têm, de acordo com definido pela Constituição no art. 25 §3º [2] a 
competência para definir via lei complementar estadual suas próprias 
"sub-divisões" para fins administrativos. Estas sub-divisões podem ou 
não concidir com as divisões definidas pelo IBGE. Esta votação se refere 
__apenas aos limites definidos pelo IBGE para fins estatísticos__, não a 
quaisquer limites definidos por lei complementar estadual para fins 
administrativos.


[1] https://lists.openstreetmap.org/pipermail/talk-br/2016-May/011328.html

[2] 
http://www.jusbrasil.com.br/topicos/10717153/paragrafo-3-artigo-25-da-constituicao-federal-de-1988:

> Os Estados poderão, mediante lei complementar, instituir regiõe
> metropolitanas, aglomerações urbanas e microrregiões, constituídas
> por agrupamentos de municípios limítrofes, para integrar
> organização, o planejamento e a execução de funções públicas de
> interesse comum.

// Leonardo.


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

Re: [OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Christian Quest]

"Non ODbL compatible data" OSM peut accueillir autre chose que de 
l'ODbL ;)



Le 02/05/2016 à 17:02, Jean-Claude Repetto a écrit :

Le 02/05/2016 15:45, Romain MEHUT a écrit :

Bonjour,

Le contributeur http://www.openstreetmap.org/user/malcolmh intègre
depuis peu des données liées à la navigation fluviale. Je lui ai demandé
quelle était sa source. Il m'a répondu "The data was extracted from
http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page
http://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la
licence ODbL.

Quelqu'un pour confirmer ?



Apparemment, il vient de lancer une série de "revert", avec comme
commentaire : "Non ODBL data".


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



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Jean-Claude Repetto]

Le 02/05/2016 15:45, Romain MEHUT a écrit :
> Bonjour,
> 
> Le contributeur http://www.openstreetmap.org/user/malcolmh intègre
> depuis peu des données liées à la navigation fluviale. Je lui ai demandé
> quelle était sa source. Il m'a répondu "The data was extracted from
> http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page
> http://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la
> licence ODbL.
> 
> Quelqu'un pour confirmer ?
> 


Apparemment, il vient de lancer une série de "revert", avec comme
commentaire : "Non ODBL data".


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

Re: [OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Jean-Marc Liotier]

On 2016-05-02 15:45, Romain MEHUT wrote:

> Le contributeur http://www.openstreetmap.org/user/malcolmh intègre depuis peu 
> des données liées à la navigation fluviale. Je lui ai demandé quelle était sa 
> source. Il m'a répondu "The data was extracted from 
> http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page 
> http://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la licence 
> ODbL.

Un administrateur pour supprimer ce post des archives de la mailing list
? Il est en infraction avec les conditions d'utilisation sus-mentionnées
: "Toute création d'un lien hypertexte d'un site internet vers le site
de VNF devra faire l'objet d'une autorisation expresse de Voies
navigables de France" - et ma réponse aussi du même coup... 

Plus sérieusement, VNF s'y réserve explicitement tous les droits
concernant toutes données publiées... C'est on ne peut plus clair. 
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ec] [activation hotosm] Re: Automatic reply: HOT activation earthquake Ecuador

[Jose Cisneros Gallegos]

Hola,

Hace unos minutos cree este proyecto http://tasks.hotosm.org/project/1793
con la delimitacion de las dos provincias. Me base en los mapas del USGS
para la delimitacion. El mapa de base es Bing y no tiene buena resolucion...

Saludos,

Jose

On 17 April 2016 at 08:31, hyan...@gmail.com  wrote:

> Hola José Cisneros,
>
> gracias por su interés en colaborar con el mapeo en Ecuador.  En este
> momento estamos buscando información sobre los poligonos de las áreas
> afectadas para definir los primeros proyectos, en esto estamos coordinando
> entre HOT, comunidad OSM del Ecuador, comunidad OSM latam y autoridades
> gubernamentales en Ecuador.
>
> Si no estás suscrito aun en la lista de talk-ec@openstreetmap.org por
> favor hazlo.  Este tuit lleva el hilo de conversación actual
>
> https://twitter.com/temporalista/status/721686892287258624
>
> por favor únete a él.  Espero pronto sea posible abrir los primero
> proyectos de mapeo.
>
> Saludos,
>
> Humberto Yances
> Miembro del HOT
>
> 2016-04-17 8:09 GMT-05:00 Dale Kunce :
>
>> Jose has lots of experience for both RC and MSF he is a good local
>> resource.
>>
>> Humberto can you reach out to him directly.
>>
>> -- Forwarded message --
>> From: Jose Cisneros Gallegos 
>> Date: Sun, Apr 17, 2016 at 8:43 AM
>> Subject: Re: Automatic reply: HOT activation earthquake Ecuador
>> To: Dale Kunce 
>>
>>
>> Hi Dale,
>>
>> Hope you are well. I don't know if you remember me, I was a volunteer at
>> MSF UK and the British Red Cross for the Missing Maps Project last year. I
>> am now back in Ecuador and the earthquake just happened.
>>
>> I know that the American Red Cross (through Drishtie Patel) has been
>> coordinating the work of the HOT-OSM-Missing Maps community in Ecuador. I
>> just logged in to the HOT Tasking Manager and saw there is no areas to map
>> for the earthquake in Ecuador. I wonder if there's been any activation of
>> the HOT community yet, and if so, do you know how I can help?
>>
>> Best,
>>
>> Jose
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>> <#m_-6901632079551454076_m_-2416994947713958119_m_-8191232253088317937_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On 17 April 2016 at 07:38, Patel, Drishtie 
>> wrote:
>>
>>> I will be out of the office on PTO from 11th April to 15th April, 2016.
>>> For urgent matters please contact dale.ku...@redcross.org.
>>>
>>>
>>> Best,
>>>
>>> Drishtie Patel
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> sent from my mobile device
>>
>> Dale Kunce
>> http://normalhabit.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Activation Working Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to activation+unsubscr...@hotosm.org.
>> To post to this group, send email to activat...@hotosm.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/hotosm.org/d/msgid/activation/CADOF%3D4KU569SDexdJgzZ6OGLuCeDyxDoXJAFPu-zy7yrPHE6SA%40mail.gmail.com
>> 
>> .
>>
>
>
___
Talk-ec mailing list
Talk-ec@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ec

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Volker Schmidt]

2016-05-02 14:21 GMT+02:00 Martin Koppenhoefer :

>
> 2016-05-02 14:07 GMT+02:00 Marco Bartalini :
>
>> penso ad esempio al fatto di lasciare visibili le linee elettriche e a
>> non rendere visibili i cancelli ad esempio! che rabbia...
>
>
>
>
> si, perché quella mappa è fatto da uno Svizzero, appunto per la Svizzera.
> Per esempio in Germania (non so in Svizzera) tu puoi (a piedi) andare
> (quasi) d'ovunque in campagna aperta, mentre in Italia quasi sempre trovi
> tutto recintato (al meno qui vicino Roma). Il fattore regionale è
> essenziale quando si mappa e quando si fa una mappa, e ovviamente tutti
> partono (e spesso si fermano) da ciò che conoscono.
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-pt] Peça jornalística que utiliza o OSM

[Rui Oliveira]

Carissimos.

Deixo aqui o link para uma peça jornalística do público  que na minha
opinião está muito bem interessante, sobretudo pela integração bastante bem
conseguida do OSM (através do uso da Leaflet) no tópico em questão :)


http://www.publico.pt/multimedia/interactivo/memorias-de-um-porto-operario-e-anarquista
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[OSM-talk-fr] Intégration de données issues de Voies Navigables de France

[Romain MEHUT]

Bonjour,

Le contributeur http://www.openstreetmap.org/user/malcolmh intègre depuis
peu des données liées à la navigation fluviale. Je lui ai demandé quelle
était sa source. Il m'a répondu "The data was extracted from
http://www.vnf.fr/ecdis/data/Moselle.zip"En lisant cette page
http://www.vnf.fr/ecdis/ je doute que cela soit compatible avec la licence
ODbL.

Quelqu'un pour confirmer ?

Merci.

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

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[thundercel]

CONCORDO

Concordo porque compreendo que limite administrativo (divisão 
administrativa) requer uma administração central e por essa razão não 
deveria ser empregado no Brasil para outros fins como os idealizados pelo 
IBGE.


A divisão do Brasil por regiões serve para outros fins estatísticos e não 
administrativos.


Antigamente, na divisão administrativa do Brasil, tínhamos a figura do 
território que foram incorporados a administração de estados. Hoje só temos 
o distrito federal, os estados, os municípios e os distritos.



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

Re: [Talk-br] RES: Limite de cidades com distritos

[Leonardo Brondani Schenkel]

On 02/05/16 15:01, Nelson A. de Oliveira wrote:

Microrregiões (não as do IBGE) são previstas na constituição:

=
Art. 25. Os Estados organizam-se e regem-se pelas Constituições e leis
que adotarem, observados os princípios desta Constituição.

§ 3º Os Estados poderão, mediante lei complementar, instituir regiões
metropolitanas, aglomerações urbanas e microrregiões, constituídas por
agrupamentos de municípios limítrofes, para integrar a organização, o
planejamento e a execução de funções públicas de interesse comum.
=

Inclusive existindo leis que as definem:

http://www.al.sp.gov.br/propositura/?id=100
http://www.al.sp.gov.br/propositura/?id=1003338
etc

Seja lá onde for parar essa discussão, precisa ter cuidado para
simplesmente não "rebaixar" toda microrregião.


Ótimo ponto. Iniciei uma votação sobre o assunto, postei na lista, e 
naquela votação me refiro àquelas __definidas pelo IBGE para fins 
estatísticos__, não a qualquer região definida a nível estadual para 
fins de administração. Acho que tenha sido claro ao explicar na votação 
que propus, mas não custa reforçar.


Sobre os links que postou, pergunto por desinformação total minha: a 
página menciona __projetos__ de lei complementar; não está explícito na 
página se os projetos foram aprovados pela assembléia (não que eu esteja 
duvidando e também não altera o seu ponto) — acho que links para leis no 
diário oficial seriam mais úteis (caso sejam de seu conhecimento).



E enquanto procurava por algo parecido eu encontrei os
Census-designated places (CDP) nos EUA, que me pareceram muito
similares ao nosso caso:

"They don't have any legal status, or represent the jurisdiction of
any government. CDPs are created by the Census Bureau for statistical
purposes only." -
https://wiki.openstreetmap.org/wiki/Talk:Key:boundary#United_States

Há alguns dias eu perguntei na talk-us como representam tais áreas e
basicamente são representadas como place=* ou com boundary=census


Exatamente, já que existe o entendimento que `boundary=administrative` 
não é apropriado para bordas não-administrativas.


// Leonardo.


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

Re: [Talk-it] Ludoteca

[Aury88]

Mauro Costantini wrote
> A naso direi amenity=toy_library (95 casi su taginfo).

Mi sembra adeguato anche se non ritengo il key amenity il più appropriato
per questo genere di attività ricreative.

ne avevo taggato uno a Gela in maniera errata, l'ho modificato con questo
tag; quindi grazie per la segnalazione ;-)



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Ludoteca-tp5872809p5872878.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-cz] podivná navigace

[Karel Volný]

čest práci,

> v Brankovicích byla chybně nastavena jedna krátká cesta jako footway a
> proto přes ni nešlo projet.
> 
> Stejně chybně trasu vyhodnotí i OSRM. Viz:
> http://www.openstreetmap.org/directions?engine=osrm_car=49.1879%2C16.6
> 218%3B49.0673%2C17.3865#map=14/49.1226/17.1406 Tímto šlo zjistit, jaký úsek
> mu vadí.
> 
> Opravil jsem to, viz:
> https://www.openstreetmap.org/changeset/39037597
> 
> Chyba byla zanesena asi 30.3. tímto changesetem:
> https://www.openstreetmap.org/changeset/38166944

ok, díky

zjevně jsem hledal ve špatném úseku, protože jsem vycházel z toho, že se mě na 
ty Koryčany snažil vyhodit ještě ve Střílkách - takže toto asi bude bug 
OSMAndu, že si Koryčany označil jako nějaký waypoint a snažil se tam dostat i 
když už to bylo irelevantní :-/

> Do příští aktualizace map to tam bohužel bude hnít.

grr, to jsem schválně před cestou stahoval aktualizace, kdybych si nechal 
předchozí verzi, tak se mi tam ta chyba nedostala, prostě zase den blbec

K.


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

Re: [Talk-it] sentiero con variante

[Alberto Nogaro]

>-Original Message-
>From: demon.box [mailto:e.rossin...@alice.it]
>Sent: lunedì 2 maggio 2016 13:24
>To: talk-it@openstreetmap.org
>Subject: Re: [Talk-it] sentiero con variante
>
>scusate, prob non mi sono spiegato bene...
>
>la variante è una nuova relazione a sè stante soltanto che la metto (come
>intera relazione) anche membro della relazione del sentiero principale.
>
>è una modalità che tra l'altro ho trovato già impostata su alcuni percorsi 
>della
>mia zona (questo non significa per forza che fosse corretto).
>
>riepilogando:
>
>Sentiero principale 370
>RELAZIONE A
>
>Variante del sentiero principale 370B
>RELAZIONE B
>membro di RELAZIONE A

In casi simili, ho messo le due relazioni in una super relazione di tipo 
route_master [1]. Secondo il wiki vale solo per i veicoli. Ma visto che vale 
per le biciclette (che difficilmente sono un mezzo di trasporto pubblico), non 
vedo perché non dovrebbe estendersi anche ai sentieri? In pochi casi è in uso 
con valore hiking, ad esempio [2].

[1] http://wiki.openstreetmap.org/wiki/Relation:route_master
[2[http://www.openstreetmap.org/relation/1309244

Ciao,
Alberto


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

Re: [Talk-br] RES: Limite de cidades com distritos

[Nelson A. de Oliveira]

Microrregiões (não as do IBGE) são previstas na constituição:

=
Art. 25. Os Estados organizam-se e regem-se pelas Constituições e leis
que adotarem, observados os princípios desta Constituição.

§ 3º Os Estados poderão, mediante lei complementar, instituir regiões
metropolitanas, aglomerações urbanas e microrregiões, constituídas por
agrupamentos de municípios limítrofes, para integrar a organização, o
planejamento e a execução de funções públicas de interesse comum.
=

Inclusive existindo leis que as definem:

http://www.al.sp.gov.br/propositura/?id=100
http://www.al.sp.gov.br/propositura/?id=1003338
etc

Seja lá onde for parar essa discussão, precisa ter cuidado para
simplesmente não "rebaixar" toda microrregião.


E enquanto procurava por algo parecido eu encontrei os
Census-designated places (CDP) nos EUA, que me pareceram muito
similares ao nosso caso:

"They don't have any legal status, or represent the jurisdiction of
any government. CDPs are created by the Census Bureau for statistical
purposes only." -
https://wiki.openstreetmap.org/wiki/Talk:Key:boundary#United_States

Há alguns dias eu perguntei na talk-us como representam tais áreas e
basicamente são representadas como place=* ou com boundary=census

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

Re: [Talk-cz] podivná navigace

[Vladimír Domes]

Ahoj,
v Brankovicích byla chybně nastavena jedna krátká cesta jako footway a
proto přes ni nešlo projet.

Stejně chybně trasu vyhodnotí i OSRM. Viz:
http://www.openstreetmap.org/directions?engine=osrm_car=49.1879%2C16.6218%3B49.0673%2C17.3865#map=14/49.1226/17.1406
Tímto šlo zjistit, jaký úsek mu vadí.

Opravil jsem to, viz:
https://www.openstreetmap.org/changeset/39037597

Chyba byla zanesena asi 30.3. tímto changesetem:
https://www.openstreetmap.org/changeset/38166944

Do příští aktualizace map to tam bohužel bude hnít.

  V.


Dne 2. května 2016 10:56 Karel Volný  napsal(a):

> zdar,
>
> nemá někdo náhodou nápad, proč při cestě z Brna na Uherské Hradiště trvá
> OSMAnd na tom, že se musí jet přes Koryčany místo po I50, a to dokonce tak
> natvrdo, že je schopen člověka z I50 vyhnat pryč s návratem až u Stupavy
> ještě
> u Střílek (kde už mu to zcela zjevně nemůže vycházet ani kratší, ani
> rychlejší)?
>
> koukal jsem, jestli v datech nenajdu něco, proč by si myslel, že příslušný
> úsek I50 (Střílky-Stupava) je neprůjezdný, ale ničeho jsem si nevšiml,
> poslední úprava většinou před 2-3 lety ...
>
> a mimochodem, je nějaká možnost, jak penalizovat silnici, aby ji navigace
> znevýhodňovaly, aniž by se tagovala něčím, co není pravda, jako třeba že je
> nižší třídy než formálně je?
> - našel jsem maxspeed:practical, ale to mi přijde příliš specifické,
> jednak se
> to liší dle vozidla a jednak dle podmínek (sníh, tma, provoz), takže bych
> tam
> musel naflákat tisíc conditionalů, aby se to blížilo realitě, zatímco já
> bych
> rád stroji sdělil informaci ve smyslu "tato cesta je méně výhodná než
> zajížďka
> o ~1/3, jak rychlostně, tak ekonomicky neb se dá jet pouze stylem
> brzda-plyn,
> s podstatně vyšší spotřebou proti plynulé jízdě, a ještě si na ní odděláte
> tlumiče"
>
> K.
>
> p.s. zjevně jsem nebyl jediný, kdo se za odbočkou musel podívat do mapy,
> že ho
> navigace žene blbě ...  z čehož soudím, že by se měla hledat chyba prvně v
> datech, pak teprv v aplikaci, stejný zdroj dat mi přijde o dost
> pravděpodobnější než stejná chyba v aplikaci (no ovšem ... když už měl
> kolega
> stejné auto, dík čemuž jsem si ho více všimnul, tak proč ne stejný program
> na
> telefonu/tabletu, že :-))
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Leonardo Brondani Schenkel]

Concordo, pois sou quem colocou a questão em votação.


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

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Martin Koppenhoefer]

2016-05-02 14:07 GMT+02:00 Marco Bartalini :

> penso ad esempio al fatto di lasciare visibili le linee elettriche e a non
> rendere visibili i cancelli ad esempio! che rabbia...




si, perché quella mappa è fatto da uno Svizzero, appunto per la Svizzera.
Per esempio in Germania (non so in Svizzera) tu puoi (a piedi) andare
(quasi) d'ovunque in campagna aperta, mentre in Italia quasi sempre trovi
tutto recintato (al meno qui vicino Roma). Il fattore regionale è
essenziale quando si mappa e quando si fa una mappa, e ovviamente tutti
partono (e spesso si fermano) da ciò che conoscono.

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

[Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Leonardo Brondani Schenkel]

Alguns voluntários da comunidade OSM Brasil (entre eles o autor desta 
votação) têm defendido na lista talk-br que o uso de 
`boundary=administrative` para as mesorregiões e microregiões criadas 
pelo IBGE não é apropriado, já que tais regiões têm fins apenas 
estatísticos e não administrativos; usar `boundary=administrative` para 
regiões que não são administrativas vai contra a definição e a intenção 
da tag.


A discussão aconteceu em abril de 2006 sob o tópico de "Limites de 
cidades com distritos", arquivada em: 
https://lists.openstreetmap.org/pipermail/talk-br/2016-April/thread.html


O objetivo desta votação é apenas para sondar o posicionamento da lista 
talk-br, do fórum brasileiro e portanto da comunidade OSM como um todo 
sobre esta questão. Caso haja um certo consenso que a representação não 
é apropriada, o próximo passo será a escrita de uma ou mais propostas 
formais de representação alternativa que não utilizem 
`boundary=administrative` e que serão apresentadas/discutidas na lista e 
colocadas em votação.


O que está em votação aqui é __única e exclusivamente__ se é apropriado 
o uso do `boundary=administrative` para as regiões do IBGE. Outros 
assuntos relacionados que foram mencionados na lista __não__ estão no 
escopo desta votação, entre eles:


- como representar sub-distritos
- como representar distritos
- como representar bairros
- como representar regiões (N/NE/CO/SE/S)
- se o Brasil deve ter 10 ou 11 valores para `admin_level`
- se os limites/bordas em si estão corretos

Em especial, esta votação __também não__ está propondo nenhuma solução 
específica nem uma alteração imediata de qualquer natureza nos dados.


Estas são justificativas que foram apresentadas na lista talk-br para 
colocar a questão em votação:


- As mesorregiões e microregiões do IBGE são apenas estatísticas e não 
têm função administrativa, conforme páginas do próprio governo [1] e 
[2],  conforme o relato (de segunda mão) da opinião de um membro da 
comunidade que é funcionário do próprio IBGE [3], e conforme o mapa 
político (cuja função é mostrar as divisões administrativas) do próprio 
IBGE [4]. Outro voluntário na lista talk-br citou a própria publicação 
do IBGE em 1989 que criou as divisões [5], onde se menciona a função 
estatística e não há menção da função administrativa. Além disso, 
ninguém na lista até o momento aparesentou um exemplo de mapa 
político/rodoviário (online ou não) onde tais regiões estão representadas.


  [1] 
http://metadados.ana.gov.br/geonetwork/srv/pt/metadata.show?id=68=simple:


  > As microrregiões integram a organização, o planejamento e a execução de
  > funções públicas de interesse comum, definidas por lei complementar
  > estadual. Entretanto, raras são as microrregiões assim definidas.
  > Consequentemente, o termo é muito mais conhecido em função de seu uso
  > prático pelo IBGE que, para fins estatísticos e com base em
  > similaridades econômicas e sociais, divide os diversos estados da
  > federação brasileira em microrregiões.

  [2] 
http://www.geografia.seed.pr.gov.br/modules/galeria/detalhe.php?foto=1586=8:


  > Mesorregião é uma subdivisão dos estados brasileiros que congrega
  > diversos municípios de uma área geográfica com similaridades econômicas
  > e sociais, que por sua vez, são subdivididas em microrregiões. Foi
  > criada pelo IBGE e é utilizada para fins estatísticos e não constitui,
  > portanto, uma entidade política ou administrativa.

  [3] 
https://lists.openstreetmap.org/pipermail/talk-br/2016-April/011302.html:


  > Estive conversando com um exímio mapeador aqui do OSM BR, que também
  > trabalha no IBGE. No entender dele e conforme seus conhecimentos na
  > área, micro e meso não são administrativos. Mas essa é a opinião dele.
  > Ele também concorda que subdistritos são sim níveis administrativos.

  [4] 
ftp://geoftp.ibge.gov.br/mapas_tematicos/mapas_murais/Brasil2500_2014/


  [5] 
https://lists.openstreetmap.org/pipermail/talk-br/2016-April/011310.html


- A documentação do `boundary=administrative` explica que o mesmo foi 
criado para representar limites __administrativos__ apenas [1], como diz 
claramente o primeiro parágrafo:


  [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative:

  > An administrative boundary. Subdivisions of 
areas/territories/jurisdictions
  > recognised by governments or other organisations for administrative 
purposes.

  > [Um limite administrativo. Subdivisões de áreas/territórios/jurisdições
  > reconhecidas por governos ou outras organizações para propósitos
  > administrativos.]

  A interpretação de que sub-divisões puramente estatísticas se 
encaixam na definição de `boundary=administrative` parece ser 
exclusivamente brasileira, de acordo com as tabelas [2] e [3]. Até o 
momento não há exemplo de outro país que codifica regiões puramente 
estatísticas usando `boundary=administrative`, o que indica que o uso 
brasileiro não segue a definição escrita nem a usada na prática e 

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Marco Bartalini]

Si infatti Martin dato questo lassismo da parte di chi fa le open mtb map
che contengono di tutto tranne che le cose più interessanti per i
ciclisti... penso ad esempio al fatto di lasciare visibili le linee
elettriche e a non rendere visibili i cancelli ad esempio! che rabbia...
L'unica cosa positiva che rimane è l'ottima visibilità degli sterrati... ho
deciso cmq che investirò inizialmente del tempo per cercare mappe
alternative, più a lungo termine ho intenzione seriamente di imparare a
farmi un rendering personalizzato... ho molte idee in questo campo per cui
credo che possa veramente essere d'aiuto... vediamo che succederà...




*Marco Bartalini,marcobartal...@gmail.com *

2016-05-01 15:44 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > Il giorno 01 mag 2016, alle ore 11:27, Volker Schmidt 
> ha scritto:
> >
> > In MTBmap, Felix Hartmann, l'autore cerca di offrire un prodotto
> pre-confezionato che va bene a un gran numero di clienti e per MTBmap ha
> cercato di includere dati su fonti di acqua, basandosi sul uso più
> frequente dei tag di OSM.
>
>
> su questo non sarei troppo sicuro, non è la prima volta che sento gente
> lamentandosi  delle sue mappe e della sua interpretazione dei tags, e lui
> ignora suggerimenti per risolvere problemi (cosa è il suo diritto). In ML
> avevo un po' l'impressione di un testardo che fa le cose come vuole lui
> fregandosi del resto ed insistente nel suo punto di vista (anche contro
> tanti). Ormai faccende di anni fa.
>
> ciao,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Is USBR 11 in Maryland complete/correct in OSM?

[Kerry Irons]

Just to echo Steve’s comment on signs: encouraged but not required.  Currently 
just under 18% of the USBRS is signed.  Budget is the issue, both at the state 
and local (non state highway) level.

 

 

Kerry

 

From: OSM Volunteer stevea [mailto:stevea...@softworkers.com] 
Sent: Sunday, May 1, 2016 8:26 PM
To: Elliott Plack 
Cc: Kerry Irons ; FTA/Ethan ; 
Wade ; Phil! Gold ; 
talk-us@openstreetmap.org
Subject: Re: Is USBR 11 in Maryland complete/correct in OSM?

 

Elliott Plack  > wrote:





Update on this. I was out along the AT in the Weverton area and had a chance to 
observe this unique condition where cyclists are encouraged to use what is 
effectively a motorway for travel.

 

I always found my armchair mapping of this highly suspect and so I added 
copious tags that it still needed additional editing.  >1.5 years later, 
Elliott submits nice, solid work after a field trip.  Well, all right!





There is no sign or specific indication of USBR 11 anywhere out there that I 
observed. What I did see was that the eastbound carriageway of US 340 had a 
green sign indicating that it was a bicycle route between the Keep Tryst Rd / 
Valley Rd intersection, and Exit 2, which had a sign indicating the bicycles 
must exit. The "Bike Route" signs did not have a number reference. There is a 
Bike Route sign on the exit to MD 67 as well, which is the part that is USBR 11.

 

Kerry might remind everybody that signage is optional (I would say “encouraged” 
but I don’t think that is official) on the USBRS.  The route exists by state 
DOT declaration and “acceptance” into the national (non) network (called USBRS) 
by AASHTO.  Signs cost money and effort to erect:  sometimes there is budget to 
do so and the state DOT finds a way to erect signs, sometimes signage is a more 
grass-roots effort (fundraising, sign-raising…) than it is state (DOT) 
sanctioned or funded.  A Bike Route sign is a legal, MUTCD-acceptable way to 
sign here but I think we all agree the M1-9 sign (USBR 11) would be preferred.





For the sections of US 340 where cyclists are allowed, I added the 
cycleway:right=shoulder tag. I also fixed any FIXMEs related to this condition.

 

Thank you, thank you.





Curiously, the eastbound carriageway is tagged as trunk, while the westbound is 
tagged motorway. While there is a single grade intersection along the eastbound 
portion (at Keep Tryst Rd), I think that this is probably not enough to call 
the entire section trunk. Thoughts on that?

 

You did the field trip!  The whole area around Keep Tryst Road and how it 
interfaces with AT and bicycles is complicated, and now seems much better 
tagged.





Finally, I also improved the routing of USBR 11 where it crosses the Potomac 
River on a shared-use rail bridge. There is a staircase to access the bridge 
that I added the steps tag too. I am not sure how bicycling routers, like OSRM 
or Strava will handle steps, but cyclists are allowed there provided they 
dismount (per signage).

 

There is also a lcm (local cycleway network) around here with a staircase, it 
is near the Santa Cruz Boardwalk at the mouth of the San Lorenzo River.  These 
things can get complicated, but I believe with the proper tagging of 
bicycle=dismount (to walk up or down stairs carrying your bicycle) that a 
router should be able to figure that out.  Especially if is part of a 
lcn/rcn/ncn.  Still, I wouldn’t mind a bicycle router showing “special” 
semiotics here (yellow or hatching or something like that).





I have mapped my observations with this changeset: 
http://www.openstreetmap.org/changeset/39027403

 

Deeply appreciated.  This tagging and routing were a little sticky here, and 
now are much better.

 

SteveA

California

USBRS WikiProject coordinator

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

Re: [Talk-it] sentiero con variante

[Volker Schmidt]

Non penso che sia coretto di mettere una relazione dentro un'altra come
membro. Se vuoi puoi utilizzare una super-relation per contenere entrambi.
Ma di quello che so le super-relazioni non sono ancora supportate bene da
vari siti.
Vedi http://wiki.openstreetmap.org/wiki/Super-Relation

2016-05-02 13:24 GMT+02:00 demon.box :

> scusate, prob non mi sono spiegato bene...
>
> la variante è una nuova relazione a sè stante soltanto che la metto (come
> intera relazione) anche membro della relazione del sentiero principale.
>
> è una modalità che tra l'altro ho trovato già impostata su alcuni percorsi
> della mia zona (questo non significa per forza che fosse corretto).
>
> riepilogando:
>
> Sentiero principale 370
> RELAZIONE A
>
> Variante del sentiero principale 370B
> RELAZIONE B
> membro di RELAZIONE A
>
>
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/sentiero-con-variante-tp5872795p5872871.html
> Sent from the Italy General mailing list archive at Nabble.com.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] sentiero con variante

[Martin Koppenhoefer]

2016-05-02 13:24 GMT+02:00 demon.box :

> scusate, prob non mi sono spiegato bene...
>
> la variante è una nuova relazione a sè stante soltanto che la metto (come
> intera relazione) anche membro della relazione del sentiero principale.
>
> è una modalità che tra l'altro ho trovato già impostata su alcuni percorsi
> della mia zona (questo non significa per forza che fosse corretto).
>
> riepilogando:
>
> Sentiero principale 370
> RELAZIONE A
>
> Variante del sentiero principale 370B
> RELAZIONE B
> membro di RELAZIONE A
>
>

io non lo farei (mettere 370B dentro 370).
Non vedo cosa si guadagna, ma vedo i problemi che si creano quando una
"route" non è lineare (difficoltà dei vari tool di verifica).

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

[Talk-br] Dados de cartografia da Prefeitura de Porto Alegre / Importação Prédios - preparação

[Sérgio V .]

Bom dia e bom começo semana, pessoal.

Uma pergunta:


Sobre a importação dos prédios em PoA, já importei no Centro Histórico (+/- 
3500 construções novas), converti o que havia de tag compatível e com sentido 
para o OSM.


Estou pensando no seguinte para as restantes construções no mapa cadastral da 
PMPA:


São +/-500.000 (mil) construções de todo tipo no cadastro da PMPA;  eles 
mapearam tudo, até construções secundárias de serviço, depósito no pátio, 
casinha de cachorro, etc.


Uma vez que o OSM a princípio não tem o propósito de ser como um mapa cadastral 
tão detalhado quanto de uma prefeitura, estou pensando em separar e remover da 
camada a ser importada toda construção menor que 2x2m (cerca de 4m², ou soma do 
comprimento de linha 8m), ou seja, o que for inabitável. Creio que reduza um 
tanto o pesado volume de dados. Que acham?


1) Sabem se no QGIS há uma maneira de filtrar isto (por área ou por somatório 
de comprimento de linha)?


2) No QGIS fiz a troca na tabela de dados dos "nomes dos campos "para as "KEYS" 
compatíveis com o OSM (ex: de "CLASSE" para "bulding").

Mas quanto aos "valores" dos  atributos ("VALUES"), sabem se há uma maneira 
dentro do QGIS de substituir todos os "valores" idênticos na tabela de dados 
(ex.: tudo que for "ESCOLA" para "school")?

Ou tem que editar o .DBF fora do QGIS, subsituir os "values", e depois acoplar 
novamente (mas e o risco de dar bagunça no SHP)? Se sim, com qual software?


Antecipadamente obrigado,


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

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

Re: [Talk-cz] Rozcestníky-focení-ztráta dat-záchrana?

[Marek Janata]

nejvíc úspěchů jsem měl s recoverjpeg
https://www.rfc1149.net/devel/recoverjpeg.html - pak výše zníměný testdisc,
foremost (všechno pod linuxem) a podobně

ale udělej si před tím zálohu karty ať to nedorazíš...

po 2. 5. 2016 v 12:12 odesílatel Lukáš Kohout  napsal:

> Na Windows lze k bitové kopii použít Win32Diskimager.
>
>
> Dne 2. května 2016 11:07 Karel Volný  napsal(a):
>
> zdravím,
>>
>> bez ohledu na to, jaký software se na to pustí dál, zásadní věc je
>> zkopírovat
>> kartu a pracovat pouze nad kopií (resp. kopiemi), aby se to nerozbilo
>> ještě
>> víc
>>
>> pro wokna neporadím, na linuxu něco jako `dd if=/dev/mmcblk0 of=kopie.img`
>> (pozn. výše uvedené zkopíruje celou kartu, nikoliv jenom partition, takže
>> potom na tom některé nástroje nemusí rozpoznat souborový systém; pro
>> zkopírování pouze příslušné partition použít mmcblk0p0 nebo mmcblk0p1,
>> podle
>> toho jak je naformátovaná)
>>
>> na vytažení souborů z neopravitelně rozpadeného souborového systému se mi
>> osvědčil `foremost`, ale to je většinou až poslední možnost, většinu
>> "neopravitelných" problémů zvládne triviálně `fsck`
>>
>> K.
>>
>> Dne Po 2. května 2016 00:45:55, Petr Vozdecký napsal(a):
>> > Ahoj,
>> >
>> > prosím radu - celá moje dnešní práce s 30 km výjezdem na kole s
>> rodinkou za
>> > odlovem rozcestníků (lokalita Skalka-lázně, okr. Prostějov) je ohrožena,
>> > ukládám totiž na microSD 32 GB a ta se po ukončení akce rozhodla, že
>> nebude
>> > komunikovat. Ve WIN7 sděluje něco ve smylu "médium v jednotce není
>> > naformátováno". SW typu Recuva a Restoration tvrdí že nic nezachrání,
>> > protože nerozpoznali souborový formát...
>> >
>> > Nějaká zkušenost? Nějaká rada? Krom "zajeď tam znovu"...
>> >
>> > Díky, vop
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] sentiero con variante

[demon.box]

scusate, prob non mi sono spiegato bene...

la variante è una nuova relazione a sè stante soltanto che la metto (come
intera relazione) anche membro della relazione del sentiero principale.

è una modalità che tra l'altro ho trovato già impostata su alcuni percorsi
della mia zona (questo non significa per forza che fosse corretto).

riepilogando:

Sentiero principale 370
RELAZIONE A

Variante del sentiero principale 370B
RELAZIONE B
membro di RELAZIONE A






--
View this message in context: 
http://gis.19327.n5.nabble.com/sentiero-con-variante-tp5872795p5872871.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-se] Nyare Mapbox satellitbilder

[Kristoffer Malmström]

Längs gävle och upplands kusten finns tyärr inga nya mapbox bilder.

*Med vänliga hälsningar*
*Kristoffer Malmström*
Tel: 0733690161

Den 2 maj 2016 09:04 skrev Martin Norbäck Olivers :

> Tack för tipset! Det finns jättefina mapbox-bilder på mina kvarter nu!
>
> Passningen verkar också i det närmaste perfekt.
>
> Hälsningar Martin
>
> Den 2 maj 2016 08:36 skrev Christian Asker :
>
>> Hej på er. Jag såg precis att det runt min hemort har kommit fräschare
>> Mapbox-satellitbilder. Förut var dom nästan helt oanvändbara, men nu är dom
>> nästan hyfsade. Dessvärre är det svårt att justera in en bra offset
>> eftersom jag inte riktigt vet vilka punkter i OSM-datat som är mest
>> tillförlitliga.
>> Ni som också saknat bra Mapbox-satellitbilder kan ju kika ifall ni också
>> har fått fräschare bilder.
>>
>> Jag tror att jag ska göra en liten lokal mätkampanj där jag mäter upp ett
>> par korsningar eller liknande ett antal gånger. Sen kan jag passa in
>> satellitbildernas offset mot dessa.
>>
>> Mvh Christian
>>
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
>
>
>
> --
> Martin Norbäck Olivers
> IT-konsult, Masara AB
> Telefon: +46 703 22 70 12
> E-post: mar...@norpan.org
> Kärrhöksvägen 4
> 656 72 Skattkärr
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-cz] Rozcestníky-focení-ztráta dat-záchrana?

[Lukáš Kohout]

Na Windows lze k bitové kopii použít Win32Diskimager.


Dne 2. května 2016 11:07 Karel Volný  napsal(a):

> zdravím,
>
> bez ohledu na to, jaký software se na to pustí dál, zásadní věc je
> zkopírovat
> kartu a pracovat pouze nad kopií (resp. kopiemi), aby se to nerozbilo ještě
> víc
>
> pro wokna neporadím, na linuxu něco jako `dd if=/dev/mmcblk0 of=kopie.img`
> (pozn. výše uvedené zkopíruje celou kartu, nikoliv jenom partition, takže
> potom na tom některé nástroje nemusí rozpoznat souborový systém; pro
> zkopírování pouze příslušné partition použít mmcblk0p0 nebo mmcblk0p1,
> podle
> toho jak je naformátovaná)
>
> na vytažení souborů z neopravitelně rozpadeného souborového systému se mi
> osvědčil `foremost`, ale to je většinou až poslední možnost, většinu
> "neopravitelných" problémů zvládne triviálně `fsck`
>
> K.
>
> Dne Po 2. května 2016 00:45:55, Petr Vozdecký napsal(a):
> > Ahoj,
> >
> > prosím radu - celá moje dnešní práce s 30 km výjezdem na kole s rodinkou
> za
> > odlovem rozcestníků (lokalita Skalka-lázně, okr. Prostějov) je ohrožena,
> > ukládám totiž na microSD 32 GB a ta se po ukončení akce rozhodla, že
> nebude
> > komunikovat. Ve WIN7 sděluje něco ve smylu "médium v jednotce není
> > naformátováno". SW typu Recuva a Restoration tvrdí že nic nezachrání,
> > protože nerozpoznali souborový formát...
> >
> > Nějaká zkušenost? Nějaká rada? Krom "zajeď tam znovu"...
> >
> > Díky, vop
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Rozcestníky-focení-ztráta dat-záchrana?

[Karel Volný]

zdravím,

bez ohledu na to, jaký software se na to pustí dál, zásadní věc je zkopírovat 
kartu a pracovat pouze nad kopií (resp. kopiemi), aby se to nerozbilo ještě 
víc

pro wokna neporadím, na linuxu něco jako `dd if=/dev/mmcblk0 of=kopie.img`
(pozn. výše uvedené zkopíruje celou kartu, nikoliv jenom partition, takže 
potom na tom některé nástroje nemusí rozpoznat souborový systém; pro 
zkopírování pouze příslušné partition použít mmcblk0p0 nebo mmcblk0p1, podle 
toho jak je naformátovaná)

na vytažení souborů z neopravitelně rozpadeného souborového systému se mi 
osvědčil `foremost`, ale to je většinou až poslední možnost, většinu 
"neopravitelných" problémů zvládne triviálně `fsck`

K.

Dne Po 2. května 2016 00:45:55, Petr Vozdecký napsal(a):
> Ahoj,
> 
> prosím radu - celá moje dnešní práce s 30 km výjezdem na kole s rodinkou za
> odlovem rozcestníků (lokalita Skalka-lázně, okr. Prostějov) je ohrožena,
> ukládám totiž na microSD 32 GB a ta se po ukončení akce rozhodla, že nebude
> komunikovat. Ve WIN7 sděluje něco ve smylu "médium v jednotce není
> naformátováno". SW typu Recuva a Restoration tvrdí že nic nezachrání,
> protože nerozpoznali souborový formát...
> 
> Nějaká zkušenost? Nějaká rada? Krom "zajeď tam znovu"...
> 
> Díky, vop


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

Re: [Talk-us] Colorado mappers: Check your notes carefully

[Richard Fairhurst]

SteveA wrote:
> [Great Divide Mountain Bike Route]
> where MountainAddict keeps setting this to network=ncn 
> when clearly it is network=icn (as it crosses the Canadian 
> border in Alberta).  A partial compromise/consensus 
> solution has emerged:  keep a duplicate relation synced as 
> route=mtb.  OK, that makes sense.

Yes.

It shouldn't really be route=bicycle at all. route=bicycle generally implies
a designated (and, in other parts of the world, signposted) bicycle route
which has been assessed for safety and other suitability for general-purpose
bicycles. Bike routers can and do give such routes preferential weighting.

The GDMBR isn't such a route. It should be route=mtb, not route=bicycle,
because it's meant for MTBs - not just "bicycles". I understand that the
original GDMBR mapper was unhappy with route=mtb as it didn't render
prominently on OpenCycleMap, but that's now been fixed so shouldn't be an
issue.

That said, life is too short to get into edit wars on such things, so I was
happy with just having a manual override in cycle.travel's US routing
profile:

if route_ref=='GDM' then
-- ignore this route
else
-- 

...until someone decided to change the ref from GDM to GDMBR. :|

cheers
Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Colorado-mappers-Check-your-notes-carefully-tp5872836p5872870.html
Sent from the USA mailing list archive at Nabble.com.

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

Re: [Talk-cz] Rozcestníky-focení-ztráta dat-záchrana?

[Pavel Machek]

Ahoj!


> prosím radu - celá moje dnešní práce s 30 km výjezdem na kole s rodinkou za 
> odlovem rozcestníků (lokalita Skalka-lázně, okr. Prostějov) je ohrožena, 
> ukládám totiž na microSD 32 GB a ta se po ukončení akce rozhodla, že nebude 
> komunikovat. Ve WIN7 sděluje něco ve smylu "médium v jednotce není 
> naformátováno". SW typu Recuva a Restoration tvrdí že nic nezachrání, 
> protože nerozpoznali souborový formát...
> 
> Nějaká zkušenost? Nějaká rada? Krom "zajeď tam znovu"...

Hlavne ne testdisk :-).

recoverjpeg -- vytahne fotky bez ohledu na souborovy filesystem. Bud
pomuze, a nebo je to "zaplat velmi velmi drahou zachranu dat", a nebo
spis "zajed tam znovu" :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Talk-cz] Mapa ZSJ

[Jan Dudík]

V minulosti fungovala mapa na adrese
http://maps.fordfrog.com/
kde byly vidět i hranice ZSJ.

TA už nefunguje - nevíte o nějaké jiné mapě s ttěmito hranicemi?

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

Re: [Talk-se] Nyare Mapbox satellitbilder

[Martin Norbäck Olivers]

Tack för tipset! Det finns jättefina mapbox-bilder på mina kvarter nu!

Passningen verkar också i det närmaste perfekt.

Hälsningar Martin

Den 2 maj 2016 08:36 skrev Christian Asker :

> Hej på er. Jag såg precis att det runt min hemort har kommit fräschare
> Mapbox-satellitbilder. Förut var dom nästan helt oanvändbara, men nu är dom
> nästan hyfsade. Dessvärre är det svårt att justera in en bra offset
> eftersom jag inte riktigt vet vilka punkter i OSM-datat som är mest
> tillförlitliga.
> Ni som också saknat bra Mapbox-satellitbilder kan ju kika ifall ni också
> har fått fräschare bilder.
>
> Jag tror att jag ska göra en liten lokal mätkampanj där jag mäter upp ett
> par korsningar eller liknande ett antal gånger. Sen kan jag passa in
> satellitbildernas offset mot dessa.
>
> Mvh Christian
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>



-- 
Martin Norbäck Olivers
IT-konsult, Masara AB
Telefon: +46 703 22 70 12
E-post: mar...@norpan.org
Kärrhöksvägen 4
656 72 Skattkärr
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-it] OSMit 2016: dove dormire

[Alessandro Palmas]

Il 02/05/2016 08:23, Luca Delucchi ha scritto:

Quanto chiedevano?



50 in doppia, 40 in tripla o quadrupla.


a testa o a camera?



A testa, fosse stato a camera mi ci sarei tuffato :-)



Il secondo posto che avevo indicato ha camerate da 6 a 20€ cad.



se ci siamo possiamo anche prenotare una camerata ...



Il Lumiere chiede 22€ a testa, pare siano camere da 6 e forse anche da 4
E' a 3km da BaSe, o 7 fermate di metro.


Qualcuno in lista che si accoda?

Alessandro Ale_Zena

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

[Talk-se] Nyare Mapbox satellitbilder

[Christian Asker]

Hej på er. Jag såg precis att det runt min hemort har kommit fräschare 
Mapbox-satellitbilder. Förut var dom nästan helt oanvändbara, men nu är 
dom nästan hyfsade. Dessvärre är det svårt att justera in en bra offset 
eftersom jag inte riktigt vet vilka punkter i OSM-datat som är mest 
tillförlitliga.
Ni som också saknat bra Mapbox-satellitbilder kan ju kika ifall ni också 
har fått fräschare bilder.


Jag tror att jag ska göra en liten lokal mätkampanj där jag mäter upp 
ett par korsningar eller liknande ett antal gånger. Sen kan jag passa in 
satellitbildernas offset mot dessa.


Mvh Christian

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

Re: [Talk-it] OSMit 2016: dove dormire

[Luca Delucchi]

2016-04-30 20:25 GMT+02:00 Alessandro Palmas :
> Il 30/04/2016 18:35, Luca Delucchi ha scritto:
>>
>>
>>
>> Il 29/apr/2016 08:11 PM, "Alessandro Palmas"
>> > ha
>> scritto:
>> >
>> >
>> > Mmh, avendo anche le camere non penso che lascino dormire all'interno.
>> > Martedì se riesco a parlargli (sono ancora nel pieno delirio per il termine
>> > dei lavori) gli chiedo se ci fanno dello sconto rispetto ai prezzi che mi
>> > avevano detto
>> >
>>
>> Quanto chiedevano?
>>
>>
> 50 in doppia, 40 in tripla o quadrupla.
>

a testa o a camera?

> Il secondo posto che avevo indicato ha camerate da 6 a 20€ cad.
>
>

se ci siamo possiamo anche prenotare una camerata ...

-- 
ciao
Luca

www.lucadelu.org

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