Re: [talk-au] City of Melbourne data

[Steve Bennett]

Awesome! I sit with the GIS team, so if you need any information about the
spatial data or any questions, don't hesitate.

We have quite a few identifiers of various types (asset IDs, property IDs
etc), so it may be helpful to import those to facilitate future updates?

Another couple of datasets to look at are the bar/tavern/pub and
cafe/restaurant ones. They're comprehensive lists of every establishment of
those types across the whole municipality, updated on a rolling cycle every
2 years.

Steve

On Mon, Dec 19, 2016 at 1:22 PM, Daniel O'Connor 
wrote:

> I'll put my hand up for (slowly) importing addresses; have begun sketching
> out a plan in https://wiki.openstreetmap.org/wiki/Import/Catalogue/
> data.melbourne.vic.gov.au-addresses
>
> Dataset:
> https://data.melbourne.vic.gov.au/Property-Planning/
> Address-Points/a7rp-xtya
>
> Sent email re explicit permission (all datasets), will add to wiki.
>
>
> On Mon, Dec 19, 2016 at 12:07 PM, Daniel O'Connor <
> daniel.ocon...@gmail.com> wrote:
>
>> A good dataset may be address point data, if available. I know we have
>> GNAF, but we've been unable to get the explicit permission needed.
>>
>> Coverage is OK at the moment, so any import would be better as a
>> semi-manual, street by street kind of thing.
>>
>>
>> Public toilets, BBQs, Playgrounds, Park names, etc also spring to mind.
>>
>>
>> On Mon, Dec 19, 2016 at 11:55 AM, Steve Bennett 
>> wrote:
>>
>>> Hi all,
>>>   I'm a long time contirbutor (user:Stevage) but a bit quiet of late.
>>> I'm now working as Senior Open Data Specialist at City of Melbourne (email:
>>> opend...@melbourne.vic.gov.au), and have just got approval for our data
>>> to be used in OpenStreetMap.
>>>
>>> So: If someone would like to email that address and formally request
>>> permission to use current and future open data in OSM, I'd be very happy to
>>> respond in the affirmative.
>>>
>>> Also: is anyone interested in importing any of our data? You can see
>>> most of our public spatial data at maps.melbourne.vic.gov.au (to
>>> actually access it, go to data.melbourne.vic.gov.au). If there is
>>> interesting data on the maps site that's not on the open data portal, we'll
>>> prioritise getting it out.
>>>
>>> Perhaps some of the street furniture datasets (bike hoops, water
>>> fountains etc) would be good starting points?
>>>
>>> Steve
>>>
>>>
>>>
>>> ___
>>> Talk-au mailing list
>>> Talk-au@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>>
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-pe] Recordatorio reunión 19 diciembre 2016

[Runa Yachaq]

http://osmpe.ourproject.org/#sthash.7HQHWXX6.dpbs

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

Re: [talk-au] City of Melbourne data

[Daniel O'Connor]

I'll put my hand up for (slowly) importing addresses; have begun sketching
out a plan in
https://wiki.openstreetmap.org/wiki/Import/Catalogue/data.melbourne.vic.gov.au-addresses

Dataset:
https://data.melbourne.vic.gov.au/Property-Planning/Address-Points/a7rp-xtya

Sent email re explicit permission (all datasets), will add to wiki.


On Mon, Dec 19, 2016 at 12:07 PM, Daniel O'Connor 
wrote:

> A good dataset may be address point data, if available. I know we have
> GNAF, but we've been unable to get the explicit permission needed.
>
> Coverage is OK at the moment, so any import would be better as a
> semi-manual, street by street kind of thing.
>
>
> Public toilets, BBQs, Playgrounds, Park names, etc also spring to mind.
>
>
> On Mon, Dec 19, 2016 at 11:55 AM, Steve Bennett 
> wrote:
>
>> Hi all,
>>   I'm a long time contirbutor (user:Stevage) but a bit quiet of late. I'm
>> now working as Senior Open Data Specialist at City of Melbourne (email:
>> opend...@melbourne.vic.gov.au), and have just got approval for our data
>> to be used in OpenStreetMap.
>>
>> So: If someone would like to email that address and formally request
>> permission to use current and future open data in OSM, I'd be very happy to
>> respond in the affirmative.
>>
>> Also: is anyone interested in importing any of our data? You can see most
>> of our public spatial data at maps.melbourne.vic.gov.au (to actually
>> access it, go to data.melbourne.vic.gov.au). If there is interesting
>> data on the maps site that's not on the open data portal, we'll prioritise
>> getting it out.
>>
>> Perhaps some of the street furniture datasets (bike hoops, water
>> fountains etc) would be good starting points?
>>
>> Steve
>>
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] City of Melbourne data

[Daniel O'Connor]

A good dataset may be address point data, if available. I know we have
GNAF, but we've been unable to get the explicit permission needed.

Coverage is OK at the moment, so any import would be better as a
semi-manual, street by street kind of thing.


Public toilets, BBQs, Playgrounds, Park names, etc also spring to mind.


On Mon, Dec 19, 2016 at 11:55 AM, Steve Bennett  wrote:

> Hi all,
>   I'm a long time contirbutor (user:Stevage) but a bit quiet of late. I'm
> now working as Senior Open Data Specialist at City of Melbourne (email:
> opend...@melbourne.vic.gov.au), and have just got approval for our data
> to be used in OpenStreetMap.
>
> So: If someone would like to email that address and formally request
> permission to use current and future open data in OSM, I'd be very happy to
> respond in the affirmative.
>
> Also: is anyone interested in importing any of our data? You can see most
> of our public spatial data at maps.melbourne.vic.gov.au (to actually
> access it, go to data.melbourne.vic.gov.au). If there is interesting data
> on the maps site that's not on the open data portal, we'll prioritise
> getting it out.
>
> Perhaps some of the street furniture datasets (bike hoops, water fountains
> etc) would be good starting points?
>
> Steve
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] City of Melbourne data

[Steve Bennett]

Hi all,
  I'm a long time contirbutor (user:Stevage) but a bit quiet of late. I'm
now working as Senior Open Data Specialist at City of Melbourne (email:
opend...@melbourne.vic.gov.au), and have just got approval for our data to
be used in OpenStreetMap.

So: If someone would like to email that address and formally request
permission to use current and future open data in OSM, I'd be very happy to
respond in the affirmative.

Also: is anyone interested in importing any of our data? You can see most
of our public spatial data at maps.melbourne.vic.gov.au (to actually access
it, go to data.melbourne.vic.gov.au). If there is interesting data on the
maps site that's not on the open data portal, we'll prioritise getting it
out.

Perhaps some of the street furniture datasets (bike hoops, water fountains
etc) would be good starting points?

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

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

[Philippe Verdy]

Numericable a aussi des armoires fibre/fibre entre les quartiers, les
armoires FTTLA (fibre/coax) sont les plus nombreuses, mais pas toujours sur
la rue, elles peuvent être dans les parties communes (privées) d'immeubles
collectifs (et dans certains cas peuvent desservir plusieurs immeubles
proches d'un même ensemble (par exemple un immeuble et des maisons
individuelles d'une même copropriété: J'ai été dans ce cas à
Asnières-sur-Seine, la fibre arrivant directement dans l'immeuble même si
la distribution se faisait en coax via les gaines communes de l'ancienne
installation d'antenne collective, en parallèle de celle-ci dans
l'immeuble, mais à la place du coax d'antenne pour les maisons
individuelles de la copro: Numericable n'a posé aucun autre câble coax il
s'en branché sur les câbles existants qui étaient déjà doublés dans
l'immeuble car à l'origine il y avait deux antennes, une pour l'UHF et
l'autre pour la VHF et la FM mais il n'y en avait plus qu'une d'utilisée
depuis la fin de l'UHF et on avait une prise coax inutilisée qui a servi
ensuite spour Numericable sans débrancher l'antenne collective).

Dans d'autres cas, Numericable se branche sur la distributions d'antenne
collective en la remplaçant: là encore Numericable ne pose aucun coax, il
alimente un signal en clair pour les chaines TNT, et sinon le reste est
utilisé pour l'internet parmi les canaux libres (y compris en UHF
puisqu'elle ne sert plus pour la TNT hertzienne). C'est le coupleur FTTLA
qui détermine les canaux à utiliser pour la distribution finale, mais en
général Numéricable évite les canaux TNT, mais va ajouter aussi quelques
canaux gratuits promotionnels en clair, même pour les non abonnés qui
peuvent voir ces quelques chaines en plus directement avec leur prise
antenne (ces chaines ce sont celles du portail de présentation commercial
et quelques chaines SD du groupe, leur nombre peut varier localement en
fonction des canaux utilisables. Le FTTLA cependant n'utilise pas tous les
canaux UHF non utilisés par la TNT pour y loger le signal "fibre", même
pour ceux qui sont éligible aux 200Mgabits/s, ce qui fait que le plan de
fréquences est en général claqué directement sur le plan de fréquence
général d'une ville en TNT, pour déterminer les canaux pour l'Internet.

Numéricable cependant ne tient plus compte des relais TNT locaux qui
peuvent exister dans certains quartiers, il envoie sur le câble toutes les
chaines TNT en clair qu'on peut utiliser sans son décodeur, directement en
branchant la télé sur la même prise antenne (il est rare qu'on ait besoin
de changer les fréquences entre la réception par l'ancienne antenne
collective et celle venant du coupleur FTTLA, mais si ça arrive ce n'est
qu'une question de recherche des nouvelles chaines et ça suit les mêmes
évolutions que le plan hertzien reçu sur sa tête de réseau et encodé/copié
tel quel sur la tête fibre, et décodé automatiquement dans son coupleur
FTTLA pour tous les résidents abonnés ou pas à Numéricable qui devient
alors l'opérateur "antenniste" chargé par la copropriété d'assurer le
"droit légal à l'antenne" pour tous, à la même manière qu'un autre
antenniste qui s'occupait avant d'une installation d'antenne collective
hertzienne, cependant certaines copropriétés conservent leur installation
hertzienne collective quand il y a déjà du câblage existant pour une autre
ancienne antenne, qui sert encore pour capter la radio FM et dont NC ne
s'occupera pas du tout)... Dans le passé NC gérait des plans de fréquences
plus compliqués immeuble par immeuble (à cause de la complexité
d'attribution des anciens canaux TNT et SECAM d'avant la TNT). NC a arrêté
cependant de distribuer les signaux SECAM bien après sa coupure sur le
réseau hertzien public. De fait pour régler son téléviseur ou sa box, il ne
demande plus le numéro d'installation mais juste un code postal ce qui
suffit presque partout à donner le plan de fréquences pour la TNT et pour
les canaux Internet. De plus, comme les téléviseurs TNT, les box de NC sont
capables d'autodétecter les canaux pour l'Internet et les discriminer des
canaux des multiplex TNT (c'est d'autant plus facile avec la nouvelle norme
TNT et l'adoption du nouveau protocole DOCSIS pour la partie Internet,
alors que c'était compliqué quand il y avait encore des signaux analogiques
SECAM).



Le 18 décembre 2016 à 20:49,  a écrit :

>
>
> Le 18/12/2016 à 18:54, François Lacombe - fl.infosrese...@gmail.com a
> écrit :
>
>
> Pourquoi pas
> Une proposition est toujours en draft sur ce sujet :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop
>
> On pensait à telecom:medium=fiber... voire medium=fiber directement.
> Comme dit en 2014, ca n'est pas un caractère de l'armoire mais la
> description du réseau qui passe à l'intérieur : plusieurs réseaux
> s'appuyant sur des medium différents peuvent passer.
> C'est le cas dans les armoires Numéricâble où est faite la transition
> coax/fibre.
> On devrait trouver 

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Sim, de fato, tava vendo melhor agora, o lado já viria certo (problema é 
atribuir o sentido do menor/maior):

-o TXT traz a numeração do endereço, com número do setor,  quadra e face (mas 
não traz coordenadas);

-que correspondem no SHP ao valor de "CD_GEO" (as linhas das faces já 
georreferenciadas).


Assim, sejam ímpares ou pares ou misturados, já correspondem ao código do lado 
certo da rua (face).


EXEMPLO:
PORTO ALEGRE - FACE DE QUADRA DO MUSEU JULIO DE CASTILHOS: RUA DUQUE DE CAXIAS 
1205
(MAS PODERIA SER QUALQUER CIDADE)


TXT: (não tem coordenadas)

-Posição Inicial 1 (Códigos UF, município, distrito, subdistrito, setor)= 
43149020562

-Posição Inicial 67 (Nome do logradouro)=DE CAXIAS

-Posição Inicial 127(NÚMERO NO LOGRADOURO)=1205

-Posição Inicial 545 (Quadra e Face)= 001004


SHP:  "CD_GEO"=43149020562001004 (=aos valores de [1...;545...] do TXT)


O que precisaria fazer (automatizar):

-(no TXT) selecionar todas as "faces de quadras" da "mesma rua" (Nome do 
logradouro + distrito, subdistrito...);

-destas, selecionar todos os "números  no logradouro" de cada face de quadra e 
destacar "o maior e o menor";

-(no SHP) copiar os valores  de maior e menor número do TXT para cada linha de 
face no SHP;

-ordenar as faces segundo os  "números  no logradouro";

-atribuir sentido às linhas, em ordem;

-atribuir a cada face do SHP, em sequencia, 2 novos campos com os valores para 
 e  

(ou já adicionar direto um campo (addr_inter) com os valores para 
-).


Depois só trocar o nome no JOSM para addr:interpolation.

Ficaria pronto para examinar no JOSM com o existente, validar e importar.


Mas não sei como automatizar aquilo ali  :-P


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

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

Re: [OSM-talk] Key:Destination Abbreviations

[Dave F]

On 18/12/2016 23:12, Andy Mabbett wrote:

On 18 December 2016 at 21:40, Edwin Smith  wrote:


1) Destination is for the use of the navigation program.

That's a form of "tagging for the renderer".

Besides, if you wan to record, literally, what's on a sign, use
something like 'transcription='



There is absolutely nothing wrong with "tagging for the 
renderer/router". *Every* tag is to allow them to adapt the data into 
coherent maps, if not everything would be black & white & all roads 
would lead to Rome..


Tagging *incorrectly* for the renderer is, however, to be discouraged.

DaveF.

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


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

Re: [OSM-talk] Key:Destination Abbreviations

[Colin Smale]

I believe the phrase is "tagging wrongly for the renderer" - we
constantly consider the users/consumers of the data when tagging, but it
is clearly frowned upon to "lie" in the tagging to get something to show
up in a particular way or otherwise to achieve a particular effect.
Whether tagging is "correct" or not depends entirely on your frame of
reference. The destination of a road can also be derived geometrically
by following the road to see where it leads, but that would not be at
all useful or appropriate to the navigation use case.

 //colin 

On 2016-12-19 00:12, Andy Mabbett wrote:

> On 18 December 2016 at 21:40, Edwin Smith  wrote:
> 
>> 1) Destination is for the use of the navigation program.
> 
> That's a form of "tagging for the renderer".
> 
> Besides, if you wan to record, literally, what's on a sign, use
> something like 'transcription='___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Andy Mabbett]

On 18 December 2016 at 21:40, Edwin Smith  wrote:

> 1) Destination is for the use of the navigation program.

That's a form of "tagging for the renderer".

Besides, if you wan to record, literally, what's on a sign, use
something like 'transcription='

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

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

Re: [OSM-talk-fr] Routes manquantes... et carreaux INSEE

[Christian Quest]

C'est rare, mais ça arrive... les données carroyées de l'INSEE ont parfois
quelques pétouilles, dans ce cas, indiquer un "faux positif" dans osmose.

Le 18 décembre 2016 à 23:10, Laurent Combe  a écrit :

> bonjour,
>
> en essayant d'apporter ma contribution à cet objectif
> je suis tombé sur ça :
> http://tile.openstreetmap.fr/?zoom=16=44.3368=3.
> 04921=B000TF
>
> osmose signale la carreau comme desservi
> mais il semble surtout que le carreau soit "mal placé"
>
> c'est possible une erreur de la sorte ?
> et que faut-il faire dans ce cas-là ?
>
> Le 18 décembre 2016 à 16:44, Christian Quest  a
> écrit :
> > On est passé en dessous de la barre des 1000 soit maintenant moins de
> > 100.000 habitants sans route dans OSM pour aller chez eux...
> >
> > On tient le bon bout ! :)
> >
> > http://osmose.openstreetmap.fr/fr/errors/?item=7170=1
> > http://osm2020.free.fr/qa-commune/popux-france.png
> >
> >
> > --
> > 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
>



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

Re: [Talk-GB] OSM UK Local Chapter now officially exists

[Rob Nickerson]

Brian,

That's great news - quicker than we were expecting :-)

Yesterday (Saturday), I set a basic website up as the one Dennis did had
gone offline after a period of inactivity. Hopefully Dennis will point the
osmuk.org domain to it early in the week. I already have one edit to make
after this news!

As far as other tasks, I think we suggested:

- Start signing up members on a free plan until prices set at first meeting.
- Research bank accounts so that this can be put to members at the first
meeting.
- Find a venue for the first meeting.

Was there anything else?

Regards,
*Rob*

p.s. A merry Christmas to all :-D
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] USGS Large-Scale Imagery degraded this month :(

[TC Haddad]

http://www.directionsmag.com/pressreleases/usgs-cutting-high-resolution-ortho-imagery-program/479365



On Sun, Dec 18, 2016 at 11:59 AM, Ian Dees  wrote:

> I run the tile.openstreetmap.us server and noticed this change. Thanks
> for finding the USGS link: I saw it a while ago but then couldn't find it
> when I was trying to debug the problems with the server. The
> "usgs_large_scale" layer on tile.openstreetmap.us is now caching the
> USGSNAIPPlus layer, but the URL they provide both has worse imagery and is
> run from a much slower server (so my caching operation takes quite a bit
> longer and results in occasional 404s to the end user).
>
> I will try to contact a couple of the folks I know at USGS (maybe they're
> still on this list and could respond?), but it might be the case that we
> need to request the imagery and build the desired layer ourselves...
>
> On Sun, Dec 18, 2016 at 2:43 PM, David Kewley 
> wrote:
>
>> For a lot of my satellite imagery tracing, I've found it very useful to
>> go back and forth between Bing and USGS Large-Scale Imagery, which provides
>> at least 1-m resolution across the U.S., and in some areas (e.g. urban
>> areas) provides nice 1-foot resolution orthoimagery that aligns very well
>> in my local area with Bing imagery.
>>
>> Well, I should say "provided", past tense. For the past couple of weeks
>> or so, I've noticed that the the USGS LSI has seemed to degrade in many of
>> my local imagery tiles, and I've finally looked into why that might be so.
>>
>> For example, at this location, today (current state of imagery tile
>> caching, perhaps mostly local to me?)
>>
>> https://www.openstreetmap.org/edit?changeset=44464607#map=19
>> /33.56194/-117.67451
>>
>> when using USGS LSI, I see the NE, NW, and SW imagery tiles look fine,
>> but the SE tile is much lower quality, clearly from a different set of
>> imagery. I could swear this area was formerly seamless with the good
>> imagery.
>>
>> It looks like this month's degradation is probably a downstream effect of
>> this change:
>>
>> https://www.usgs.gov/news/usgs-national-map-orthoimagery-
>> map-services-transition-and-other-map-service-changes
>>
>> Before USGS made this change, I saw identical imagery if I used iD's
>> built-in USGS LSI, versus using the following setting in Custom imagery in
>> iD:
>>
>> http://whoots.mapwarper.net/tms/{z}/{x}/{y}/0/http://raster.
>> nationalmap.gov/arcgis/services/Orthoimagery/USGS_EROS_Ortho
>> /ImageServer/WMSServer?
>>
>> The OSM built-in USGS LSI was faster than this custom link, I believe
>> because the custom link is dynamic (not cached by whoots), and it takes two
>> round trips, a lookup by iD to whoots, then by whoots to USGS, and probably
>> a dynamic conversion by whoots. I'm not an expert in this, so could easily
>> have some of this wrong.
>>
>> USGS LSI seemed faster -- perhaps it was static on the backend, or cached
>> better or something. The OSM built-in USGS LSI imagery appears to be served
>> by openstreetmap.us, though I know none of the details of how it's
>> served.
>>
>> Anyway now per the above announcement link, the *USGS_EROS_Ortho* URL is
>> deprecated, and is no longer served, and it seems like the following whoots
>> dynamic lookup imagery is the appropriate one, based on the
>> USGS-recommended replacement for the deprecated imagery:
>>
>> http://whoots.mapwarper.net/tms/{z}/{x}/{y}/1/https://servic
>> es.nationalmap.gov/arcgis/services/USGSNAIPPlus/MapServer/WMSServer?
>>
>> Indeed when I use this in the Custom imagery setting in iD, I see the
>> same degraded imagery that the built-in USGS LSI setting now gives me.
>>
>>
>> Can anyone shed further light or corrections on any of this? Any idea
>> whether it's technically possible and legally permissible to have
>> openstreetmap.us serve the older, better USGS LSI instead of the newer,
>> worse stuff? If so, upon further discussion I'd probably support such a
>> move, and possibly even offer to help with the conversion. :)
>>
>> Thanks!
>> David
>>
>> ___
>> 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
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Marcos Fedato]

Acho q o impar par é menos problema. Normalmente é impar a esquerda olhando do 
comeco da rua para o fim. E par a direita.

Se voce souber o sentido vc consegue saber que lado é o que.

Até pq se vc for usar o dado das faces a numeracao esta amarrada com o lado 
certo.

Vc só precisaria se importar caso unisse as numeracoes em um unico vetor com 4 
atributos num. Ini direita Num ini esquerda num fim direita, num fim esquerda.

Se for por face da quadra ja ta resolvido pq seria o inicial e o final de cada 
lado só.

Esse site explica mais ou menos. Nao deve se aplicar a tudo (sempre tem palmas, 
bauru e brasília pra ajudar) mas via de regra é igual.

http://mundoestranho.abril.com.br/cotidiano/como-sao-escolhidos-os-numeros-das-casas-de-uma-rua/

Enviado do meu smartphone Samsung Galaxy.


 Mensagem original 
De: "Sérgio V." 
Data: 18/12/2016 19:38 (GMT-03:00)
Para: talk-br@openstreetmap.org
Assunto: [Talk-br] Sobre addr:interpolation - possibilidades


Bom, legal que tem várias ideias e alternativas possíveis.


@santamariense, a camada de "faces" citada é dos SHP de "faces de logradouros" 
(ftp://geoftp.ibge.gov.br/recortes_para_fins_estatisticos/malha_de_setores_censitarios/censo_2010/base_de_faces_de_logradouros),
 que tem as linhas (ways) de face georreferenciadas.

Problema ainda é como colocar ali os números de endereços.


O negócio acho que é ir testando (de preferência antes, fora do OSM), 
documentando e compartilhando aqui o que der certo pros demais testarem também.


De minha parte à medida que tiver tempo vou testando no QGIS pra ver se e como 
daria pra fundir os ways do SHP das faces de logradouro com a numeração do: 
ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/

(Neste site, o arquivo "Layout.zip" indica as colunas dos dados dos TXT: tem a 
identificação das quadras e os CEPs também; tipo de estabelevimento, etc; 
várias informações úteis se se conseguir recuperar)


Um modo que tou pensando pra tentar conseguir identificar o sentido pra onde 
cresce a numeração serviria para os casos de "várias quadras" na sequência de 
"uma mesma rua": as quadras que (após a fusão com os números) tiverem numeração 
maior que as anteriores indicam o sentido. Poderia então colocar todos estes 
ways no mesmo sentido:  -> -> -> (se tiver como identificar e fazer 
automático...). Aí daria pra aplicar addr:interpolation nas duas extremidades 
(já orientadas) com mínimo/máximo.

Problema ainda seria lado impar/par.


Mas o negócio mesmo é ir testando concretamente, documentar, e partilhar.

Aí talvez possam vir mais soluções viáveis.

Tá valendo de todo modo.



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

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

Re: [OSM-talk] Key:Destination Abbreviations

[Tobias Zwick]

Hey Edwin

I read through the discussion on that page.

I think you focus too much on this 20:1 statistic. I too think this does
not really belong on the main page, but this is not really the issue.

I do not have the impression that anyone is using the 20:1 statistic as
an argument whether the destination name should be abbreviated or not.
The argument is that abbreviations in names being expanded for the DB is
the standard _in general_ and that the destination-value is just another
name(-like) tag.
Which I can totally follow. After all, where is the difference between a
sign on a freeway saying "Argument Ave" for the next exit and an actual
street sign at an intersection saying "Argument Ave"?

Why should this one sign not be abbreviated (street name) but that other
sign (freeway exit name) should?

As Carciofo said on the discussion page, I don't see the use case why
this consensus on names should be overturned for a specific tag.
You mentioned so that the actual sign could be displayed by the
navigation software. Well, it still can, the software just needs to know
how to abbreviate words, which is easy to do. The other way round,
automatically expanding an abbreviation (i.e. reading aloud) may be
ambiguous.

This is an old argument, it has been brought up years ago when talked
about whether to abbreviate names or not in general. That the same
argument applies to Key:destination again is a clear sign that
Kay:destination is in fact just another name tag.

Cheers
Tobias Zwick

On 18.12.2016 10:40 PM, Edwin Smith wrote:
> Hi all,
> There is a disagreement that could use a few more eyes.  Destination has
> the explicit purpose of telling a
> navigation program the wording of a sign.  It is typically used as a tag
> of a Motorway Link.  It is not visible
> in the Mapnik in any way.
> 
> One side of the disagreement argues that if an abbreviation appears on
> the sign (Ave for instance)
> it should be expanded to Avenue in the Destination Tag.  The arguments are:
> 1) OpenStreetMap discourages abbreviations
> 2) If you search through Destinations every time Avenue appears it is a
> mapper vote for expanding Ave to
> Avenue.
> 
> The other side of the disagreement (which I support) argues to present
> the sign to the navigation program
> exactly as it appears, neither abbreviating or expanding abbreviations. 
> The arguments are:
> 1) Destination is for the use of the navigation program.  If
> abbreviations are changed it has no way to
> know if the sign says Ave or Avenue.  If they are unchanged it can make
> its own decision as to what use
> of abbreviations is best for its users.
> 2) It is just wrong to count every Avenue as a mapper vote for expanding
> Ave because it very often is
> just the mapper's correct reporting that the sign has Avenue spelled out.
> 
> Check it out in the Key:destination Discussion.  As you will guess, the
> EDSS comments are mine.
> 
> Cheers,
> Edwin Smith
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk-fr] Routes manquantes... et carreaux INSEE

[Laurent Combe]

bonjour,

en essayant d'apporter ma contribution à cet objectif
je suis tombé sur ça :
http://tile.openstreetmap.fr/?zoom=16=44.3368=3.04921=B000TF

osmose signale la carreau comme desservi
mais il semble surtout que le carreau soit "mal placé"

c'est possible une erreur de la sorte ?
et que faut-il faire dans ce cas-là ?

Le 18 décembre 2016 à 16:44, Christian Quest  a écrit :
> On est passé en dessous de la barre des 1000 soit maintenant moins de
> 100.000 habitants sans route dans OSM pour aller chez eux...
>
> On tient le bon bout ! :)
>
> http://osmose.openstreetmap.fr/fr/errors/?item=7170=1
> http://osm2020.free.fr/qa-commune/popux-france.png
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

[OSM-talk] Key:Destination Abbreviations

[Edwin Smith]

Hi all,There is a disagreement that could use a few more eyes.  Destination has 
the explicit purpose of telling anavigation program the wording of a sign.  It 
is typically used as a tag of a Motorway Link.  It is not visiblein the Mapnik 
in any way.

One side of the disagreement argues that if an abbreviation appears on the sign 
(Ave for instance)it should be expanded to Avenue in the Destination Tag.  The 
arguments are:1) OpenStreetMap discourages abbreviations2) If you search 
through Destinations every time Avenue appears it is a mapper vote for 
expanding Ave toAvenue.
The other side of the disagreement (which I support) argues to present the sign 
to the navigation programexactly as it appears, neither abbreviating or 
expanding abbreviations.  The arguments are:1) Destination is for the use of 
the navigation program.  If abbreviations are changed it has no way toknow if 
the sign says Ave or Avenue.  If they are unchanged it can make its own 
decision as to what use
of abbreviations is best for its users.2) It is just wrong to count every 
Avenue as a mapper vote for expanding Ave because it very often isjust the 
mapper's correct reporting that the sign has Avenue spelled out.
Check it out in the Key:destination Discussion.  As you will guess, the EDSS 
comments are mine.
Cheers,Edwin Smith
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] rete satellitare Galileo

[Germano Massullo]

Peccato Royaltek non produca più le sue eccellenti antenne bluetooth,
sarebbe stato interessante acquistarne una per Galileo

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

Re: [Talk-it] rete satellitare Galileo

[Davide Mangraviti]

Stamattina facendo un rilievo per migliorare la mappatura su OSM in una zona
con il mio smartphone, ho notato (sarà un caso) che l'accoppiata segnale
GPS/GLONASS era migliore del solito che si senta la concorrenza del
rivale europeo? C'è ancora tempo..

Dico questo, pensando al fatto che di Galileo, sento parlare che ero ancora
all'Università. Per tutte le cose che si sono lette in questi anni, da parte
mia, le aspettative di qualità dei servizi, sono diventate molto alte e di
questo sono preoccupato. Nel frattempo gli USA stanno comunque rinnovando i
loro satelliti in orbita e non staranno fermi a guardare. 

Comunque sia, ancora non ci sono nè i chip in circolazione dentro i device
capaci a ricevere il segnale, i satelliti sono ancora non sufficienti, nè
sono pronti i servizi evoluti di cui tanto si parla. Diciamo che se parla
nel 2020?...

Questa settimana c'è stato il simbolico "pigiamento" del tasto rosso in
pompa magna mediatica. Speriamo che non sia come uno di quei tanti "tagli di
nastro" delle opere pubbliche che ci siamo spesso abituati a vedere in giro
da sempre.
Voglio essere ottimista e speranzoso.
saluti a tutti



--
View this message in context: 
http://gis.19327.n8.nabble.com/rete-satellitare-Galileo-tp5887685p5887713.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-us] USGS Large-Scale Imagery degraded this month :(

[Ian Dees]

I run the tile.openstreetmap.us server and noticed this change. Thanks for
finding the USGS link: I saw it a while ago but then couldn't find it when
I was trying to debug the problems with the server. The "usgs_large_scale"
layer on tile.openstreetmap.us is now caching the USGSNAIPPlus layer, but
the URL they provide both has worse imagery and is run from a much slower
server (so my caching operation takes quite a bit longer and results in
occasional 404s to the end user).

I will try to contact a couple of the folks I know at USGS (maybe they're
still on this list and could respond?), but it might be the case that we
need to request the imagery and build the desired layer ourselves...

On Sun, Dec 18, 2016 at 2:43 PM, David Kewley 
wrote:

> For a lot of my satellite imagery tracing, I've found it very useful to go
> back and forth between Bing and USGS Large-Scale Imagery, which provides at
> least 1-m resolution across the U.S., and in some areas (e.g. urban areas)
> provides nice 1-foot resolution orthoimagery that aligns very well in my
> local area with Bing imagery.
>
> Well, I should say "provided", past tense. For the past couple of weeks or
> so, I've noticed that the the USGS LSI has seemed to degrade in many of my
> local imagery tiles, and I've finally looked into why that might be so.
>
> For example, at this location, today (current state of imagery tile
> caching, perhaps mostly local to me?)
>
> https://www.openstreetmap.org/edit?changeset=44464607#map=
> 19/33.56194/-117.67451
>
> when using USGS LSI, I see the NE, NW, and SW imagery tiles look fine, but
> the SE tile is much lower quality, clearly from a different set of imagery.
> I could swear this area was formerly seamless with the good imagery.
>
> It looks like this month's degradation is probably a downstream effect of
> this change:
>
> https://www.usgs.gov/news/usgs-national-map-orthoimagery-map-services-
> transition-and-other-map-service-changes
>
> Before USGS made this change, I saw identical imagery if I used iD's
> built-in USGS LSI, versus using the following setting in Custom imagery in
> iD:
>
> http://whoots.mapwarper.net/tms/{z}/{x}/{y}/0/http://raster.
> nationalmap.gov/arcgis/services/Orthoimagery/USGS_EROS_Ortho
> /ImageServer/WMSServer?
>
> The OSM built-in USGS LSI was faster than this custom link, I believe
> because the custom link is dynamic (not cached by whoots), and it takes two
> round trips, a lookup by iD to whoots, then by whoots to USGS, and probably
> a dynamic conversion by whoots. I'm not an expert in this, so could easily
> have some of this wrong.
>
> USGS LSI seemed faster -- perhaps it was static on the backend, or cached
> better or something. The OSM built-in USGS LSI imagery appears to be served
> by openstreetmap.us, though I know none of the details of how it's served.
>
> Anyway now per the above announcement link, the *USGS_EROS_Ortho* URL is
> deprecated, and is no longer served, and it seems like the following whoots
> dynamic lookup imagery is the appropriate one, based on the
> USGS-recommended replacement for the deprecated imagery:
>
> http://whoots.mapwarper.net/tms/{z}/{x}/{y}/1/https://
> services.nationalmap.gov/arcgis/services/USGSNAIPPlus/MapServer/WMSServer?
>
> Indeed when I use this in the Custom imagery setting in iD, I see the same
> degraded imagery that the built-in USGS LSI setting now gives me.
>
>
> Can anyone shed further light or corrections on any of this? Any idea
> whether it's technically possible and legally permissible to have
> openstreetmap.us serve the older, better USGS LSI instead of the newer,
> worse stuff? If so, upon further discussion I'd probably support such a
> move, and possibly even offer to help with the conversion. :)
>
> Thanks!
> David
>
> ___
> 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-GB] OSM UK Local Chapter now officially exists

[Robert Norris]

Well done to all those involved in drudgery of the formal legal process.


I know I'm too lax to have input into the procedure but it's great to have 
motivated people who are!


--
Be Seeing You - Rob.
If at first you don't succeed,
then skydiving isn't for you.

From: Brian Prangle 
Sent: 18 December 2016 15:50:37
To: Talk GB
Subject: [Talk-GB] OSM UK Local Chapter now officially exists

Hi everyone

On Saturday morning I received from Companies House the Certicifate of 
Incorporation for OpenStreetMap United Kingdom Community Interest Company Ltd. 
It is a private limited company, limited by guarantee.

It's taken us a year to get this far, through a protracted and  often tedious 
process of agreeing Memorandum and Articles of Association,Community Interest 
Statement, form-filling, and signature gathering. Thankyou to everyone who 
participated, especially the volunteers who agreed to be the first directors 
necessary to get the thing off the ground.

Now we can start doing the fun stuff of how we make this work and transform it 
into a living organisation.(Although I'm sure we'll still have our share of 
bureaucratic process to navigate).

Regards

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

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

[osm . sanspourriel]

Le 18/12/2016 à 18:54, François Lacombe - fl.infosrese...@gmail.com a 
écrit :


Pourquoi pas
Une proposition est toujours en draft sur ce sujet :
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop

On pensait à telecom:medium=fiber... voire medium=fiber directement.
Comme dit en 2014, ca n'est pas un caractère de l'armoire mais la 
description du réseau qui passe à l'intérieur : plusieurs réseaux 
s'appuyant sur des medium différents peuvent passer.
C'est le cas dans les armoires Numéricâble où est faite la transition 
coax/fibre.
On devrait trouver soit fiber=yes + coax=yes ou bien 
telecom:medium=fiber;coax


Jsuis ni fan des listes à ; ni des clés avec pour seule valeur yes
Dilemme :/

Bonne fin de weekend

François

Je vais te proposer de mettre fin à ton dilemme :
telecom:medium:fiber=yes
telecom:medium:coax=yes

Pas de soucis pour les armoires à usage multiple.
Et comme il y a trois et non deux cas (yes, no, absence de tag)

> C'est le cas dans les armoires Numéricâble où est faite la transition 
coax/fibre.
Tu veux dire : du réseau à l'armoire en fibre et de l'armoire à l'abonné 
en coax, pas que l'armoire gère des réseaux basés sur deux technologies 
différentes.
Intéressant mais je ne vois pas ça dans le schéma. Non, je ne propose 
pas d'ajouter cette information mais je suis prêt à te l'entendre dire.

Ce serait par exemple :
telecom:service_level:FTTH pour l'armoire fibre et FTTLa pour l'armoire 
fibre/coax.
Comme ça on n'aurait pas de valeurs multiples ? Je dis peut-être une 
connerie, ne pas hésiter à le dire, j'aurais encore appris qqc ce soir.
Par exemple, est-ce quelque chose distingue le FTTH (H=Home, prise 
individuelle) et le FTTB (B=building, fibre à l'immeuble, autre techno 
ensuite) d'une point de vue réseau ? Est que le  FTTB n'est pas un FTTH 
suivi d'un FTTLa  (ou plutôt FTTC) dans l'immeuble ?

http://www.ariase.com/fr/guides/fibre-optique.html

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

Re: [Talk-it] rete satellitare Galileo

[Aury88]

dieterdreist wrote
> sent from a phone
> 
>> On 18 Dec 2016, at 11:24, Francesco Pelullo 

> f.pelullo@

>  wrote:
>> 
>> Nella ml internazionale è passato un messaggio da parte di un utente che
>> lo possiede, sostanzialmente non riceve niente. Ha postato degli
>> screenshot su twitter:
> 
> 
> 
> per il momento ci sono solo 11 satelliti in funzione quindi è improbabile
> di ottenere un fix
> 
> 
> ciao,
> Martin 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

a che mi risulta (fonte sito esa [1]) sono 14. sarebbero 18 ma 4 sono in
fase di test (lanciati tutti assieme un mesetto fa) e si uniranno al
servizio solo questa primavera.
qui la simulazione della copertura (purtroppo non c'è quella con 14
satelliti ma solo quella con 11 e 15)[2]

[1]http://www.esa.int/Our_Activities/Navigation/Galileo_begins_serving_the_globe
[2]http://www.esa.int/spaceinvideos/Videos/2016/12/Galileo_coverage




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n8.nabble.com/rete-satellitare-Galileo-tp5887685p5887706.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: [OSM-talk-fr] fiber=yes ?

[François Lacombe]

Bonjour Mael,

Le 17 décembre 2016 à 14:30, Maël REBOUX  a
écrit :

> Bonjour,
>
> Ce matin je tombe dans la rue sur une armoire telecom flambante neuve
> installée dans la semaine.
> Elle servira au FTTH car le déploiement fibre est en cours dans ma ville.
> https://twitter.com/mael_reboux_bzh/status/810061582231289857
>

+1


> *Je militerais bien pour le simple tag fiber=yes car, en l’occurrence il
> est certain que cette armoire est dédiée à la fibre et que ce serait
> dommage de l’oublier.*
>


Pourquoi pas
Une proposition est toujours en draft sur ce sujet :
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop

On pensait à telecom:medium=fiber... voire medium=fiber directement.
Comme dit en 2014, ca n'est pas un caractère de l'armoire mais la
description du réseau qui passe à l'intérieur : plusieurs réseaux
s'appuyant sur des medium différents peuvent passer.
C'est le cas dans les armoires Numéricâble où est faite la transition
coax/fibre.
On devrait trouver soit fiber=yes + coax=yes ou bien
telecom:medium=fiber;coax

Jsuis ni fan des listes à ; ni des clés avec pour seule valeur yes
Dilemme :/

Bonne fin de weekend

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

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

[Frédéric Rodrigo]

Bonjour,

L'intégration des données STIF est disponible sur Osmose. J'ai utilise 
le CSV pas le GTFS.


Si vous avez des remarques je prends (je prends aussi les pull request)

http://osmose.openstreetmap.fr/fr/errors/?item=8040

http://osmose.openstreetmap.fr/fr/map/#item=8040%2C8041%2C8042=14=48.80728=2.37892=1%2C2%2C3


https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_public_transport_FR_stif.py

Et bon courage aux parisiens pour l'intégration !


Frédéric.


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

Re: [Talk-it] rete satellitare Galileo

[Martin Koppenhoefer]

sent from a phone

> On 18 Dec 2016, at 11:24, Francesco Pelullo  wrote:
> 
> Nella ml internazionale è passato un messaggio da parte di un utente che lo 
> possiede, sostanzialmente non riceve niente. Ha postato degli screenshot su 
> twitter:



per il momento ci sono solo 11 satelliti in funzione quindi è improbabile di 
ottenere un fix


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

Re: [Talk-cz] otevření D8

[Jan Martinec]

No vida, tahle varianta mě nenapadla. Podle online zdrojů se víc hýbe ten
východní most (tj "směr sever"), takže se nejspíš jezdí po tom druhém;
nejsem si ale jist, kde se to spojuje a rozděluje (odhad je podle "2 km
úseku s omezením," což akorát vychází na místo sesuvu+estakádu), plus to
řazení do pruhů ve Stadicích. Tam by to chtělo zmapovat v terénu; osobně
nevím, kdy budu mít cestu tím směrem. Teď je to medle "méně špatně," byť
správně to není.

HPM

Dne 18. 12. 2016 1:44 napsal uživatel "jzvc" :

> Dne 17.12.2016 v 11:56 Jan Martinec napsal(a):
>
>> No - a zatímco jsme diskutovali, někdo už to včera otevřel v IDu :D Tak
>> jsem to aspoň doopravil - chyběl tam most a tak. Taky jsem odhadem
>> přidal prackovické omezení na 1 pruh (a snížení rychlosti - při provozu
>> 1 pruhem nelze legálně nechat 130).
>>
>
> Jezdi se jen po jednom moste, takze asi jinak nez si to otagoval ...
>
> https://www.novinky.cz/ekonomika/423985-po-poslednim-useku-
> d8-se-konecne-jezdi-u-prackovic-ale-s-omezenim.html
>
>
> Po kerym nevim.
>
>
>> HPM
>>
>> Dne 17. 12. 2016 10:30 napsal uživatel "jzvc" > >:
>>
>> Dne 17.12.2016 v 10:00 Jan Martinec napsal(a):
>>
>> Vzhledem k intervalu mi to připadá jako mikromapování ve 4D.
>> Blanku taky
>> někdo "otevřel" hned o půlnoci, tj 14 hodin před ofiko otevřením,
>> podobně Pražský okruh a D35 u Opatovic. Vzhledem k latenci
>> konzumentů
>>(hlavně routerů, renderery bývají svižnější) je 8 hodin sem
>> nebo tam
>> medle na hranici rozlišitelnosti. Je deset, jdu stříhat pásku v
>> mapě;)
>>
>>
>>
>> Bylo by fajn, kdyby se vsichni zucastneni tim gulasem zadusili 
>>
>> https://www.novinky.cz/domaci/423968-zoufalstvi-kolem-noveho
>> -useku-d8-otevreme-uvidime-a-mozna-zase-zavreme.html
>>
>> Hlavne ze se uz 1/2 roku dusujou, ze vsichni jsou blbci, ze nemaj
>> aktualni informace ... to nebude stat dalsi miliardu ani deset, ale
>> sto.
>>
>> A pripodotek, ten usek z Lovosic nahoru se taky pekne vlni, pred 14
>> dnama to sice preflikovali, ale to na veci nic nezmeni.
>>
>>
>>
>>
>> HPM
>>
>> Dne 17. 12. 2016 1:13 napsal uživatel "Pavel Machek"
>> 
>> >>:
>>
>>  On Fri 2016-12-16 11:53:35, Jan Martinec wrote:
>>   > Ok, mám to v JOZu připravený, jen to odpálit. Jdu se
>> podívat, kdy
>>  se bude
>>   > pižlat páska :)
>>
>>  Tak ono by bylo korektni to uploadnout rovnou (uz to stoji)
>> jen tam
>>  nechat tagy ze zavreno do zitrka, ne?
>>
>>  Hmm. A uz dlouho se vi ze by bylo dobre zavest v osm
>> "kontinenty"
>>  (protoze ty potvory se hybou). Co me nenapadlo je ze by
>> davalo smysl
>>  zavest stejny system i pro mensi celky (jako treba
>> ujizdejici kus
>>  D8) :-).
>>
>>
>>   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 
>> .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
>>
>>
>>
>> ___
>> 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

[Talk-GB] OSM UK Local Chapter now officially exists

[Brian Prangle]

Hi everyone

On Saturday morning I received from Companies House the Certicifate of
Incorporation for OpenStreetMap United Kingdom Community Interest Company
Ltd. It is a private limited company, limited by guarantee.

It's taken us a year to get this far, through a protracted and  often
tedious process of agreeing Memorandum and Articles of
Association,Community Interest Statement, form-filling, and signature
gathering. Thankyou to everyone who participated, especially the volunteers
who agreed to be the first directors necessary to get the thing off the
ground.

Now we can start doing the fun stuff of how we make this work and transform
it into a living organisation.(Although I'm sure we'll still have our share
of bureaucratic process to navigate).

Regards

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

[OSM-talk-fr] Routes manquantes... et carreaux INSEE

[Christian Quest]

On est passé en dessous de la barre des 1000 soit maintenant moins de
100.000 habitants sans route dans OSM pour aller chez eux...

On tient le bon bout ! :)

http://osmose.openstreetmap.fr/fr/errors/?item=7170=1
http://osm2020.free.fr/qa-commune/popux-france.png


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

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

[santamariense]

@Marcos Fedato, tudo o que você falou é verdade. Só seria útil e
preciso se tivesse coordenadas como na zona rural. Acrescento dizendo
que para piorar cada setor censitário pode conter N quadras. Mapeei em
outra oportunidade os setores censitários em Santa Maria, vejam em
http://overpass-turbo.eu/s/9zr.

Eu diria que seria possível complementar informações já existentes.
Mas uma importação tá quase impossível. Seria uma compilação manual
apenas. Exemplos de coisas que se pode extrair manualmente:

1. Se o setor censitário tiver 4 ruas, e no OSM se tem o nome de 3,
provavelmente lá se encontrará o nome da 4ª.
2. Se no OSM tivermos já o número das casas. Podemos posicionar POIs
do CNEFE no OSM.
3. Em ruas que passam por vários setores censitários, e que tiverem
numerações coerentes, até seria possível, ter ideia de onde a rua
começa/termina, bem como faixas de números referente a cada setor
censitário.

Mas tudo isso, se tivéssemos os dados como uma camada de fundo para
edições manuais, não consigo ainda vislumbrar uma importação.

@Vítor Rodrigo Dias, eu acho que o que foi falado acima possa
responder tua pergunta. E eu também já pensei nisso que você tá
astuciando, mesmo sem usar o CNEFE/IBGE. No caso da minha cidade,
sabendo onde começam (nº1) e terminam as ruas (nº [medida em metros a
partir do início da rua]), seria sim possível gerar algo provisório,
mas muito útil até que se tenha cada casa mapeada. E a ideia que
tinha, e que alguns colegas também tiveram, era aproveitando o próprio
eixo das vias.

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

[talk-ph] Fwd: [OSM-talk] weeklyOSM #334 06/12/2016-12/12/2016

[Eugene Alvin Villar]

-- Forwarded message --
From: weeklyteam 
Date: Sun, Dec 18, 2016 at 5:04 PM
Subject: [OSM-talk] weeklyOSM #334 06/12/2016-12/12/2016
To: t...@openstreetmap.org


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

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

Enjoy!

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

Re: [Talk-dk] Subject: Re: Er OpenStreetMap blevet kommercielt ?? - præcisering

[Finn Hansen]

Nu er det første gang jeg vil deltage i debatten her på forummet. Du 
nævner PAGUGA som bl.a. har stoppesteder på Fyn ved stationerne. Disse 
stoppesteder er ukorrekte, da DSB har aftaler med andre leverandører af 
togbuskørsler. Jeg har rettet  dem til at være DSB Togbus i stedet for 
PAGUGA. Det vil for mit synspunkt være den mest korrekte tags at give 
dem. Jeg kan endvidere nævne at på de pågældende stationer er der sat 
skilte op fra DSB om disse stoppesteder, hvor der klart ikke nævnes 
hvilke selskaber der kører for DSB.


/Lytter1


Den 18-12-2016 kl. 11:36 skrev s...@bukhmark.dk:


I min definition burde jeg nok have skrevet ”tilrette til egne formål” 
i stedet for ”bruge”


- dvs. at Papuga-stoppestederne i mine øjne også er kommercielt 
misbrug ligesom vandrehjemmenes egne turforslag o.lign.


Det er klart, at der er opstået en industri baseret på OSM-data, og 
det er fint med mig, så længe man husker de korrekte krediteringer.


/sba-dk

*Fra: *Julian Hollingbery 
*Sendt: *17. december 2016 16:08
*Til: *talk-dk@openstreetmap.org 
*Emne: *[Talk-dk] Subject: Re: Er OpenStreetMap blevet kommercielt ?? -

Ikke fordi jeg insisterer på at få det sidste ord, men i 
objektivitetens interesse bliver jeg lige nødt til at påpege, at det 
ikke er anvendeligt at definere "kommercielt misbrug" som "et firma 
tjener eller sparer så meget som en femøre ved at bruge OSM frem for 
andre kortleverandører". Grunden til dette er at det allerede sker i 
stort omfang. Bare for at tage et enkelt eksempel har jeg da betalt 
penge for at få installeret OsmAnd+ på min telefon - såvidt jeg kan 
se, er det et firma som står bag udviklingen heraf.


Jeg vil også stille spørgsmålstegn ved sådan en skarp skelnen mellem 
frivillighed og kommerciel aktivitet: Der er masser af firmaer som 
bidrager til OSM udover hvad der er strengt nødvendigt for deres 
bundlinie.


Til spørgsmålet "Hvorfor skal min frivillige arbejdskraft stilles 
gratis til rådighed for kommercielle interesser?" vil jeg foreslå 
svaret: "Fordi du udfra en helhedsbetragtning mener at samfundet 
bliver et bedre sted af at du bidrager". Der kan sikkert tænkes andre 
svar :-)


Når alt dette er sagt, så er jeg enig i at name-tags på disse huse bør 
slettes administrativt: Hvis ferienhaus-dk gerne vil have denne 
information i databasen, må de oprette et tag til formålet. Hvis man 
vil være flink, kunne man overveje at flytte den URL som står i 
"operator" til et "website" tag. Dog er det min læsning af wikien, at 
tourism=chalet giver god mening for sommerhuse som udlejes.


/julian

-Oprindelig meddelelse-

Message: 2

Date: Sat, 17 Dec 2016 12:45:49 +0100

From: 

To: OpenStreetMap Denmark 

Subject: Re: [Talk-dk] Er OpenStreetMap blevet kommercielt ?? -

 afsluttende kommentarer

Message-ID: 

Content-Type: text/plain; charset="utf-8"

Tusind tak for de mange meninger.

Vedr. Julians spørgsmål om definitioner, så er der efter min 
opfattelse tale om kommerciel misbrug såfremt et privat firma tjener 
eller sparer så meget som en femøre ved at bruge OSM i stedet for 
andre kortleverandører. Og ja, disse data er til ulempe for mig, fordi 
det er grimt og ukorrekt, og formentlig også for nogle naboer, der vil 
opleve et prisfald på deres huse ved for stor turistbelastning !!


Og så glemmer Julian, Lars og Michael Collinson en væsentlig Open 
Source karakteristika. OSM er baseret på frivillighed, og jeg har 
temmelig svært ved at se, hvorfor min og andre frivilliges 
arbejdskraft skal stilles gratis til rådighed for kommercielle 
interesser. Det vil i hvert fald kølne min interesse for projektet.


Jeg er dog enig med flere i, at vi ikke uden videre kan slette disse 
data af hensyn til god osm-opførsel, men vi kan rydde op, fx ved at 
slette "tourism=chalet" og name-tagging.


Jeg mener, at "tourism=chalet" er noget vrøvl i dette tilfælde. 
Udlejningshuse kan jo lige så godt bruges af rejsende håndværkere 
eller af gæster til et familiearrangement eller til indlogering af 
flygtninge. Det giver absolut ikke nogen mening i lokalområdet, at 
enkelte sommerhuse stikker ud, så derfor bør der tagges med ”building=yes”


Jeg mener, at name-tagging uden videre kan fjernes, dels fordi 
sprogbrugen er udansk, dels fordi de som Asger påpeger formentlig kun 
er interne data som ikke har bund i virkeligheden, dels fordi de som 
Jørgen påpeger overtræder tagging-regler om serialisering, dels fordi 
der ikke er nogen dansk tradition for at angive husnavne på kort. I 
modsætning til mange andre lande, så har vi et velfungerende 
OSAK-system, der gør husnavne på kort overflødige.


Jeg har ikke skrevet til d'herrer operatører, men nogen må gerne 
opfinde et standardbrev, der kan bruges i slige tilfælde.


/sba-dk

___

Talk-dk mailing list

Re: [Talk-it] rete satellitare Galileo

[Francesco Pelullo]

Il 18 dic 2016 11:35, "Damjan Gerl"  ha scritto:


Attenzione che per quello che ne so (almeno fino a alcuni mesi fa) l'unico
chipset che supportava il galileo era il chipset u-blox, però da tenere
conto che può ricevere solo due tipi di satelliti: o gps + glonas o gps +
galileo, quindi non tutti e tre insieme.


Probabilmente la situazione è cambiata nel frattempo:

http://www.usegalileo.eu/EN/inner.html#data=smartphone

Il problema è che chi possiede uno dei terminali compatibili
(sostanzialmente soltanto BQ, dato che Huawei è ancora in prevendita) dice
che non riceve niente.

Altro utente che segnala il problema:
http://www.mibqyyo.com/comunidad/discussion/87826/galileo/p1

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

Re: [Talk-dk] Subject: Re: Er OpenStreetMap blevet kommercielt ?? - præcisering

[sba]

I min definition burde jeg nok have skrevet ”tilrette til egne formål” i stedet 
for ”bruge”
- dvs. at Papuga-stoppestederne i mine øjne også er kommercielt misbrug ligesom 
vandrehjemmenes egne turforslag o.lign.

Det er klart, at der er opstået en industri baseret på OSM-data, og det er fint 
med mig, så længe man husker de korrekte krediteringer. 

/sba-dk

Fra: Julian Hollingbery
Sendt: 17. december 2016 16:08
Til: talk-dk@openstreetmap.org
Emne: [Talk-dk] Subject: Re: Er OpenStreetMap blevet kommercielt ?? -

Ikke fordi jeg insisterer på at få det sidste ord, men i objektivitetens 
interesse bliver jeg lige nødt til at påpege, at det ikke er anvendeligt at 
definere "kommercielt misbrug" som "et firma tjener eller sparer så meget som 
en femøre ved at bruge OSM frem for andre kortleverandører". Grunden til dette 
er at det allerede sker i stort omfang. Bare for at tage et enkelt eksempel har 
jeg da betalt penge for at få installeret OsmAnd+ på min telefon - såvidt jeg 
kan se, er det et firma som står bag udviklingen heraf.

Jeg vil også stille spørgsmålstegn ved sådan en skarp skelnen mellem 
frivillighed og kommerciel aktivitet: Der er masser af firmaer som bidrager til 
OSM udover hvad der er strengt nødvendigt for deres bundlinie.

Til spørgsmålet "Hvorfor skal min frivillige arbejdskraft stilles gratis til 
rådighed for kommercielle interesser?" vil jeg foreslå svaret: "Fordi du udfra 
en helhedsbetragtning mener at samfundet bliver et bedre sted af at du 
bidrager". Der kan sikkert tænkes andre svar :-)

Når alt dette er sagt, så er jeg enig i at name-tags på disse huse bør slettes 
administrativt: Hvis ferienhaus-dk gerne vil have denne information i 
databasen, må de oprette et tag til formålet. Hvis man vil være flink, kunne 
man overveje at flytte den URL som står i "operator" til et "website" tag. Dog 
er det min læsning af wikien, at tourism=chalet giver god mening for sommerhuse 
som udlejes.

/julian


-Oprindelig meddelelse-

Message: 2
Date: Sat, 17 Dec 2016 12:45:49 +0100
From: 
To: OpenStreetMap Denmark 
Subject: Re: [Talk-dk] Er OpenStreetMap blevet kommercielt ?? -
afsluttende kommentarer
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Tusind tak for de mange meninger.

Vedr. Julians spørgsmål om definitioner, så er der efter min opfattelse tale om 
kommerciel misbrug såfremt et privat firma tjener eller sparer så meget som en 
femøre ved at bruge OSM i stedet for andre kortleverandører. Og ja, disse data 
er til ulempe for mig, fordi det er grimt og ukorrekt, og formentlig også for 
nogle naboer, der vil opleve et prisfald på deres huse ved for stor 
turistbelastning !!

Og så glemmer Julian, Lars og Michael Collinson en væsentlig Open Source 
karakteristika. OSM er baseret på frivillighed, og jeg har temmelig svært ved 
at se, hvorfor min og andre frivilliges arbejdskraft skal stilles gratis til 
rådighed for kommercielle interesser. Det vil i hvert fald kølne min interesse 
for projektet.

Jeg er dog enig med flere i, at vi ikke uden videre kan slette disse data af 
hensyn til god osm-opførsel, men vi kan rydde op, fx ved at slette 
"tourism=chalet" og name-tagging.

Jeg mener, at "tourism=chalet" er noget vrøvl i dette tilfælde. Udlejningshuse 
kan jo lige så godt bruges af rejsende håndværkere eller af gæster til et 
familiearrangement eller til indlogering af flygtninge. Det giver absolut ikke 
nogen mening i lokalområdet, at enkelte sommerhuse stikker ud, så derfor bør 
der tagges med ”building=yes”

Jeg mener, at name-tagging uden videre kan fjernes, dels fordi sprogbrugen er 
udansk, dels fordi de som Asger påpeger formentlig kun er interne data som ikke 
har bund i virkeligheden, dels fordi de som Jørgen påpeger overtræder 
tagging-regler om serialisering, dels fordi der ikke er nogen dansk tradition 
for at angive husnavne på kort. I modsætning til mange andre lande, så har vi 
et velfungerende OSAK-system, der gør husnavne på kort overflødige.

Jeg har ikke skrevet til d'herrer operatører, men nogen må gerne opfinde et 
standardbrev, der kan bruges i slige tilfælde.

/sba-dk



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

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

Re: [Talk-it] rete satellitare Galileo

[Damjan Gerl]

18.12.2016 - 11:24 - Francesco Pelullo:


Il 18 dic 2016 11:01, "Marco Ciampa" > ha scritto:




A proposito, qualcuno ha provato il "BQ Aquaris X5 Plus" che
dovrebbe supportarlo?



Nella ml internazionale è passato un messaggio da parte di un utente 
che lo possiede, sostanzialmente non riceve niente. Ha postato degli 
screenshot su twitter:


https://twitter.com/gregorymarler/status/810061580914360320?s=09

Ciao
/niubii/


Attenzione che per quello che ne so (almeno fino a alcuni mesi fa) 
l'unico chipset che supportava il galileo era il chipset u-blox, però da 
tenere conto che può ricevere solo due tipi di satelliti: o gps + glonas 
o gps + galileo, quindi non tutti e tre insieme.


Ciao
Damjan

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

Re: [Talk-it] rete satellitare Galileo

[Francesco Pelullo]

Il 18 dic 2016 11:01, "Marco Ciampa"  ha scritto:



A proposito, qualcuno ha provato il "BQ Aquaris X5 Plus" che dovrebbe
supportarlo?



Nella ml internazionale è passato un messaggio da parte di un utente che lo
possiede, sostanzialmente non riceve niente. Ha postato degli screenshot su
twitter:

https://twitter.com/gregorymarler/status/810061580914360320?s=09

Ciao
/niubii/



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

Re: [Talk-it] rete satellitare Galileo

[Marco Ciampa]

On Sun, Dec 18, 2016 at 10:15:29AM +0100, Dario Zontini Gmail wrote:
> Segnalo che da alcuni giorni è attiva la rete satellitare Galileo. Non ci
> sono molti dispositivi in commercio in grado di ricevere il segnale, ma se
> qualcuno ha intenzione di acquistare qualcosa di nuovo, magari vale la pena
> verificare se è compatibile a Galileo.

A proposito, qualcuno ha provato il "BQ Aquaris X5 Plus" che dovrebbe 
supportarlo?

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




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

Re: [Talk-us] weeklyOSM #334 06/12/2016-12/12/2016

[Shawn K. Quinn]

On 12/18/2016 03:04 AM, weeklyteam wrote:
> The weekly round-up of OSM news, issue # 334,
> is now available online in English, giving as always a summary of all things 
> happening in the openstreetmap world:
> 
> http://www.weeklyosm.eu/en/archives/8472/

When I just retrieved it, there was no English version, I got what
appears to be Spanish.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

[Talk-it] rete satellitare Galileo

[Dario Zontini Gmail]

Segnalo che da alcuni giorni è attiva la rete satellitare Galileo. Non 
ci sono molti dispositivi in commercio in grado di ricevere il segnale, 
ma se qualcuno ha intenzione di acquistare qualcosa di nuovo, magari 
vale la pena verificare se è compatibile a Galileo.


Ciao

--


Dario Zontini


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

[Talk-GB] weeklyOSM #334 06/12/2016-12/12/2016

[weeklyteam]

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

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

Enjoy!

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

[Talk-in] weeklyOSM #334 06/12/2016-12/12/2016

[weeklyteam]

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

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

Enjoy!

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

[Talk-ca] weeklyOSM #334 06/12/2016-12/12/2016

[weeklyteam]

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

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

Enjoy!

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

[OSM-talk-ie] weeklyOSM #334 06/12/2016-12/12/2016

[weeklyteam]

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

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

Enjoy!

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

[Talk-us] weeklyOSM #334 06/12/2016-12/12/2016

[weeklyteam]

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

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

Enjoy!

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

[OSM-talk] weeklyOSM #334 06/12/2016-12/12/2016

[weeklyteam]

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

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

Enjoy!

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

Re: [Talk-it] OSM e CAI

[Alfredo Gattai]

2016-12-17 18:09 GMT+01:00 gpstracks.it :

> Volevo esprimere le mie opinioni sulla bozza mappatura dei sentieri CAI
>
> Sono (diventato) completamente contrario al "name" contenente il numero di
> sentiero per i seguenti motivi:
>
> -E' in contrapposizione a quello che è indicato sulla documentazione [1]
>
> -OSM è un database e come tale va trattato per renderlo utilizzabile.
> Non è corretto inserire il "ref "in un campo che non è destinato a tale
> informazione.
>

Su questo siamo tutti daccordo ed infatti nella bozza CAI si ricalca quando
gia' in uso nelle wiki ufficiali nella maggior parte dei casi


> In ogni caso, se il sentiero non ha un nome non lo si deve inventare.
>

In questo caso non si tratta di inventare un nome ma si tratta di chiarire
quali sono le linee guida CAI per l'assegnazione di un nome al sentiero
quando non ne esista gia' uno. Non si chiede a nessuno di inventare un
nome, si descrive solamente come viene fatto dal CAI. Sull'arco alpino dove
ci sono i sentieri piu' famosi e "blasonati" questo problema non esiste. In
molte altre zone non alpine esistono antiche viabilita' che stanno venendo
recuperate e purtroppo ci sono alcuni tracciati dei quali si e' perso il
nome storico. Ne esistono moltissimi che hanno gia' come nome dei soli
riferimenti al toponimo di partenza e quello di arrivo. Per quelli che non
hanno gia' un nome lo si stabilisce usando lo stesso principio. Non e' una
raccomandazione per tutti i mappatori (che possono non avere le
informazioni necessarie sul terreno), e' la pratica in uso al CAI (ed in
collaborazione con le regioni) favorita dal fatto che il CAI e la Regione
hanno spesso informazioni aggiuntive che permettono di farlo. Che queste
informazioni vengano liberate in OSM c'e' solo da esserne contenti.
Comunque ho cambiato la descrizione della wiki, dove la pratica in uso al
CAI e' messa tra parentesi e si specifica che non e' una raccomandazione
generica.


>
>
> In merito ai bivacchi, ho notato la seguente imprecisione:
> il classico bivacco Fondazione Berti o similare (per intenderci, quelli in
> lamiera a forma di semibotte),
> va taggato con amenity=shelter e shelter_type=basic_hut.
>


Grazie, avevamo indicato erroneamente nel titolo come bivacchi quelli che
sono i rifugi non gestiti.
Si accettano suggerimenti per la questione chiavi. Probabilmente sia per i
rifugi non gestiti che per i bivacchi si possono aggiungere:

access
operator
description

dove nella descrizione si specifica se sono necessarie le chiavi

Ciao
Alfredo



> Ciao
>
> [1] http://wiki.openstreetmap.org/wiki/IT:Hiking
>
>
> ___
> 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