Re: [OSM-talk] new bing hires updates not visible in JOSM?
At 2012-06-12 17:39, maning sambale wrote: As the subject says, we spotted new imagery from Bing. Potlatch2 can load the imagery, but JOSM still shows the lowres Landsat image of the same area. This area for reference: http://www.openstreetmap.org/?lat=9.305565lon=123.308057zoom=18 Using JOSM r5181: In that area, I can get down/in to zoom 19, dated 2011-09-14. This is 0.3m/pel (~30m on the 1 scale bar) - enough to see individual cars and the buildings with which some OSM ways are poorly aligned :) Unfortunately, there is some cloud/fog-cover that obscures some areas completely. The high-res extends west only to ~123.265 deg longitude and, when zoomed down/in further than about zoom 14 (9.4m/pel (1:940m)), there is no imagery at all west to ~123.245 deg (a swath ~2200m wide), before the zoom 13 (18.8m/pel, 1:1880m) imagery area. That should probably be reported. Bing tends to have these at interfaces between different image sets, but there are usually just a few meters, unlike this one. The imagery cache path is given in the Preferences dialog, Advanced Preferences, key imagery.tms.tilecache_path. Under that directory, there are separate directories for each particular WMS/TMS source, each of which contain a ton of files. I don't know what it's like on a Mac, but it takes many hours to remove those directories on Windows (the subject of a recent JOSM change request) if you want to flush the cache. You can also flush the cache for a particular source by creating a layer with it in JOSM, then right-clicking (or whatever your context-menu-key is) and choosing Flush cache. This may be quicker, or not. Lastly, or maybe firstly, check the Imagery URL you are using (Preferences-Imagery Preferences). It should be bing:http://www.bing.com/maps/;. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wikimapia data now under cc-by-sa
Am 14.06.2012 15:24, schrieb Arun Ganesh: wikimapia for clarification: * Wikimapia has nothing at all to do with Wikimedia foundation, it is held by a private company (see e.g. http://en.wikipedia.org/wiki/WikiMapia) * CC by SA is something which is not in our interrest as we want to move away from this licence anyhow... Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Specific Cases of Governments Using OSM
Hi All, I'm giving a presentation in a couple weeks about OpenStreetMap and how governments can interact with OSM. I'm looking for examples of governments using OSM data, versus releasing data for OSM to use. I already know about TriMet in Portland, OR for example: http://ride.trimet.org/ There is also my work with HOT in Indonesia for mapping exposure for impact models. What other examples are out there? Thanks, -Kate ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wikimapia data now under cc-by-sa
Hi there, this is interesting. Where can the data be downloaded, do you know? I dont seem to find dumps. http://wikimapia.org/forum/viewtopic.php?t=7775 I found an api, http://wikimapia.org/api/ thanks, mike On Thu, Jun 14, 2012 at 9:24 AM, Arun Ganesh arun.plane...@gmail.comwrote: Before you get all excited, I do not think its what it sounds like. See the official announcement here: http://wikimapia.org/forum/viewtopic.php?f=74t=9878 I'm not certain what this 'wikimapia data' is or where it can be downloaded from. But it seems to be that this could be the placemark content- titles, descriptions, images and comments, but not the geographical coordinates. I have seen numerous cases where the description and images have just been copied from wikipedia and this license change is probably an attempt at conforming with the cc-by-sa license. If this data covers the geographical coordinates which have been derived from google maps service, then it doesnt make any sense. Can someone clarify? -- j.mp/ArunGanesh http://j.mp/ArunGanesh ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Wanted
I am looking for two knowledgeable OSM community people to run workshops at a conference I am helping coordinate in London in September. One to run a workshop on using OSM data (demystifying licence, access, formats, exporting, metadata etc) - opening the door to the data to cartographers The second is to demonstrate the mapbox/tilemill capabilities and workflow Negotiable incentives may be available (certainly free conference attendance, possibly some travel). Conference is the Society of Cartographers at UCL 3-5 Sept (workshops on Tues 4th Sept): http://www.soc2012.soc.org.uk/ Any suggestions or contacts welcomed, thanks. Cheers Steve Chilton (@steev8) ste...@mdx.ac.ukBoundary_(ID_UOsvvC79dWMMVALiP+j0aw) ** MESSAGE DAMAGED IN TRANSIT ** ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] NOTICE: Deprecating non-standard tile.osm.org URLs
Cross posting from announce@ and dev@ lists...
-- Forwarded message --
Date: 1 June 2012 18:30
Subject: Deprecating non-standard tile.osm.org URLs
To: OSM Dev List d...@openstreetmap.org, annou...@openstreetmap.org
OpenStreetMap Devs,
After the 30th June 2012 a number of non-standard
tile.openstreetmap.org URLs will no longer function.
The only valid URL format is:
http://tile.openstreetmap.org/{z}/{x}/{y}.png
Valid host aliases are: a.tile.openstreetmap.org,
b.tile.openstreetmap.org, c.tile.openstreetmap.org, tile.osm.org,
a.tile.osm.org, b.tile.osm.org and c.tile.osm.org
Common non-standard URLs:
http://tile.openstreetmap.org//{z}/{x}/{y}.png
http://tile.openstreetmap.org/mapnik/{z}/{x}/{y}.png
http://tile.openstreetmap.org/mapnik_tiles/{z}/{x}/{y}.png
...and many more
All non-standard tile URLs will return 404 Not Found from the 30th June onwards.
The vast majority of websites and apps are using the valid URL format,
however you may wish to check that you are using the correct URL to
access tiles.
Please be aware that tile.openstreetmap.org has a usage policy:
http://wiki.openstreetmap.org/wiki/Tile_usage_policy
Mass scraping of tiles for offline usage or similar is NOT permitted
on this tile server.
Technical: The invalid URLs are poisoning our caches. Storage
re-writing is impractical due to the request rate. (1000 tiles per
second)
Sincerely
Grant
Part of OpenStreetMap sysadmin team.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
2012/6/15 Kate Chapman k...@maploser.com: Hi All, I'm giving a presentation in a couple weeks about OpenStreetMap and how governments can interact with OSM. I'm looking for examples of governments using OSM data, versus releasing data for OSM to use. I already know about TriMet in Portland, OR for example: http://ride.trimet.org/ There is also my work with HOT in Indonesia for mapping exposure for impact models. What other examples are out there? There is the portal for cultural tourism in Latium, Italy: http://futouring.it http://futouring.it/web/filas/mappe-del-lazio cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
On 15 June 2012 10:04, Kate Chapman k...@maploser.com wrote: What other examples are out there? Picked out a few public gov users of OSM tiles. * http://data.linz.govt.nz/ * http://energy.gov/search/site/florida * http://geo.nysenate.gov/maps/regular.jsp?x=850y=595sd=51 * http://community.newcastle.gov.uk/my-newcastle/your-details?uprn=4510091335ens=418227,564684address=%20%20%208%20%20%20%20%20%20%20NORTHUMBERLAND%20ROAD%20NEWCASTLE%20UPON%20TYNE%20NE15%208SD * http://www.wrexham.gov.uk/english/leisure_tourism/plas_madoc/plas_madoc_index.htm * http://web.mintransporte.gov.co/sinc/ * http://mz.ks.gov.ba/node/1795 * http://maps.dggs.alaska.gov/gp/ * http://www.strathclyde.police.uk/your_community/ayrshire/irvine_east Many many more... tile.osm.org is accessed from .gov domains from the following TLDs: .ar, .au, .ba, .br .ca, .co, .ge, .gov, .gr, .in, .it, .my, .nz, .ph, .pl, .py, .ru, .tr, .tw, .uk, .vc, .za / Grant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
Hampshire County Council, UK seem to be doing something http://lists.openstreetmap.org/pipermail/talk-gb/2012-June/013345.html Surrey Heath Borough Council, UK have an OSM-fan working in the GIS department who might be able to help you. I think they were also responsible for some very high-res aerial imagery being available to trace. https://twitter.com/Chobhamonian/status/205369574982557697 http://wiki.openstreetmap.org/wiki/Surrey_Air_Survey On 15 June 2012 12:51, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/6/15 Kate Chapman k...@maploser.com: Hi All, I'm giving a presentation in a couple weeks about OpenStreetMap and how governments can interact with OSM. I'm looking for examples of governments using OSM data, versus releasing data for OSM to use. I already know about TriMet in Portland, OR for example: http://ride.trimet.org/ There is also my work with HOT in Indonesia for mapping exposure for impact models. What other examples are out there? There is the portal for cultural tourism in Latium, Italy: http://futouring.it http://futouring.it/web/filas/mappe-del-lazio cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
Kate Chapman wrote: What other examples are out there? http://wiki.openstreetmap.org/wiki/DE:OSM_Internet_Links has a Behörden / Kommunen section with many examples of, mostly German, government institutions using OSM. Most of these are slippy map backgrounds of sites visualising POI or other data for citizens, some are road maps for villages, layers in GIS systems or even just static maps for directions. Tobias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
At 2012-06-15 02:04, Kate Chapman wrote: I'm looking for examples of governments using OSM data Not huge, but nice: http://www.whitehouse.gov/change/ -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Presenting filter for openstreetmaps history RSS feeds
On 14/06/2012 19:12, Arlindo Pereira wrote: Thanks a lot, Pavel! I've always wished for a tool that allowed me to track alterations on the map in a so easily way. There was an excellent one: http://matt.dev.openstreetmap.org/owl_viewer/ It's obviously down at the moment but the owner has said he plans on getting it back up running. Hopefully very soon. Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Specific Cases of Governments Using OSM
Hi Kate, I'm one of the interns on the TriMet project and I just had to step in and offer a correction: ride.trimet.org is *not* the trip planner that uses OSM--- the one that does is our new Regional Trip Planner (still in beta, but soon out of it, we hope) at http://rtp.trimet.org. Some government folks in Chattanooga, TN are also working on setting up a trip planner with the same system (OpenTripPlanner) and OSM-- I'm not sure what their progress is right now (I do think some of them are on this list, though). You might want to check out http://openchattanooga.wikispaces.com/Routr for some info. Thanks, and good luck! Mele Sax-Barnett TriMet Regional Trip Planner/OSM Improvement Project Intern ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Procura-se voluntários para importação IBGE
Oi Djavan, Infelizmente, não há dados bem precisos para a região de BH. Tudo o que eu achei foi dados com uma precisão média. Logo, o que eu falei pro Cláudio sobre Teresópolis é valido também para esses dados: Eu consegui achar uns dados de Teresópolis no IBGE. Eles são um pouco mais precisos que os do RS, mas menos que os do RJ. Como se trata de cidade, um erro de 10 metros pode fazer alguém se confundir de quarteirão, então não são dados bons o suficiente para ser importados na sua totalidade. Por outro lado, eu diria que usar esses dados como matéria-prima é mais fácil do que fazer tudo a mão usando o Bing: várias estradas estão boas o suficiente para ser importadas sem modificação e outras so precisa mudar um pedaço pequeno (mas algumas estão completamente erradas). O arquivos são: http://sites.google.com/site/vsessak/belo_horizonte.osm.bz2 http://sites.google.com/site/vsessak/cachoeira_dos_macacos.osm.bz2 http://sites.google.com/site/vsessak/caete.osm.bz2 http://sites.google.com/site/vsessak/contagem.osm.bz2 http://sites.google.com/site/vsessak/esmeraldas.osm.bz2 http://sites.google.com/site/vsessak/jabuticabas.osm.bz2 http://sites.google.com/site/vsessak/lagoa_santa.osm.bz2 http://sites.google.com/site/vsessak/pedro_leopoldo.osm.bz2 []'s, e espero que esses dados te sejam uteis, -Vitor On 06/14/2012 03:40 PM, Djavan Fagundes wrote: Eu estou meio atarefado estes dias e impossibilitado de ajudar mas estou acompanhando os e-mails. Se correr tudo bem nas importações, irei fazer para a região metropolitana de BH. Em 14 de junho de 2012 09:39, Vitor Sessak vitor1...@gmail.com mailto:vitor1...@gmail.com escreveu: Olá a todos, Falando em importar dados de outros estados, eu pus na página da wiki uma primeira leva de dados do Rio Grande do Sul. Esses pedaços estão prontos a serem importados. Qualquer comentário/sugestão é bem-vinda. []'s Vitor On 06/12/2012 07:19 PM, Vitor Sessak wrote: Olá Edmar, O IBGE permite a incorporação dos dados, veja o email para essa mesma lista em [1]. Além desse email, a ausência de qualquer nota de copyright no site deles e os varios links para a pagina da lei de acesso à informação corroboram isso. Sobre os outros dados, eu conto importa-los também. A minha idéia é começar pelos dados do Rio porque eles são bem precisos e é uma região onde as imagens de satélite são boas, o que permite checar se não tem nenhum problema com o processo de importação. []'s -Vitor [1] http://lists.openstreetmap.org/pipermail/talk-br/2010-January/000953.html On 06/12/2012 03:25 PM, Edmar Moretti wrote: Dúvida: A licença de uso dos dados do IBGE permite a incorporção dos ddados ao OSM? Se sim, essa imprtação pode ser feita para outros casos, como a cartografia básica em outras escalas e que cobrem outras regiões? []'s Em 12/06/2012 10:11, CLFerraz escreveu: Saudações... Estou offline até a próxima quinta, mas me prontifico a fazer para a região de Teresópolis, o de possuo residência e tenho colaborado. Se alguém puder atualizar a tabela, agradeço... Cláudio L. Ferraz Enviado via iPhone Em 12/06/2012, às 09:43, Aun Yngve Johnsen li...@gimnechiske.org mailto:li...@gimnechiske.org mailto:li...@gimnechiske.org mailto:li...@gimnechiske.org escreveu: Oi JOSM tem um plugin para simplificar ruas, talvez poder ajuda Aun Y. Johnsen Sent from my iPad +55 (27) 3114-0008 tel:%2B55%20%2827%29%203114-0008 +55 (27) 9736-3919 tel:%2B55%20%2827%29%209736-3919 (vivo) On 12. juni 2012, at 08:46, Stephane Goldstein s@gmx.com mailto:s@gmx.com mailto:s@gmx.com mailto:s@gmx.com wrote: Olá Vitor. Baixei o arquivo [1] para dar uma olhada. Será que não seria melhor simplificar estas vías antes de importa-las ? Não sei qual seria o melhor método para fazer isso, mas acho que elas estão com mais pontos do que o necessario, sobrecarregando a base e tornando o trabalho no JOSM muito lento. Abraço Stephane - Original Message - From:
Re: [Talk-br] Classificação de vias
Nada é nunca. O mais importante é usar o bom senso. Supõe-se que uma estrada municipal não liga um município a outro, então a sua importância para o fluxo de veículos seria baixa. Pode haver alguma exceção. Por exemplo, se a estrada municipal não pavimentada é a principal via de ligação de um distrito (com centro urbano) à sede do município, talvez seja mais adequado classificá-la como tertiary. É difícil prever todas as possibilidades. Em 15-06-2012 04:06, Hermann Peifer escreveu: Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6y0cq0...@public.gmane.org escreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias
Talvez 'highway=track', não? http://wiki.openstreetmap.org/wiki/Tag:highway=track Vitor George mapaslivres.org twitter.com/mapaslivres 2012/6/15 Hermann Peifer pei...@gmx.eu Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/**wiki/Pt-br:Guia_de_Mapeamento_** do_Territ%C3%B3rio_Brasileirohttp://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6Y0CQ0nG0@public.**gmane.orgmartin137-hi6y0cq0...@public.gmane.orgescreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/**wiki/Pt-br:Guia_de_Mapeamento_** do_Territ%C3%B3rio_Brasileirohttp://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/**wiki/Pt-br:Key:highwayhttp://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.**br/cidade/secretarias/** habitacao/departamentos/aprov/**index.php?p=3303http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias
Pela descrição do wiki essa tag se aplica mais a uma estrada de roça do que a uma estrada de interior... Rodrigo Avila Em 15/06/2012 12:24, vitor vitor.geo...@gmail.com escreveu: Talvez 'highway=track', não? http://wiki.openstreetmap.org/wiki/Tag:highway=track Vitor George mapaslivres.org twitter.com/mapaslivres 2012/6/15 Hermann Peifer pei...@gmx.eu Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/**wiki/Pt-br:Guia_de_Mapeamento_** do_Territ%C3%B3rio_Brasileirohttp://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6Y0CQ0nG0@public.**gmane.orgmartin137-hi6y0cq0...@public.gmane.orgescreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/**wiki/Pt-br:Guia_de_Mapeamento_** do_Territ%C3%B3rio_Brasileirohttp://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/**wiki/Pt-br:Key:highwayhttp://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.**br/cidade/secretarias/** habitacao/departamentos/aprov/**index.php?p=3303http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Procura-se voluntários para importação IBGE
Vitor, boa tarde… Coloquei no JOSM o arquivo com os dados de Teresópolis que você disponibilizou, mas… tá tudo muito impreciso… Acho que vai servir apenas para tirar dúvidas, como material de referência. Não é offset das imagens do Bing, visto que os dados que coletei eu mesmo com uso do GPS se mostram mais precisos que os contidos no arquivo. Acho também que daria mais trabalho acertar as ruas do que desenhá-las, considerando que muitas vias já acertei. Há de se levar em conta ainda que há ruas que deixaram de existir ou tiveram seu traçado alterado depois da enchente de janeiro de 2011, visto que tivemos até geografia do local alterada. Acredito que esse arquivo seja anterior a essa data. Usarei ele como referência e com cautela. Se conseguir qualquer coisa a mais sobre a região, será bem-vindo ;-) De qualquer forma, obrigado, e qualquer coisa, conte comigo. Se puder dar uma olhada na região e opinar para ver se estou fazendo tudo certo, também agradeço ;-) Abraços… Cláudio L. Ferraz Em 15/06/2012, às 12:34, CLFerraz escreveu: Valeu, Vitor, já baixei. Tinha procurado algo de Terê por lá, mas não fui bem sucedido. Vai ajudar, com certeza. Obrigado!!! Cláudio L. Ferraz Em 15/06/2012, às 05:44, Vitor Sessak escreveu: Olá Cláudio, Eu consegui achar uns dados de Teresópolis no IBGE. Eles são um pouco mais precisos que os do RS, mas menos que os do RJ. Como se trata de cidade, um erro de 10 metros pode fazer alguém se confundir de quarteirão, então não são dados bons o suficiente para ser importados na sua totalidade. Por outro lado, eu diria que usar esses dados como matéria-prima é mais fácil do que fazer tudo a mão usando o Bing: varias estradas estão boas o suficiente para ser importadas sem modificação e outras so precisa mudar um pedaço pequeno (mas algumas estão completamente erradas). Você pode baixar o arquivo em [1]. []'s Vitor [1] http://sites.google.com/site/vsessak/teresopolis.osm.bz2 On 06/15/2012 01:08 AM, CLFerraz wrote: Valeu, Vítor, pela resposta... Também acho melhor ser alguém que conheça a região. Por isso, por enquanto e principalmente pelo tempo que disponho, prefiro continuar investindo no mapeamento, correção e inserção de dados de Teresópolis, pois além dessa cidade não possuir dados para importação, posso fazer um trabalho mais preciso categorizando as ruas, inserindo POIs, corrigindo erros, etc, justamente por conhecê-la. Abraços... Cláudio L. Ferraz Em 13/06/2012, às 03:35, Vitor Sessakvitor1...@gmail.com escreveu: Olá Cláudio, Realmente é sempre melhor quando a pessoa que importa conhece a região, mas como tem uma quantidade enorme de dados a importar (esses do Rio são só o começo), eu acho que não dá para ser tão exigente. Logo sua contribuição é muito bem vinda! []'s -Vitor 2012/6/12 CLFerrazfer...@clferraz.com.br: Puxa, que pena, Vitor… Como novato, gostaria de contribuir, mas com uma região que eu conhecesse que é o caso de Teresópolis. A região que você cita fica fora da cidade pelo que estou entendento, mais próximo a Magé ou Baia da Guanabara… Praticamente desconheço essa região… Acho que o ideal seria fazer com conhecimento da área, estou correto? Me corrija se estiver errado... No caso de Teresópolis, tenho feito uso do Bing e circulado pela cidade com GPS. Comparo os resultados e faço os devidos ajustes… Agora, se der para fazer e contribuir mas sem conhecer a região, me coloco a disposição sim... []'s… Cláudio Em 12/06/2012, às 14:23, Vitor Sessak escreveu: Olá, Obrigado por avisar que alguns arquivos precisam ser simplificados. Os que eu tinha olhado não precisavam, logo eu conclui precipitadamente que todos estavam bons. A idéia do Aun de usar o JOSM funciona muito bem, mas eu gostaria de alguma coisa que eu pudesse automatizar, logo eu usei o --simplify do ogr2ogr e também deu certo (eu olhei no JOSM e a qualidade continua boa). Eu troquei todos os arquivos pelas versões simplificadas. De fato o tamanho diminuiu bastante. []'s -Vitor On 06/12/2012 01:46 PM, Stephane Goldstein wrote: Olá Vitor. Baixei o arquivo [1] para dar uma olhada. Será que não seria melhor simplificar estas vías antes de importa-las ? Não sei qual seria o melhor método para fazer isso, mas acho que elas estão com mais pontos do que o necessario, sobrecarregando a base e tornando o trabalho no JOSM muito lento. Abraço Stephane - Original Message - From: Vitor Sessak Sent: 06/11/12 07:09 PM To: OSM talk-br Subject: [Talk-br] Procura-se voluntários para importação IBGE Olá a todos, O IBGE disponibilizou recentemente uns mapas bem precisos do estado do Rio de Janeiro. Infelizmente, a unica maneira de importar esses dados pro OSM é por um procedimento semi-manual. Logo, eu estou procurando voluntários para me ajudar com este trabalho. Para quem estiver interessado em
Re: [Talk-br] Classificação de vias
Obrigado pela reposta. Estava mesmo pensando em estradas municipais que ligam um município a outro ou um distrito à sede do município. Vou continuar mapear-las como tertiary (dependente do fluxo de veículos). Hermann On 2012-06-15 15:52, Flavio Bello Fialho wrote: Nada é nunca. O mais importante é usar o bom senso. Supõe-se que uma estrada municipal não liga um município a outro, então a sua importância para o fluxo de veículos seria baixa. Pode haver alguma exceção. Por exemplo, se a estrada municipal não pavimentada é a principal via de ligação de um distrito (com centro urbano) à sede do município, talvez seja mais adequado classificá-la como tertiary. É difícil prever todas as possibilidades. Em 15-06-2012 04:06, Hermann Peifer escreveu: Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias
Acho que highway=track fica bom para uma estrada de acesso a uma fazenda, que passa por dentro da fazenda e não é usada para ir de uma localidade a outra. Em 15-06-2012 12:32, Rodrigo Avila escreveu: Pela descrição do wiki essa tag se aplica mais a uma estrada de roça do que a uma estrada de interior... Rodrigo Avila Em 15/06/2012 12:24, vitor vitor.geo...@gmail.com mailto:vitor.geo...@gmail.com escreveu: Talvez 'highway=track', não? http://wiki.openstreetmap.org/wiki/Tag:highway=track Vitor George mapaslivres.org http://mapaslivres.org twitter.com/mapaslivres http://twitter.com/mapaslivres 2012/6/15 Hermann Peifer pei...@gmx.eu mailto:pei...@gmx.eu Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/__wiki/Pt-br:Guia_de_Mapeamento___do_Territ%C3%B3rio_Brasileiro http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6Y0CQ0nG0@public.__gmane.org mailto:martin137-hi6y0cq0...@public.gmane.org escreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/__wiki/Pt-br:Guia_de_Mapeamento___do_Territ%C3%B3rio_Brasileiro http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/__wiki/Pt-br:Key:highway http://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.__br/cidade/secretarias/__habitacao/departamentos/aprov/__index.php?p=3303 http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 _ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.__org/listinfo/talk-br http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure.
Re: [Talk-br] Classificação de vias
Usar a tag unclassified para uma rodovia que foi *classificada* como municipal não-pavimentada eu acho contraditório. Na minha opinião deveria ser tertiary e surface=unpaved ou surface=ground. Já track, ou seja trilha me parece descrever uma caminho que não é usado corriqueiramente, por exemplo um caminho onde você não esperaria ter uma linha de ônibus. Mas o meu maior desconforto é ver que nenhum rederizador parece distinguir estrada com surface=unpaved de estrada com surface=paved. Quer dizer, se uma estrada é unclassified, tertiary, secondary etc é uma avaliação muitas vezes subjetiva e uma informação que não é crucial para o usuário. Mas a informação surface=ground ou surface=unpaved é uma informação totalmente objetiva e crucial e que não aparece para o usuário (me corrijam se eu estiver errado). A situação é mais ou menos a seguinte: você planeja uma viagem e consulta o mapa OSM na web, aí você vê que existe uma determinado caminho e planeja fazê-lo. Chegando lá você se depara com uma rota de 100 km de estrada de terra. Imagine isto em época de chuva. Ou seja, é uma informação que precisava saltar aos olhos, mas como? abraço Gerald 2012/6/15 Hermann Peifer pei...@gmx.eu Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/**wiki/Pt-br:Guia_de_Mapeamento_** do_Territ%C3%B3rio_Brasileirohttp://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6Y0CQ0nG0@public.**gmane.orgmartin137-hi6y0cq0...@public.gmane.orgescreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/**wiki/Pt-br:Guia_de_Mapeamento_** do_Territ%C3%B3rio_Brasileirohttp://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/**wiki/Pt-br:Key:highwayhttp://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.**br/cidade/secretarias/** habitacao/departamentos/aprov/**index.php?p=3303http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias
Eu poder dar um luz ai, Depende do fonte o classificacão das estradas e bem dificil. * Ate agora eu não teve como dividir meus trilhas gpx por areas asfaltadas e areas não asfaltadas, mas maioria dos meus trilhas gpx e dos estradas asfaltadas. * mapeamento por Bing e outros fontes com imagens aereal e mais fazil identificar onde e asfaltadas e onde e não, mas e dificil identificar se e um estrada principal ou não * mapeamento com fontes importadas as vezes tem informação adicional que poder por exemplo identificar areas asfaltadas ou não e também poder identificar que e estradas principal, secundario, etc. Eu acho que, afore dos estradas principais como BR-101, cohencimento local e necesario para identificar as ruas mais certo. A gente mapeando sem este precicar mapear por um padrao, e os locais ajuda com asertar os dados depois Aun Y. Johnsen Sent from my iPad On 15. juni 2012, at 18:13, Arlindo Pereira openstreet...@arlindopereira.com wrote: Pois é. Na verdade, ela é subjetiva por ser uma classificação oficial da Inglaterra, onde o OpenStreetMap surgiu. Acho a solução de colocar a observação razoável, embora não a ideal. Não deixando de colocar as tags surface=* apropriadas, não vejo porque seria um problema. Infelizmente isso é um bocado fora da minha realidade pois vivo na cidade grande, não dirijo, viajo de ônibus ou de avião etc., meu mapeamento é 100% metropolitano. []s 2012/6/15 Gerald Weber gwebe...@gmail.com Olá eu concordo totalmente que não se deva colocar tags incorretas apenas para fazer aparecer num dado renderizado alguma coisa específica, e nem sequer proponho isto. Até porque seria inútil, já que cada renderizador mostra as coisas do jeito que quer. O que me chama a atenção no entanto é que a classificação da via (tertiary, secondary etc) é subjetiva e nem sequer tão útil, mas é mostrada. Por outro lado não se dá ao usuário qualquer dica de que ele está olhando para uma estrada de terra e não de asfalto. Em todos os mapas que eu conheço esta é a informação mais elementar que existe. No mapnik e todos os outros renderizadores que vi esta informação inexiste. Uma maneira de contornar isto seria adicionar ao nome da estrada terra ou em terra. Eu vejo isto nos mapas do tracksource e acho bem efetivo pois garante que a informação é transmitida independente do renderizador. Tipo name=BR 123 (em terra) nos trechos apropriados. Não compromete nada e passa a informação garantidamente. Afinal de que serve colocar todo o esforço em mapear e depois uma informação tão crucial fica simplesmente perdida? Enfim, se me permite emprestar a frase: don't tag for the renderer, map for the user ;) abraço e bom final de semana Gerald 2012/6/15 Arlindo Pereira openstreet...@arlindopereira.com Me parece que isso é problema do renderizador (leia-se, do Mapnik), não nosso. É aquele mantra, don't tag for the renderer. http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer O que não quer dizer que a gente não tenha que resolver, em absoluto. Mas não vai ser escolhendo tags diferentes das que já existem, mas sim fazendo o renderizador entender as tags que já são usadas. []s 2012/6/15 Gerald Weber gwebe...@gmail.com Usar a tag unclassified para uma rodovia que foi classificada como municipal não-pavimentada eu acho contraditório. Na minha opinião deveria ser tertiary e surface=unpaved ou surface=ground. Já track, ou seja trilha me parece descrever uma caminho que não é usado corriqueiramente, por exemplo um caminho onde você não esperaria ter uma linha de ônibus. Mas o meu maior desconforto é ver que nenhum rederizador parece distinguir estrada com surface=unpaved de estrada com surface=paved. Quer dizer, se uma estrada é unclassified, tertiary, secondary etc é uma avaliação muitas vezes subjetiva e uma informação que não é crucial para o usuário. Mas a informação surface=ground ou surface=unpaved é uma informação totalmente objetiva e crucial e que não aparece para o usuário (me corrijam se eu estiver errado). A situação é mais ou menos a seguinte: você planeja uma viagem e consulta o mapa OSM na web, aí você vê que existe uma determinado caminho e planeja fazê-lo. Chegando lá você se depara com uma rota de 100 km de estrada de terra. Imagine isto em época de chuva. Ou seja, é uma informação que precisava saltar aos olhos, mas como? abraço Gerald 2012/6/15 Hermann Peifer pei...@gmx.eu Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip ---
Re: [Talk-br] Classificação de vias
Essa discussão tá interessante! Um problema em se usar as imagens aéreas (como o Aun sugeriu) para distinguir vias asfaldas e não-asfaltadas é que muitas vezes houve uma obra entre a data da fotografia e os dias atuais, ou então a imagem tem saturação muito alta e não dá pra distinguir estrada de chão de paralelepípedo, pisos intertravados, etc. Eu desisti de colocar a tag surface=* nas ruas de Marataízes-ES [1] por causa disso, quando vou lá pessoalmente às vezes tem muitas ruas que estão diferentes. Já em áreas mais metropolitanas ainda tenho minhas dúvidas. Por exemplo, tudo bem que trunk na cartilha é para vias duplicadas, mas não serveriam para binários de ligam duas vias duplicadas? E ainda existem bairros com ruas que podem ter várias interpretações e, sinceramente, não sei o que fazer. Vou dar o exemplo de onde edito, no Rio de Janeiro, onde há muito o caso de múltiplas interpretações, já que existem muitos bairros de passagem pela própria geografia: Em Copacabana [2], existe um binário (Barata Ribeiro/Nossa Senhora de Copabana) e uma via duplicada (Av. Atlântica) de velocidades semelhantes (60/70). Pela cartilha, o binário pode variar de tertiary até primary e Av. Atlântica de tertiary (por ter maior vocação turística) até trunk. Nos bairros vizinhos de Ipanema e Leblon, a situação é parecida por terem o mesmo dilema binário + via duplicada turística. Ainda em Copacabana, existem alguns dilemas tertiary-secondary como: - Av. Henrique Dodsworth (Corte do Cantagalo) [3]: liga Copacabana à Lagoa, mas serve até para Ipanema. - Túnel Velho + binário Siqueira Campos - Figueiredo de Magalhães [4]: liga Copacabana a Botafogo, mas serve para todos que tem como destino bairros após Copacabana. 1: http://www.openstreetmap.org/?lat=-21.052lon=-40.8272zoom=13layers=M 2: http://www.openstreetmap.org/?lat=-22.9712lon=-43.1841zoom=14layers=M 3: http://www.openstreetmap.org/?lat=-22.976794lon=-43.195811zoom=18layers=M 4: http://www.openstreetmap.org/?lat=-22.9643lon=-43.18969zoom=17layers=M Em 15/06/12, Aun Yngve Johnsenli...@gimnechiske.org escreveu: Eu poder dar um luz ai, Depende do fonte o classificacão das estradas e bem dificil. * Ate agora eu não teve como dividir meus trilhas gpx por areas asfaltadas e areas não asfaltadas, mas maioria dos meus trilhas gpx e dos estradas asfaltadas. * mapeamento por Bing e outros fontes com imagens aereal e mais fazil identificar onde e asfaltadas e onde e não, mas e dificil identificar se e um estrada principal ou não * mapeamento com fontes importadas as vezes tem informação adicional que poder por exemplo identificar areas asfaltadas ou não e também poder identificar que e estradas principal, secundario, etc. Eu acho que, afore dos estradas principais como BR-101, cohencimento local e necesario para identificar as ruas mais certo. A gente mapeando sem este precicar mapear por um padrao, e os locais ajuda com asertar os dados depois Aun Y. Johnsen Sent from my iPad On 15. juni 2012, at 18:13, Arlindo Pereira openstreet...@arlindopereira.com wrote: Pois é. Na verdade, ela é subjetiva por ser uma classificação oficial da Inglaterra, onde o OpenStreetMap surgiu. Acho a solução de colocar a observação razoável, embora não a ideal. Não deixando de colocar as tags surface=* apropriadas, não vejo porque seria um problema. Infelizmente isso é um bocado fora da minha realidade pois vivo na cidade grande, não dirijo, viajo de ônibus ou de avião etc., meu mapeamento é 100% metropolitano. []s 2012/6/15 Gerald Weber gwebe...@gmail.com Olá eu concordo totalmente que não se deva colocar tags incorretas apenas para fazer aparecer num dado renderizado alguma coisa específica, e nem sequer proponho isto. Até porque seria inútil, já que cada renderizador mostra as coisas do jeito que quer. O que me chama a atenção no entanto é que a classificação da via (tertiary, secondary etc) é subjetiva e nem sequer tão útil, mas é mostrada. Por outro lado não se dá ao usuário qualquer dica de que ele está olhando para uma estrada de terra e não de asfalto. Em todos os mapas que eu conheço esta é a informação mais elementar que existe. No mapnik e todos os outros renderizadores que vi esta informação inexiste. Uma maneira de contornar isto seria adicionar ao nome da estrada terra ou em terra. Eu vejo isto nos mapas do tracksource e acho bem efetivo pois garante que a informação é transmitida independente do renderizador. Tipo name=BR 123 (em terra) nos trechos apropriados. Não compromete nada e passa a informação garantidamente. Afinal de que serve colocar todo o esforço em mapear e depois uma informação tão crucial fica simplesmente perdida? Enfim, se me permite emprestar a frase: don't tag for the renderer, map for the user ;) abraço e bom final de semana Gerald 2012/6/15 Arlindo Pereira openstreet...@arlindopereira.com Me parece que isso é problema do renderizador (leia-se, do Mapnik), não nosso. É aquele mantra, don't
Re: [Talk-de] Historie und ID in JOSM
Hi, On 06/14/12 13:18, Markus wrote: Jetzt suche ich noch den Link, der das Objekt und seine Historie zeigt. (also mit dem man Dritten zeigen kann: schau mal hier...) http://www.openstreetmap.org/browse/objekttyp/id/history Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Elektrotankstelle E fahrrad / Pedalec
charging:voltage=230 das macht schon mal klar, daß es eine normale Steckdose ist. [...] Für die Steckdosen könnte man sich auf Wikipedia beziehen: http://de.wikipedia.org/wiki/**L%C3%A4nder%C3%BCbersicht_** Steckertypen,_Netzspannungen_**und_-frequenzenhttp://de.wikipedia.org/wiki/L%C3%A4nder%C3%BCbersicht_Steckertypen,_Netzspannungen_und_-frequenzen und A, B, ... bis M [...] eigentlich klar, welcher Stecker bei 230 Volt, aber z.B. ergänzt um: charging:plug=euro Hm? Wieso gibst du einen Wikipediaartikel mit mind. drölfzig verschiedenen Steckertypen für 230V an und schreibst dann wiederholt, dass es doch bei 230V 'klar' sei, um welchen Steckertyp es sich handelt? Ich wäre von einer Eurobuchse dann doch sehr überrascht, wenn mein Ladegerät einen Schukostecker hat. Und dann gibt's noch die CEE Stecker, die auf der Wikiseite gar nicht aufgeführt sind ...( http://de.wikipedia.org/wiki/IEC_60309) Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Planetauszug
Hallo, gibt es eigentlich irgendwann mal wieder einen kompletten Planetdump? -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetauszug
Hi Carsten, Carsten Schwede schrieb: gibt es eigentlich irgendwann mal wieder einen kompletten Planetdump? auf [1] entsteht gerade wieder ein offizieller Dump. Also vielleicht noch ein paar Stunden warten, dann ist wieder einer verfügbar. Ansonsten gibt es laut Wiki[2] auch andere Seiten [3], die wohl einen aktuellen Dump anbieten. viele gruesse pascal [1] http://planet.openstreetmap.org/pbf/ [2] http://wiki.openstreetmap.org/wiki/Planet.osm#Worldwide_data [3] ftp://ftp.pucpr.br/osm/mirror/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetauszug
Hallo, On 06/15/12 09:44, Carsten Schwede wrote: gibt es eigentlich irgendwann mal wieder einen kompletten Planetdump? Hier ist eins vom 13.6. http://amygdala.geofabrik.de/planet-100613.osm.pbf passendes state.txt: http://amygdala.geofabrik.de/state-100613.txt Das ist aber kein regelmaessiger Service. Von OSM gibt es bis zum Abschluss des Lizenzwechsels nur sporadisch Planetfiles. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *** GMX Spamverdacht *** Re: Planetauszug
Hallo Pascal, danke, habs gerade auch wieder entdeckt, ich war wohl erst etwas zu früh. :-) Die anderen Seiten hatte ich auch angesehen, da lag bis vorhin auch immer nur der Dump vom 8. Mai. Deshalb hatte ich mal gefragt. On 06/15/12 09:58, Pascal Neis wrote: auf [1] entsteht gerade wieder ein offizieller Dump. Also vielleicht noch ein paar Stunden warten, dann ist wieder einer verfügbar. Ansonsten gibt es laut Wiki[2] auch andere Seiten [3], die wohl einen aktuellen Dump anbieten. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Piktogramme als SVG
Hallo, gibt es die Piktogramme (kleiner Brezel für Bäcker und die Symbole für Bank, Telefon, Briefkasten, ...), die Mapnik zum Rendern verwendet, irgendwo auch als Vektorgrafik? Wenn man die Karte in SVG rendern lässt und das ganze dann auf Plakatgröße großzieht, dann sehen die Raster-Piktogramme doch etwas arm aus... Danke im Voraus Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Schul-klassifikation
Im Wiki gibt es dieses Proposal zur feineren Klassifikation von Schulen: http://wiki.openstreetmap.org/wiki/Proposed_features/ISCED im Prinzip ein sinnvoller Vorstoß, aber leider ist in der Praxis das vorgeschlagene System eher noch nicht ausreichend für Deutschland. Die Sekundarstufe I ( http://de.wikipedia.org/wiki/Sekundarstufe_I ) z.B. umfasst alle gängigen Schultypen wie Hauptschule, Realschule und Gymnasium. Weiss zufällig jemand, ob es ein (möglichst internationales) System gibt (evtl. Subsystem zu ISCED), das eine genauere Unterscheidung zulässt? evtl. subtags für deutsche Schultypen? Oder verlassen wir uns auf den Namen wie bisher? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schul-klassifikation
Hallo, Am 15.06.2012 14:29, schrieb Martin Koppenhoefer: Oder verlassen wir uns auf den Namen wie bisher? In Frankreich wird der Schultyp mit school:FR getaggt: http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool Ich halte das für einen vernünftigen und pragmatischen Ansatz. Wenn man das in Deutschland auch so macht, dann kann später automatisiert ein ISCED-Tag oder eine OSM-spezifische internationale Klassifizierung hinzugefügt werden. Selbst wenn eine internationale Klassifizierung eine Abbildung aller deutschen Schultypen erlaubt, würde ich nicht auf den deutschen Schultyp verzichten. Auf taginfo wird school:de zwar 1670 mal aufgeführt, ich habe das Tag aber bei ein paar Stichproben nicht gefunden, auch kein Wiki-Eintrag dazu. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klärbecken...
Jan Tappenbeck o...@tappenbeck.net wrote: building=yes wäre wohl etwas mehr als daneben - eine Idee ? natural=water *duck* Sven -- Dynamische IP-Nummern sind Security-Homöopathie. (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schul-klassifikation
Am 15.06.2012 15:18, schrieb Rainer Kluge: Auf taginfo wird school:de zwar 1670 mal aufgeführt, ich habe das Tag aber bei ein paar Stichproben nicht gefunden, auch kein Wiki-Eintrag dazu. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Wiki ist leider aus der Mode gekommen. Hier z.b. eine glaube recht gut (mit tags) ausgestattet Schule: http://www.openstreetmap.org/browse/node/651294435 LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klärbecken...
Jan Tappenbeck o...@tappenbeck.net wrote: building=yes wäre wohl etwas mehr als daneben - eine Idee ? Au ja einheitlich getaggte Kläranlagen wären mal was, dann könnte ich vielleicht endlich meine Theorie bestätigen, dass diese sich immer neben Fernradwegen befinden :) Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Piktogramme als SVG
Manuel Reimer manuel.s...@nurfuerspam.de wrote: gibt es die Piktogramme (kleiner Brezel für Bäcker und die Symbole für Bank, Telefon, Briefkasten, ...), die Mapnik zum Rendern verwendet, irgendwo auch als Vektorgrafik? Jepp, das ist die SJJB Icon collection: http://www.sjjb.co.uk/mapicons/ Sven -- How to prevent Java from forking? Use a spoon. (Found on http://slashdot.org) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schul-klassifikation
stimmt, der Eintrag ist ja auch von mir ;) In absehbarer Zeit sehen die meissten Schulen in Hessen so aus (mehr Daten und Zeit/Lust hab ich nicht). Näheres hier: http://wiki.openstreetmap.org/wiki/DE:Hesse/Schools wobei ich das mir zu komplexe Zusatztagging auf ein absolutes Minimum reduziert habe - was man bei dem Beispiel wohl sehen kann. Gruss Walter p.s. Danke für die bisher sehr rege Mitarbeit :( und hier noch der alte Thread dazu: http://gis.19327.n5.nabble.com/Liste-aller-hessischen-Schulen-verfugbar-td5590833.html -- View this message in context: http://gis.19327.n5.nabble.com/Schul-klassifikation-tp5712957p5713006.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klärbecken...
Am 14. Juni 2012 14:29 schrieb Martin Koppenhoefer dieterdre...@gmail.com: nicht gerade mein Spezialgebiet, aber dieses Wort (tailings) finde ich im Netz vor allem in Bezug zu Bergbau und diesbezüglichen Absetzbecken. Sind wir sicher, dass das das richtige Wort ist? ich habe diesbezüglich mal auf tagging nachgefragt und die Antwort war, dass das tatsächlich für Kläranlagen nicht zu passen scheint: http://lists.openstreetmap.org/pipermail/tagging/2012-June/010603.html Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Hallo, noch eine weitere Ergänzung meinerseits für das Taggingschema: Ich habe mir gedacht, dass man Fabriken, Industriebetriebe, etc., die über einen Gleisanschluss verfügen, mit einem besonderen Tag kennzeichnet. So würde z.B. ein Chemiewerk oder ein kleiner Landhandel zusätzlich zu man_made=works (oder als was das auch immer getaggt ist) ein Tag wie etwa railway_access=yes erhalten. Mit dem Tag wäre es dann möglich, solche Betriebe auch der Karte zu rendern. So sieht man schnell, welche Firmen einen Bahnanschluss haben. Außerdem ist es etwa für Bahnunternehmen interessant, die bei einer Lieferung an Firma X schnell sehen können, wie man dort hingelangt. Auch für Bahninteressierte ist es in Simulatoren oder rein aus Interesse von Relevanz. Bereits existierende Eisenbahn-Atlanten zeigen zumindest die größeren Fabriken mit Bahnanschluss auf der Karte... Was haltet ihr von dieser Idee? Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von Grenzen - remappen?
Martin Koppenhoefer dieterdre...@gmail.com wrote: genau, darum ging es hier ja: der OP hatte Grenzsteine gefunden, die nicht mit den OSM-Grenzen übereinstimmen. Wenn man die Grenzsteine überhaupt erstmal nicht findet, ist das Problem natürlich anders. Klar, nicht immer sind die Grenzsteine einfach aufzufinden. Mir ging es darum zu zeigen, dass jeder wie auch immer geartete Versuch, Grenzen präzise vor Ort zu erfassen, in aller Regel scheitert. Denn die alten Steine über der Erde sind ungenau, die neuen genauen befinden sich unter der Erde und teilweise zudem an unzugänglichen Orten. OSM hat also keine Möglichkeit, einigermaßen korrekte Grenzen anzugeben. Mir geht es darum, diesen Status Quo zu verifizieren. Denn damit hätte man ein gutes Argument dafür, dass die Urheber und damit einzigen Quellen (die Katasterbehörden) zumindest diese Daten anstatt wie bisher proprietär in Zukunft frei zur Verfügung stellen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von Grenzen - remappen?
Bernhard Weiskopf bweisk...@gmx.de wrote: Beim Stand der Vermessungstechnik sind auch gar keine Grenzsteine mehr notwendig, es gibt genügend Vermessungspunkte oder andere Fixpunkte, auf die man sich beziehen kann. Die beiden Flächen-Anlieger müssen sich nur über den Verlauf bzw. dessen Koordinaten einigen. Zumindest im hiesigen Raum ist Jeder verpflichtet, seine Grundstücke von der Katasterbehörde einmessen und mit Grenzsteinen versehen zu lassen sowie dies zu bezahlen. Jeder Bauherr orientiert sich beim Bau seines Eigenheims an den Grenzsteinen des Grundstücks. Hierzu muss er bei der Katasterbehörde Pläne mit deren Lage kaufen und diese ausgraben. So kann er dann die Vorschriften wie Abstand des Hauses von der Grenze, Einhalten des Sichtdreiecks an Straßenecken (z.B. beim Hecken) befolgen. Letzteres gilt z.B. auch für Bauern bei der Bepflanzung des Ackers. Ohne Steine würde das schon sehr aufwendig. Man müsste jedes Mal ein Vermessungsbüro beauftragen. Von daher kann ich mir nicht vorstellen, dass die theoretische Möglichkeit des Verzichts auf Steine in der Praxis Anwendung findet - zumindest solange nicht, wie es keine verbreitete und hinreichend genaue Vermessungsmethode für Jedermann gibt. Da hier nun jedes Grundstück ein Flurstück darstellt, dieses ein Teil eines Flures - Gemarkung - Ortsteil - Kommune - Landkreis ist, lässt sich auch jede administrative Einheit anhand dieser Grenzsteine ausmachen. Darin wäre dann auch der Einigungsvorgang der Flächenanlieger dokumentiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] relation analyzer
Il 13 giugno 2012 13:56, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: Segnalo un update al relation analyzer: http://ra.osmsurround.org/ (purtroppo solo in tedesco) io ce l'ho in inglese... ciao, Martin -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Nuova versione editor Meraartor 0.18
Per chi come me e' un po' allergico a Java, segnalo che e' uscita la nuova versione dell'editor Merkaartor: la 0.18.1 La potete trovare al sito [1] Saluti Fabrizio [1] http://merkaartor.be/projects/merkaartor/news ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Cambiare i nomi Valle d'Aosta e Trentino-Südtirol/Alto Adige
Am 14.06.2012 23:11, schrieb Daniele Forsi: Il 14 giugno 2012 18:50, Luca Delucchilucadel...@gmail.com ha scritto: On 14 Jun 2012 12:59, Elena ``of Valhallaapos;apos; elena.valha...@gmail.com wrote: On 2012-06-14 at 11:59:45 +0200, Daniele Forsi wrote: la contraddizione per me sta nel sostenere che un nome di un oggetto che si trova in Italia (name) possa essere diverso dal nome in italiano di quell'oggetto (name:it); e perche' mai? un oggetto che si trova in svizzera può tranquillamente avere una combinazione di nomi in tedesco, francese, italiano e romancio, con magari tutti questi nomi combinati nel nome ufficiale dell'oggetto, ma non e` che il nome ad esempio tedesco comprenda anche quello nelle altre lingue. +1 ma la Svizzera non ha una Costituzione della Repubblica Italiana che ha rinominato la Valle d'Aosta in Valle d’Aosta/Vallée d’Aoste, per cui secondo me il nome italiano è composto da entrambe le parti, ma a parte l'art. 116 non ho trovato conferme, nemmeno nello Statuto della Regione (in quale tag vada messo il nome doppio e quelli singoli è un altro discorso) Un altro esempio (che però non è più valido): L'Alto Adige fino agli anni ´70 era conosciuto ufficialmente dal nome tedesco Tiroler Etschland, mentre in Austria e Germania (e anche in Alto Adige) tutti parlavano di Südtirol. Quale name:de ci metteresti? -- cheers, Alex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Istituti comprensivi
2012/6/14 Alessio Zanol nar...@infinito.it Ciao, sull'onda del tag per il grado scolastico (isced:level) sto pensando a come si possa definire un istituto comprensivo. Le idee che mi son venute sono: * una relation.. ma di che tipo? site? A volte le varie scuole sono adiacenti ma spesso son separate anche di chilometri. Vale ancora la definizione di site? * un tag che potrebbe essere operator=* o network=*. Esempio operator=Istituto Comprensivo Osmotico Altre idee? Alessio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it Se n'era già parlato un po', senza però concludere nulla: http://lists.openstreetmap.org/pipermail/talk-it/2012-February/026785.html ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Classificazione scuole
Stando a Wikipedia[1], nella pagina wiki su ref:ISCED[2] c'era un errore nella conversione con le scuole italiane. L'ho corretto. [1] http://it.wikipedia.org/wiki/ISCED [2] http://wiki.openstreetmap.org/wiki/Proposed_features/ISCED 2012/6/14 Martin Koppenhoefer dieterdre...@gmail.com 2012/6/14 Sky One sky...@skyone.it: 2012/6/14 Martin Koppenhoefer dieterdre...@gmail.com: 2012/6/13 Alessio Zanol nar...@infinito.it: Ciao, iniziamo a usare isced:level=* per indicare il grado delle scuole? si, bella iniziativa, usiamo 'ste livelli... Ma non sarebbe il caso, prima, di far diventare attiva la proposta? fatto ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Grandi boschi e multipoligoni
groppo otto wrote C'è qualche cosa di cui tener conto per questo secondo approccio? es. un limite alla grandezza di questi multipoligoni, numero di nodi, numero way... ? Io uso multipoligoni e non credo esistano limiti ne di numero di way ne di nodi. C'è il limite di 2000 punti per way. Inoltre nei multipoligoni assegni il ruolo landuse=forest solamente alle proprietà del multipoligono e no alla singola way. Ciao Simone -- View this message in context: http://gis.19327.n5.nabble.com/Grandi-boschi-e-multipoligoni-tp5712813p5712913.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Grandi boschi e multipoligoni
Il 15/06/2012 11:45, morsi ha scritto: groppo otto wrote C'è qualche cosa di cui tener conto per questo secondo approccio? es. un limite alla grandezza di questi multipoligoni, numero di nodi, numero way... ? Io uso multipoligoni e non credo esistano limiti ne di numero di way ne di nodi. C'è il limite di 2000 punti per way. Inoltre nei multipoligoni assegni il ruolo landuse=forest solamente alle proprietà del multipoligono e no alla singola way. Anch'io uso i multipoligoni, principalmente per motivi di render (sì, lo so, non si dovrebbe...). A parte le linee bianche di mapnik, son molto più fastidiose le linee verdi dei bordi vegetazione della cyclemap, che tendono a creare confusione. Per contro le aree possono diventare molto grandi, e quando devi apportare qualche modifica devi prima scaricarti relazioni enormi... Comunque molto spesso avrai a che fare con dei buchi nella vegetazione, quindi le relazioni saranno quasi d'obbligo. Ciao Marco ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Grandi boschi e multipoligoni
2012/6/15 marcram marcr...@email.it: Anch'io uso i multipoligoni, principalmente per motivi di render (sì, lo so, non si dovrebbe...). Per contro le aree possono diventare molto grandi, e quando devi apportare qualche modifica devi prima scaricarti relazioni enormi... Comunque molto spesso avrai a che fare con dei buchi nella vegetazione, quindi le relazioni saranno quasi d'obbligo. +1, anch'io non vedo alternative a multipoligoni in tanti casi (buchi, features a canto). Le relazioni hanno anche il loro senso quando una foresta è delimitata da altri features (per esempio landuse=farmland) che così si possono riutilizzare parti dei way. In generale consiglio (e cerco di farlo) di spezzare le foreste ovunque possibile. Cercate di fare sempre il poligono più piccolo quando possibile. Per esempio ad ogni strada (al meno quelle grandi) spezzo la foresta in 2 foreste. Cogliete ogni possibilità di spezzare una foresta! Poi cercate di avere solo un poligono in ogni relazione (anche con più outer ways che insieme creano un poligono, ma non con più poligoni chiusi e disgiunti nella stessa relazione). All'inizio non avevo fatto così e dopo un po di mappatura dettagliata mi sono ritrovato con delle foreste di 800+ membri. Un incubo sia per spezzare che per modificare che anche per renderizzare o elaborare. Pensiamo sempre che non creiamo l'ultima versione, ma che deve essere anche consecutivamente modificabile. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Nomi dei Comuni nelle relazioni con piccole differenze rispetto a quelli ISTAT
2012/6/13 Daniele Forsi dfo...@gmail.com n 69300019 name=Reggio nell'Emilia, place=city r 43415 name=Reggio Nell'emilia, admin_level=8 (tanti nomi importati hanno errori di maiuscole/minuscole) r 42965 name=Reggio Emilia, admin_level=6 Questi nomi sono corretti (a meno di maiuscole/minuscole): la provincia è Provincia di Reggio Emilia [1] (senza preposizione) mentre il comune è Comune di Reggio nell'Emilia [2] (con la proposizione). Poi, in realtà, spesso si usa Reggio Emilia anche per indicare il comune, ma questo andrebbe segnalato come alt_name o qualcosa del genere... [1] http://www.provincia.re.it/ [2] http://www.municipio.re.it/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Grandi boschi e multipoligoni
Grazie per le risposte. Per disegnare landuse ho trovato utili questi due strumenti, nel caso qualcuno non li conoscesse: - disegnare una way che condivide un lungo tratto con un'altra, es. campo coltivato confinante con un bosco (se non si fa appartenere la way a due multipoligoni), basta premere f in successione http://josm.openstreetmap.de/wiki/Help/Action/FollowLine - creare automaticamente una way parallela ad una preesistente, es. creare il lato di un bosco parallelo ad una strada http://josm.openstreetmap.de/wiki/Help/Action/Parallel Ciao, Groppo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Una ayuda para efectuar correcciones
Hola 2012/6/15 Igor TAmara i...@tamarapatino.org: Hola, en [1] coloqué un servicio que permite identificar nombres de vías que podrían ser incorrectos, creo que complementa el trabajo de #botika en el sentido de que no es tan fácil predecir los errores en el nombramiento de vías que los humanos podemos llegar a crear o inventar :) 1.http://test.openstreetmap.co:5000/ magnifica herramienta, al comienzo no la entendia pero en esta imagen dejo la clave para el uso: https://picasaweb.google.com/lh/photo/gm-mJ3Tz-U_MT6L3sWC0OHbP0MnqbN2SUasQHilZlX8 Será mucho pedir que tenga un link al control remoto de josm asi: http://www.openstreetmap.org/edit?editor=remotelat=6.24491lon=-75.58977zoom=17 ? salu2 La idea de este servicio es evidenciar dónde estarían los posibles problemas para que podamos corregirlos manualmente. En realidad solamente se muestran los errores, pero sería bueno abrir potlatch2, o también alimentar la base de conocimiento de ella para que sepa qué cosas debería corregir, que le enseñáramos qué debería corregir :) Más ideas son bienvenidas. Tanto para el mapa como para botika :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Una ayuda para efectuar correcciones
Que buena realimentación :) . Hay varias cosas en el todo para la herramienta * help tool : Vamos a tener varios tabs y en cada uno hay una ayuda, el screenshot que ofreciste es inspirador * satélite hires frame : Podríamos ver los bounding box de los lugares que tienen cobertura bing o de otras fuentes chéveres. Ahí lo único que hay que hacer es haber marcado las hires en openstreetmap y de allí obtenemos los datos. * CSS improvement : Soy un ignorante respecto a CSS, así que si hay alguien que quiera ayudar a estilizar, sería súper. * select way : Cuando se selecciona una vía habría opción para usar el enlace de JOSM o el de openstreetmap, no se si potlatch2 tenga algo parecido. * unnamed ways : Habrá otro tab para que podamos identificar las zonas que tienen muchas vías sin nombre, para organizar las sesiones de mapeo en campo :) * Geolocalisation tab : Vamos a integrar la herramienta anterior de geolocalización inversa en un tab :) Todas estas ideas las voy a tratar de colocar en Trello para que haya una especie de roadmap, y por supuesto podamos estar trabajando. Quiénes quieran unirse a desarrollar, chévere, porque se está usando : postgresql 9.1 postgis 1.5.3 Flask 0.8 openlayers 1.10 (Trataré de migrar a 1.11) jquery La idea es que podamos saber qué otras necesidades vemos para facilitar la corrección de datos y su complementación. Tenemos que seguir mirando qué otra organización visual podríamos tener. Si alguien desea hacerse un mockup de cómo se imagina la aplicación, pues bienvenido, porque esa es la área en la que soy no hábil, y por supuesto, más que un mockup, sería ideal un marcado y los css. :D El 15 de junio de 2012 05:30, Fredy Rivera fredyriv...@gmail.com escribió: Hola 2012/6/15 Igor TAmara i...@tamarapatino.org: Hola, en [1] coloqué un servicio que permite identificar nombres de vías que podrían ser incorrectos, creo que complementa el trabajo de #botika en el sentido de que no es tan fácil predecir los errores en el nombramiento de vías que los humanos podemos llegar a crear o inventar :) 1.http://test.openstreetmap.co:5000/ magnifica herramienta, al comienzo no la entendia pero en esta imagen dejo la clave para el uso: https://picasaweb.google.com/lh/photo/gm-mJ3Tz-U_MT6L3sWC0OHbP0MnqbN2SUasQHilZlX8 Podría usar esa imagen para ayuda embebida en la aplicación? Será mucho pedir que tenga un link al control remoto de josm asi: http://www.openstreetmap.org/edit?editor=remotelat=6.24491lon=-75.58977zoom=17 ? Eso está contemplado, creo que habría updates semanales de la aplicación. salu2 La idea de este servicio es evidenciar dónde estarían los posibles problemas para que podamos corregirlos manualmente. En realidad solamente se muestran los errores, pero sería bueno abrir potlatch2, o también alimentar la base de conocimiento de ella para que sepa qué cosas debería corregir, que le enseñáramos qué debería corregir :) Más ideas son bienvenidas. Tanto para el mapa como para botika :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Ayuda aplicación fotos/gpx
Hola El josm tiene la utilidad de sincronizar las fotografias. Pàra ello basta subir la traza al josm y en la capa darle click derecho alli aparecen las opciones de cargar fotos. Enviado desde BlackBerry® de COMCEL S.A. -Original Message- From: hyan...@gmail.com hyan...@gmail.com Date: Fri, 15 Jun 2012 18:24:28 To: OpenStreetMap Colombiatalk-co@openstreetmap.org Reply-To: OpenStreetMap Colombia talk-co@openstreetmap.org Subject: [Talk-co] Ayuda aplicación fotos/gpx ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-dk] kommunegrænser og fysiske objekter
Hej folkens først og fremmest super godt arbejde, til ham/hun/dem der har tegnet alle kommune grænserne ind, det må have været et kæmpe arbejde. jeg har dog et enkelt spørgsmål (delt op i to spørgsmål). Er kommune grænserne defineret ud fra geografiske objekter? på linket ses en å der ligger næsten sammenfaldende med kommunegrænsen, men følger grænsen i virkeligheden åen? http://www.openstreetmap.org/?lat=55.87008lon=9.71424zoom=15layers=M hvis kommunegrænsen følger åen, så kunne man måske med fordel sammenkøre kommunegrænsen med de fysiske objekter, vha nogen multi polygoner? joris ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
hej ivan, der er vist noget med dine æ ø å'er? ja den er hurtigt, hvilket jeg synes giver en god brugeroplevelse. det er sjovt at kunne prøve sig lidt frem ved at flytte rundt på markørerne. der er lagt data ind for danmark og sverige. det er derfor du ikke kan lave en rute til berlin. man kan sagtens lægge data ind for et større område, men det kræver mere RAM og mere tid til at behandle data. tror du ikke det bliver kompliceret at tage højde for fejl i OSM? jeg tror generelt det bedste er at få rettet fejlene i selve datakilden. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk mailto:z...@tmf.kk.dk Fra: Ivar Madsen [mailto:lists.openstreetmap@milli.dk] Sendt: 14. juni 2012 21:14 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] Cykelruteplanlæggeren Den er godtnok ekstrem hurtig. B夥 til at vise kort, n岠man flyter p堤et, eller zoomer ind/ud, og n岠man laver en route. Jeg forsgte mig med en route fra V沥brovej, til Tinghjvej, den valgte en route langs Hillerd motorvejen, men ved ring 3, var cykelstien knyttet til mororvejs linket, over Ring 3, det er en fejl i OSM, som jeg s堨ar rettet, men m峫e man kunne tage hjde for den slags fejl i OSM, og lave routen den vej alligevel? Jeg forsgte mig ogs堭ed en route i Berlin, men det ville den ikke v沥 med til, hvorfor ikke? -- Med venlig hilsen Ivar Madsen Mandag den 4. juni 2012 09:55:17 Emil Tin skrev: hej janus, planen er en alpha version p堷eb denne m宥d, og s堦orbedringer hen over sommeren/efter岥t. app'en vil formodentligt flge et par m宥der efter. vi flger en s嫡ldt 'agile' proces, hvor borgerne kan komme med input og kommentarer fra den frste alpha version, og p堤en m夥 v沥 med til at forme lsningen. du kan se en prototype p庠http://stormy-flower-5599.herokuapp.com/ v沠opm沫som p堡t den ikke (endnu) fungerer i internet explorer, s堢rug firefox eller chrome. prototypen er mest en test af selve ruteberegningen - der kommer en ny brugergr殳eflade, andre funktioner, etc. cykelsuperstierne er interesserede i at udbrede lsningen til region hovedstaden, og vi har en t洠kontakt til dem. en af de udfordringer vi har er jura ifht at gre kortdata frit tilg殧elige. i indstillingen stod at data s堶idt muligt skal gres tilg殧elige for kommercielle aktrer og andre. men desv沲e er juristerne pt bekymrede for om det er konkurrenceforvridende. det er et synspunkt jeg personligt mener er problematisk. mange andre byer l槧er jo fx masser af offentlige data ud, og skaber p堤en m夥 grobund for innovation. ring endeligt hvis du vil vide mere. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KENHAVNS KOMMUNE Teknik- og Miljforvaltningen Center for Trafik Islands Brygge 37 V沮 118 Postboks 450 2300 Kbenhavn S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk -Oprindelig meddelelse- Fra: Janus Sandsgaard [mailto:j...@oim.dk] Sendt: 4. juni 2012 09:38 Til: OpenStreetMap Denmark Emne: [Talk-dk] Cykelruteplanl槧eren Hej Emil Efterh室en l殧e siden. Er nysgerrig p堨vordan det g岠med den mobile cykeruteplanl槧er - bare et par stikord p堨vor langt I er, om der er sten p堶ejen for projektet etc. Er der et sted jeg kan l泥 om det, eller er det bedre med uformel snak p弯p tlf.? Mvh janus Janus Sandsgaard ثonomi- og Indenrigsministeriet Afdeling for offentlig fornyelse og velf沤spolitik Slotsholmsgade 10-12 - 1216 Kbenhavn K - Tlf. 7228 2400 - www.oim.dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
[Talk-dk] Wheelmap nævnt i Ekstra Bladet
Hej alle sammen Ekstra Bladet har en lille artikel samt video om WheelMap i dag http://ekstrabladet.dk/kup/article1776581.ece - Men desværre nævnes det ikke at det er OpenStreetMap som grundkort samt at WheelMap får oplysninger om kørestolsegnet steder eller ej fra OSMs database (tag wheelchair=yes/no/limited læs mere på Wikien http://wiki.openstreetmap.org/wiki/Wheelchair) Du kan selv være med at at forbedre OSMs POIs for butikker, museer, etc ved at angive disse tags vedr. wheelchair. Wheelmap er nok et af de gode eksempler på, hvordan OSMs data kan bruges i andre sammenhænge. (jeg har skrevet lidt om Wheelmap for et år siden http://www.microformats.dk/2011/07/19/wheelmap-find-k%C3%B8restolstilg%C3%A6ngelige-steder/ ) Hvis historien dukker op andre steder i DK medier vil jeg prøve på at kontakte journalisterne, om de ikke godt kan nævne OpenStreetMap som den bagvedliggende database. Vh Søren Johannessen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
Hej Emil Tin jeg syns også jeres router er virkelig hurtig, jeg måtte forsøge med flere adresse kombinationer for at blive overbevist om at performance generelt er så høj, godt gået. da jeg testede en rute fra: Kærbøllinghusevej, Danmark til: Kvak Mølle Vej, Østengård lagde jeg dog mærke til at man bliver sendt på noget af en skovtur (jeg har cyklet der mange gange, og det er faktisk en rigtig flot rute man bliver ledt ud på, med rigtig mange højdemeter). Det er klart at man ikke må cykle på den hovedvej der ligger der hvor det ville være normalt at gå over vejen. Det er dog i praksis det som folk gør da man sådanset bare krydser vejen, kunne man evt tilføje noget logik der kiggede på den afstand man tilbagelægger på veje man ikke må køre på som cyklist? så kunne man jo fin tune denne afstand til at undgå de fleste af denne slags problemer. joris ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
S er den tilfjet. Jeg var lige ved at skrive til listen, da Claus kom mig i forkbet. Joris Kofman wrote: Hej claus kunne du evt tegne det ind, s jeg kan se hvordan du vil foresl det skal laves, s kan jeg jo gentage konstruktioenen andre steder, hvis jeg mder sdanne. joris ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
tak for det begge to, nu er jeg med på hvad i mener. ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
data i routeren vil bliver opdateret en gang om dagen, men det er ikke slået til endnu. så der kan godt gå lidt før i ser jeres tilføjelser have effekt. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk mailto:z...@tmf.kk.dk Fra: Uffe Kousgaard [mailto:u...@routeware.dk] Sendt: 15. juni 2012 12:31 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] Cykelruteplanlæggeren Så er den tilføjet. Jeg var lige ved at skrive til listen, da Claus kom mig i forkøbet. Joris Kofman wrote: Hej claus kunne du evt tegne det ind, så jeg kan se hvordan du vil foreslå det skal laves, så kan jeg jo gentage konstruktioenen andre steder, hvis jeg møder sådanne. joris ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
Hej, I praksis (IRL) er fodgngere tilladt p alle de cykelstier der er mappet i OSM, da vi kun mapper stier hvor der ikke er en vej (med evt. fortov) umiddelbart parallelt med. Se frdselsloven, kap 3, 10, stk 1: https://www.retsinformation.dk/Forms/R0710.aspx?id=139027#Kap3 S, hvis nogen skulle finde p at lave en ruteplanlgger for fodgngere, vil det vre en god id at inkludere cykelstier blandt de tilladte veje. Hilsen Uffe Claus Hindsgaul wrote: Hermed gjort. Bemrk i virgt, at highway=cycleway som udgangspunkt ikke tillader fodgngere; hvis fordgngere m frdes her, skal man tilfje srlige tags for dette (sehttp://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway). Da cykelstien ikke har et sdant tag, har jeg heller ikke tilladt fodgngere p forbindelsesvejen. Claus ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] stationer
godt tip! men på rejseplanen er der så vidt jeg kan se ingen funktion til at få en liste over alle stationer? på dsb labs kan man få en liste over stationer, men de har ingen koordinat eller adresse. e -Oprindelig meddelelse- Fra: Michael Hammel [mailto:m...@dcf.dk] Sendt: 14. juni 2012 14:00 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] stationer Hvorfor benytter du ikke rejseplanens geo-rest-service? Det er vel reelt overflødigt at duplere data med en ekstra node ovenpå bygningen, med mindre du vil markere stationernes forskellige indgange. Ellers kan du jo både søge på polygoner og noder. Mvh Michael Hammel Webmaster og webredaktør m...@dcf.dk Dansk Cyklistforbund Rømersgade 5 DK-1362 Copenhagen K Sent from myBike Den 14/06/2012 kl. 13.47 skrev Emil Tin z...@tmf.kk.dk: hej, jeg forsøger at lave et udtræk af stationer i region h, dvs. s-tog og metro. jeg bruger osmosis med --tag-filter funktionen. de fleste stationer er tagget med en node med railway=station. men kbh hovedbanegård har ingen node. i stedet er selve bygningen (en way) tagget med railway=station. andre har begge dele, fx hillerød station: http://www.openstreetmap.org/?lat=55.926881lon=12.310791zoom=18layers=M er det ok at tilføje en node, de steder hvor der er en bygning i forvejen, fx kbh's hovedbanegård? Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
interessant. men de fleste steder findes der jo en separat fodgængersti, og så man man vel ikke gå på cykelstier? fx nørrebroparken, den grønne sti på frederiksberg, bryggebroen, etc. http://www.openstreetmap.org/?lat=55.693067lon=12.543148zoom=18layers=M http://www.openstreetmap.org/?lat=55.682447lon=12.54207zoom=18layers=M Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk mailto:z...@tmf.kk.dk Fra: Uffe Kousgaard [mailto:u...@routeware.dk] Sendt: 15. juni 2012 13:42 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] Cykelruteplanlæggeren Hej, I praksis (IRL) er fodgængere tilladt på alle de cykelstier der er mappet i OSM, da vi kun mapper stier hvor der ikke er en vej (med evt. fortov) umiddelbart parallelt med. Se færdselsloven, kap 3, § 10, stk 1: https://www.retsinformation.dk/Forms/R0710.aspx?id=139027#Kap3 Så, hvis nogen skulle finde på at lave en ruteplanlægger for fodgængere, vil det være en god idé at inkludere cykelstier blandt de tilladte veje. Hilsen Uffe Claus Hindsgaul wrote: Hermed gjort. Bemærk i øvirgt, at highway=cycleway som udgangspunkt ikke tillader fodgængere; hvis fordgængere må færdes her, skal man tilføje særlige tags for dette (se http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway). Da cykelstien ikke har et sådant tag, har jeg heller ikke tilladt fodgængere på forbindelsesvejen. Claus ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Cykelruteplanlæggeren
Nej, men hvis der i OSM kun er mappet n (cykel)sti men virkeligheden er, at der er bde cykelsti og fodgngersti, s er det jo vigtigt at man tillader fodgngere p cykelstier. Langt det meste her i omrdet er netop mappet som cykelstier, underforstet at s m fodgngere ogs anvende dem. Uanset om der er seperate forlb eller kun t flles. Cykelstier med decideret forbud mod fodgngere og uden en parallel fodgngersti er vel trods alt et ret sjldent fnomen? Mske disse nye supercykelstier er udformet sledes? Hilsen Uffe Kousgaard PS: Jeg kender ikke de nedenfor omtalte stier til at kunne kommentere p dem. Emil Tin wrote: interessant. men de fleste steder findes der jo en separat fodgngersti, og s man man vel ikke g p cykelstier? fx nrrebroparken, den grnne sti p frederiksberg, bryggebroen, etc. http://www.openstreetmap.org/?lat=55.693067lon=12.543148zoom=18layers=M http://www.openstreetmap.org/?lat=55.682447lon=12.54207zoom=18layers=M Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KBENHAVNS KOMMUNE Teknik- og Miljforvaltningen Center for Trafik Islands Brygge 37 Vr. 118 Postboks 450 2300 Kbenhavn S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk Fra: Uffe Kousgaard [mailto:u...@routeware.dk] Sendt: 15. juni 2012 13:42 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] Cykelruteplanlggeren Hej, I praksis (IRL) er fodgngere tilladt p alle de cykelstier der er mappet i OSM, da vi kun mapper stier hvor der ikke er en vej (med evt. fortov) umiddelbart parallelt med. Se frdselsloven, kap 3, 10, stk 1: https://www.retsinformation.dk/Forms/R0710.aspx?id=139027#Kap3 S, hvis nogen skulle finde p at lave en ruteplanlgger for fodgngere, vil det vre en god id at inkludere cykelstier blandt de tilladte veje. Hilsen Uffe Claus Hindsgaul wrote: Hermed gjort. Bemrk i virgt, at highway=cycleway som udgangspunkt ikke tillader fodgngere; hvis fordgngere m frdes her, skal man tilfje srlige tags for dette (sehttp://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway). Da cykelstien ikke har et sdant tag, har jeg heller ikke tilladt fodgngere p forbindelsesvejen. Claus ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] kommunegrænser og fysiske objekter
Hej Joris Du kan se mere om kommunegrænserne på wiki: http://wiki.openstreetmap.org/wiki/Denmark/Da:Administrative_boundaries hvis du ikke lige var faldt over denne side. Det er vist mere eller mindre udelukkende rasher og rasmusv der har tegnet kommunegrænserne. Jeg ved godt det ikke rigtigt svarer på dit spørgsmål, men det kan være ovennævnte kan uddybe. 15. jun. 2012 09.25 skrev Joris Kofman joriskof...@gmail.com: Hej folkens først og fremmest super godt arbejde, til ham/hun/dem der har tegnet alle kommune grænserne ind, det må have været et kæmpe arbejde. jeg har dog et enkelt spørgsmål (delt op i to spørgsmål). Er kommune grænserne defineret ud fra geografiske objekter? på linket ses en å der ligger næsten sammenfaldende med kommunegrænsen, men følger grænsen i virkeligheden åen? http://www.openstreetmap.org/?lat=55.87008lon=9.71424zoom=15layers=M hvis kommunegrænsen følger åen, så kunne man måske med fordel sammenkøre kommunegrænsen med de fysiske objekter, vha nogen multi polygoner? joris ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] kommunegrænser og fysiske objekter
On 16-06-2012 00:03, Nick Østergaard wrote: Hej Joris Du kan se mere om kommunegrænserne på wiki: http://wiki.openstreetmap.org/wiki/Denmark/Da:Administrative_boundaries hvis du ikke lige var faldt over denne side. Jeg har skrevet lidt om de tanker rasmusv og jeg har gjort os i den retning. Jeg har dog ikke lige snakket med Rasmus om den præcise ordlyd af det jeg skrev, så læg ikke alt for meget i det (endnu i hvert fald). -- Jonas Häggqvist rasher(at)rasher(dot)dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-es] [Catastro] Elemtex
On Jueves, 14 de junio de 2012 22:46:25 David Marín Carreño escribió: Yo intentaría invertir trabajo y esfuerzo en importar de golpe todo lo que se pueda importar de catastro, no sólo elemtex. A mi lo idea del servidor intermedio me parece brutal y estoy con David en que, de hacerse así, es preferible importar todo e ir corrigiendo poco a poco. De esta manera los revisores importarían todo de una sola vez. Incluyendo lo que, bajo mi punto de vista, es la información más útil que podemos importar de catastro por su actual escasez en España: los nombres de calles junto con los números de policía. ¿Alguien ha escrito a la lista de talk por el tema de edificios por relaciones o por polígonos con ways superpuestos? No y nosotros andamos ahora bastante petados de trabajo. Si alguien se anima estaría bastante bien a ver si a finales de julio podemos hacer algo al respecto (aunque lo dudo mucho). -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Hola a todos. Se que he estado una buena temporada un poco ausente liado con otros temas pero precisamente esa desconexión es la que me ha hecho darle vueltas al tema de cat2osm y la pelea de los imports. El conflicto está principalmente en la *forma de dividir las geometrías*que sean adyacentes a otra y que en un principio podrían ser representadas por un único way cerrado, en una relación conteniendo los distintos ways que la componen con intención de reutilizar ways. Un solo resultado de cat2osm para una población un poco grande tiene mas relations que toda la base de datos de OSM. (Geometrías representadas por un único way cerrado y que por consiguiente se solaparán los bordes) http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png (Geometrías divididas en ways independientes lo más grande posibles para ser reutilizados por otras geometrías) http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png En un principio pensé que esta segunda opción era mejor ya que, aunque requiere más cálculos para crear la geometría, la reutilización de ways *optimizaría los archivos .osm*. El caso es que tras muchas pruebas no he visto reducción del tamaño de los archivos sino que además *han aumentado*. Me dio por ver cómo funciona Mapnik en nuestro servidor de pruebas que montamos y este genera varias tablas entre las que podríamos crear la siguiente división: *Tablas por si alguien me pide el archivo importado* y *Tablas para usar*. En las tablas del archivo importado (que son 3, una de nodos, otra de ways y otra de relations) guarda tal cual lo que ha leído del archivo .osm que le hemos pasado y no vuelve a tocarlo para nada. Intuyo que al pedir información .osm al API devolverá de esta tablas. En cambio en las tablas para usar, lee el archivo y construye las *geometrías con bordes solapados que tanto esfuerzo hemos puesto en desmontar*. Y es que si lo pensamos bien, para poder usar todas las ventajas de los SIG las geometrías deben estar así en polígonos cerrados para poder consultar si un punto está dentro, polígonos que intersequen... De hecho en el Google Summer of Code que estoy trabajando (para la visualización de tiles vectoriales en Marble), finalmente vamos a tener que crear nuestro propio servidor de tiles de la información de OSM que envíe las geometrías ya construidas ya que el Google Summer of Code paralelo de OSM para crear un servidor de tiles vectoriales, por el momento va a seguir el formato OSM (nodes, ways y relations) y esto *requiere muchísimo mas procesado*. (Hay un ejemplo de los dos formatos en http://blogs.deusto.es/gsoc-deustotech/the-black-planet/) *Cómo pequeño ejemplo, imaginemos unas fichas personales, de las cuales tengamos que conocer la edad de una serie de personas, en las que se indican la fecha de nacimiento y la edad. Tan solo con la fecha de nacimiento, conociendo la fecha actual podríamos hacer la resta y conocer su edad por lo que indicar explícitamente la edad es innecesario. Pero si hay que calcular las edades muchas veces, el incluir la edad aunque sea redundante es más óptimo ya que evitas hacer restas una y otra vez. Esto llevado a algo mucho mas voluminoso es lo que pasa teniendo que saltar de relations a ways, de ways a nodes, etc para ir creando la geometría en lugar de darla ya hecha con un way cerrado.* Mirando en la wiki qué representa exactamente una relación, se dice lo siguiente: *A relation is one of the core data elements that consists of one or more tags and also an ordered list of one or more nodes and/or ways as members which is used to define logical or geographic relationships between other elements.* Si que es cierto que indica que se pueden agrupar geometrías por cuestiones geográficas, pero creo que la palabra clave para decidir si hace falta una relation es *tags*. Cuando es necesario indicar que las dos geometrías comparten cierta lógica, cierto significado, en definitiva tags es cuando opino que si que hay que agruparlas. No se si la mención que hace a cuestiones geográficas sería la de reutilización de ways pero aún siendo eso, no veo optimización en ella. El problema ahora está en definir hasta qué punto relacionar porque si seguimos al pie de la letra el tema de agrupar según *compartición de tags*, podríamos acabar con unas super-relaciones.* *Construcciones Parcelas Manzanas Poblaciones Provincias... En definitiva, ¿*de qué nos sirve separar*, complicar el programa, complicar el trabajo a la comunidad que tenga que editar el resultado en JOSM, complicar el procesado de los datos a la gente que luego quiera trabajar con ellos o importarlos a algún programa suyo, dificultar la lectura de un .osm a pelo si fuese necesario, etc *si de verdad no hay una optimización clara con ello*? A la hora de crear una estructura de almacenamiento de información muchas veces en la carrera (Ingeniería informática) nos han dicho que hay situaciones en las que hay que
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Los edificios tienen agujeros. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Yo estaba por generar relaciones porque a mi me dijeron en su día que *así es como debe hacerse*. Por eso creo que tenemos que hablar con los que dijeron que *así es como debe hacerse* para contarles todas estas cosicas. Y tomar la decisión con ellos. Yo también sería de la opinión que los polígonos formados por líneas sin etiquetar, para evitar segmentos superpuestos, es hacer un pan con unas tortas: para evitar algo que podría ser un problema, genero problemas mucho mayores... Y dejaría sólo el uso de multipolígonos para el caso de edificios con agujeros, y cosas así. Vamos, que el tema sería que los mayores decidan y definan si en OSM el uso de ways con segmentos superpuestos es bueno, o no lo es. El 15 de junio de 2012 10:50, Ander Pijoan ander.pij...@deusto.esescribió: Hola a todos. Se que he estado una buena temporada un poco ausente liado con otros temas pero precisamente esa desconexión es la que me ha hecho darle vueltas al tema de cat2osm y la pelea de los imports. El conflicto está principalmente en la *forma de dividir las geometrías*que sean adyacentes a otra y que en un principio podrían ser representadas por un único way cerrado, en una relación conteniendo los distintos ways que la componen con intención de reutilizar ways. Un solo resultado de cat2osm para una población un poco grande tiene mas relations que toda la base de datos de OSM. (Geometrías representadas por un único way cerrado y que por consiguiente se solaparán los bordes) http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png (Geometrías divididas en ways independientes lo más grande posibles para ser reutilizados por otras geometrías) http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png En un principio pensé que esta segunda opción era mejor ya que, aunque requiere más cálculos para crear la geometría, la reutilización de ways *optimizaría los archivos .osm*. El caso es que tras muchas pruebas no he visto reducción del tamaño de los archivos sino que además *han aumentado*. Me dio por ver cómo funciona Mapnik en nuestro servidor de pruebas que montamos y este genera varias tablas entre las que podríamos crear la siguiente división: *Tablas por si alguien me pide el archivo importado* y *Tablas para usar*. En las tablas del archivo importado (que son 3, una de nodos, otra de ways y otra de relations) guarda tal cual lo que ha leído del archivo .osm que le hemos pasado y no vuelve a tocarlo para nada. Intuyo que al pedir información .osm al API devolverá de esta tablas. En cambio en las tablas para usar, lee el archivo y construye las *geometrías con bordes solapados que tanto esfuerzo hemos puesto en desmontar*. Y es que si lo pensamos bien, para poder usar todas las ventajas de los SIG las geometrías deben estar así en polígonos cerrados para poder consultar si un punto está dentro, polígonos que intersequen... De hecho en el Google Summer of Code que estoy trabajando (para la visualización de tiles vectoriales en Marble), finalmente vamos a tener que crear nuestro propio servidor de tiles de la información de OSM que envíe las geometrías ya construidas ya que el Google Summer of Code paralelo de OSM para crear un servidor de tiles vectoriales, por el momento va a seguir el formato OSM (nodes, ways y relations) y esto *requiere muchísimo mas procesado*. (Hay un ejemplo de los dos formatos en http://blogs.deusto.es/gsoc-deustotech/the-black-planet/) *Cómo pequeño ejemplo, imaginemos unas fichas personales, de las cuales tengamos que conocer la edad de una serie de personas, en las que se indican la fecha de nacimiento y la edad. Tan solo con la fecha de nacimiento, conociendo la fecha actual podríamos hacer la resta y conocer su edad por lo que indicar explícitamente la edad es innecesario. Pero si hay que calcular las edades muchas veces, el incluir la edad aunque sea redundante es más óptimo ya que evitas hacer restas una y otra vez. Esto llevado a algo mucho mas voluminoso es lo que pasa teniendo que saltar de relations a ways, de ways a nodes, etc para ir creando la geometría en lugar de darla ya hecha con un way cerrado.* Mirando en la wiki qué representa exactamente una relación, se dice lo siguiente: *A relation is one of the core data elements that consists of one or more tags and also an ordered list of one or more nodes and/or ways as members which is used to define logical or geographic relationships between other elements.* Si que es cierto que indica que se pueden agrupar geometrías por cuestiones geográficas, pero creo que la palabra clave para decidir si hace falta una relation es *tags*. Cuando es necesario indicar que las dos geometrías comparten cierta lógica, cierto significado, en definitiva tags es cuando opino que si que hay que agruparlas. No se si la mención que hace a cuestiones geográficas sería la de reutilización de ways pero aún
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 10:29, Jaime Crespo jy...@jynus.com escribió: Los edificios tienen agujeros. -- Jaime Crespo Eso entra dentro del caso las etiquetas son las mismas que comenta Ander. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 11:54, Javier Sánchez javiers...@gmail.com escribió: El día 15 de junio de 2012 10:29, Jaime Crespo jy...@jynus.com escribió: Los edificios tienen agujeros. -- Jaime Crespo Eso entra dentro del caso las etiquetas son las mismas que comenta Ander. Por lo tanto requiere relaciones. No existe la primitiva polígono en OSM. Al menos en la API 0.6. Se habló en su día de una posible adición para la API 0.7... @Ander: no confundas un modelo pensado para pintar, como Mapnik o tu rendering de vectores, donde las relaciones sobran, con otros usos de OSM. Normalización/desnormalización de bases de datos. No obstante, acepto la discusión. Los alemanes están teniendo discusiones acaloradas sobre el tema: http://lists.openstreetmap.org/pipermail/tagging/2012-June/010523.html Lo que no tiene discusión alguna es utilizar las relaciones como categorías: las categorías sin ningún tipo de orden ni rol especial se realizan mediante etiquetas normales. No se agrupan cosas mediante relaciones. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 09:50, Ander Pijoan ander.pij...@deusto.es escribió: En definitiva, ¿de qué nos sirve separar, complicar el programa, complicar el trabajo a la comunidad que tenga que editar el resultado en JOSM, complicar el procesado de los datos a la gente que luego quiera trabajar con ellos o importarlos a algún programa suyo, dificultar la lectura de un .osm a pelo si fuese necesario, etc si de verdad no hay una optimización clara con ello? Pues macho, si en [imports] nos dicen que creen que estamos usando demasiadas relaciones y después de pensarlo tanto tampoco está claro que nos traiga ventajas o de que sea lo más correcto, yo no le daría más vueltas. Dejar las relaciones sólo para etiquetas comunes, geometrías con agujeros, geometrías muy grandes y complejas (tipo fronteras)... Pero para los edificios y parcelas adyacentes polígonos superpuestos. Así es como lo han hecho en muchos sitios (Francia, por ejemplo). De hecho el dejar subparcelas como polígonos independientes puede facilitar el proceso de agrupar por ejemplo subparcelas con el mismo cultivo y dejar únicamente la geometría de su contorno para simplificar aún mas el resultado (si alguien desease consultar las divisiones administrativas entre subparcelas debería ir a Catastro, creo que no es la función de OSM ser Catastro 2). http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/06/Subparcels.png Agrupar subparcelas si están formadas por dos relaciones me parece muy fácil. Eliminar de una relación las vías que pertenezcan a ambas y eliminar la otra relación. Con polígonos superpuesto sería hacer lo mismo a nivel de nodos, siempre que no estén duplicados. Vamos, que en ambos casos me parece comparable la dificultar. Respecto a lo de Catastro 2 +1. Si la división en distintas parcelas se refiere solo a una cuestión administrativa fusionarlas. Se que retrasaría la importación y habría que volver a definir cómo hacer muchas cosas pero bueno, esta es mi opinión y por supuesto está abierta a debate. Yo voto que si, que hay que hacerlo. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 12:15, Javier Sánchez javiers...@gmail.com escribió: El día 15 de junio de 2012 09:50, Ander Pijoan ander.pij...@deusto.es escribió: En definitiva, ¿de qué nos sirve separar, complicar el programa, complicar el trabajo a la comunidad que tenga que editar el resultado en JOSM, complicar el procesado de los datos a la gente que luego quiera trabajar con ellos o importarlos a algún programa suyo, dificultar la lectura de un .osm a pelo si fuese necesario, etc si de verdad no hay una optimización clara con ello? Pues macho, si en [imports] nos dicen que creen que estamos usando demasiadas relaciones y después de pensarlo tanto tampoco está claro que nos traiga ventajas o de que sea lo más correcto, yo no le daría Atención, editar con geometrías superpuestas no es precisamente fácil tampoco. ¿Lo habéis probado alguno? Dependiendo del editor te puedes volver loco para pulsar en el área que quieres. Lo digo para que penséis también en las desventajas. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Claro que las relaciones son esenciales y sin ellas no hay forma de representar cosas como los agujeros de edificios. Pero creo que se crearon para eso, para dar solución a agrupaciones lógicas que no había otra forma de agrupar y no para simplificar geometrías. Los ways son los que (en mi opinión) deben recrear los polígonos, áreas, lineas, etc. (de hecho en la wiki indica que para eso son) y luego en caso de necesitar especificar un rol que es totalmente necesario especificar que cumple ese way, indicarlo mediante relations. Podría plantear la pregunta al revés, ¿qué mejora la reutilización de ways? Saludos. El 15 de junio de 2012 12:15, Javier Sánchez javiers...@gmail.comescribió: El día 15 de junio de 2012 09:50, Ander Pijoan ander.pij...@deusto.es escribió: En definitiva, ¿de qué nos sirve separar, complicar el programa, complicar el trabajo a la comunidad que tenga que editar el resultado en JOSM, complicar el procesado de los datos a la gente que luego quiera trabajar con ellos o importarlos a algún programa suyo, dificultar la lectura de un .osm a pelo si fuese necesario, etc si de verdad no hay una optimización clara con ello? Pues macho, si en [imports] nos dicen que creen que estamos usando demasiadas relaciones y después de pensarlo tanto tampoco está claro que nos traiga ventajas o de que sea lo más correcto, yo no le daría más vueltas. Dejar las relaciones sólo para etiquetas comunes, geometrías con agujeros, geometrías muy grandes y complejas (tipo fronteras)... Pero para los edificios y parcelas adyacentes polígonos superpuestos. Así es como lo han hecho en muchos sitios (Francia, por ejemplo). De hecho el dejar subparcelas como polígonos independientes puede facilitar el proceso de agrupar por ejemplo subparcelas con el mismo cultivo y dejar únicamente la geometría de su contorno para simplificar aún mas el resultado (si alguien desease consultar las divisiones administrativas entre subparcelas debería ir a Catastro, creo que no es la función de OSM ser Catastro 2). http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/06/Subparcels.png Agrupar subparcelas si están formadas por dos relaciones me parece muy fácil. Eliminar de una relación las vías que pertenezcan a ambas y eliminar la otra relación. Con polígonos superpuesto sería hacer lo mismo a nivel de nodos, siempre que no estén duplicados. Vamos, que en ambos casos me parece comparable la dificultar. Respecto a lo de Catastro 2 +1. Si la división en distintas parcelas se refiere solo a una cuestión administrativa fusionarlas. Se que retrasaría la importación y habría que volver a definir cómo hacer muchas cosas pero bueno, esta es mi opinión y por supuesto está abierta a debate. Yo voto que si, que hay que hacerlo. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Yo estaba por generar relaciones porque a mi me dijeron en su día que *así es como debe hacerse*. Por eso creo que tenemos que hablar con los que dijeron que *así es como debe hacerse* para contarles todas estas cosicas. Y tomar la decisión con ellos. http://wiki.openstreetmap.org/wiki/Key:building Nodes: 432.548 Ways: 59.106.532 Relations: 58.763 Independientemente de que deba o no hacerse así, desde luego NO se hace así. Siendo el 99.2% de los elementos tagueados, ways, lo que está claro es que la tendencia es otra. De todas formas, ya nos han dicho que no vamos a importar con relaciones mientras los recursos (hardware y editor online) no lo soporten. ¿Porqué no importamos con ways, aunque a algunos nos nos acabe de convencer, y guardamos los datos y el software a la espera de que la forma de mapear edificios cambie? Creo que es preferible tener los edificios mapeados con ways superpuestos que no tenerlos. @Javier Sánchez: El problema es que prácticamente todos los edificios de españa serían entonces relaciones. Aunque superpongas las caras adyacentes entre edificios, el problema es que en este país hay una barbaridad de edificios con patios de luces, plazas interiores, etc. Siguen siendo tantas relaciones que al terminar de importar españa, ese 58.763 se haría demasiado grande. Vamos, que creo que aún con ese cambio nos echarían atrás la importación. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 12:35, Ander Pijoan ander.pij...@deusto.es escribió: Podría plantear la pregunta al revés, ¿qué mejora la reutilización de ways? Evita esto: http://i.imgur.com/YDXRi.png -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Si, por supuesto que es difícil. Pero a mi por lo menos me es más fácil moverme en dos niveles (nodos y vías) que además es muy visual ver y editarlo que tener que aplicar un tercer nivel (relations) que a veces no está muy claro a simple vista si lo hemos editado bien o no. Y supongo que si vamos a gente todavía más inexperta o poco habitual a trabajar con ello se harán bastante lio, con eso de que cambias algo y de repente empiezan a salirte mensajes de que otras relaciones pueden verse afectadas. Si de la primera forma borras un nodo, de la misma observas el destrozo que has hecho, en cambio con relaciones los problemas no están tan a la vista. Esto son gustos personales, pero por eso pregunto qué mejoras tiene la reutilización de vías. El 15 de junio de 2012 12:34, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 12:15, Javier Sánchez javiers...@gmail.com escribió: El día 15 de junio de 2012 09:50, Ander Pijoan ander.pij...@deusto.es escribió: En definitiva, ¿de qué nos sirve separar, complicar el programa, complicar el trabajo a la comunidad que tenga que editar el resultado en JOSM, complicar el procesado de los datos a la gente que luego quiera trabajar con ellos o importarlos a algún programa suyo, dificultar la lectura de un .osm a pelo si fuese necesario, etc si de verdad no hay una optimización clara con ello? Pues macho, si en [imports] nos dicen que creen que estamos usando demasiadas relaciones y después de pensarlo tanto tampoco está claro que nos traiga ventajas o de que sea lo más correcto, yo no le daría Atención, editar con geometrías superpuestas no es precisamente fácil tampoco. ¿Lo habéis probado alguno? Dependiendo del editor te puedes volver loco para pulsar en el área que quieres. Lo digo para que penséis también en las desventajas. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 12:41, Ander Pijoan ander.pij...@deusto.es escribió: Si, por supuesto que es difícil. Pero a mi por lo menos me es más fácil moverme en dos niveles (nodos y vías) que además es muy visual ver y editarlo que tener que aplicar un tercer nivel (relations) que a veces no está muy claro a simple vista si lo hemos editado bien o no. Pues nada, cuando edites una línea de bus, borra ways y paradas y olvídate de las dichosas relaciones que te avisa que rompes. A ver: openstreetmap es complejo si quieres aprender todas sus características. Punto. No hay posible solución para eso. Otra cosa es que se plantee no permitir a los usuarios nuevos hacer las cosas de manera sencilla. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [Catastro] Elemtex
Por Zaragoza estamos tratando de preparar ese servidor intermedio con algo de hardware que nos han donado (a la asociación de software libre de la universidad[0]) pero estamos teniendo algún contratiempo (básicamente, que no hay pelas para hacer alguna que otra reparación y ampliación). [0]: http://pulsar.unizar.es/rack 2012/6/15 Cruz Enrique Borges cruz.bor...@deusto.es: On Jueves, 14 de junio de 2012 22:46:25 David Marín Carreño escribió: Yo intentaría invertir trabajo y esfuerzo en importar de golpe todo lo que se pueda importar de catastro, no sólo elemtex. A mi lo idea del servidor intermedio me parece brutal y estoy con David en que, de hacerse así, es preferible importar todo e ir corrigiendo poco a poco. De esta manera los revisores importarían todo de una sola vez. Incluyendo lo que, bajo mi punto de vista, es la información más útil que podemos importar de catastro por su actual escasez en España: los nombres de calles junto con los números de policía. ¿Alguien ha escrito a la lista de talk por el tema de edificios por relaciones o por polígonos con ways superpuestos? No y nosotros andamos ahora bastante petados de trabajo. Si alguien se anima estaría bastante bien a ver si a finales de julio podemos hacer algo al respecto (aunque lo dudo mucho). -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Metido a mano por un usuario si que evitaría eso, pero para ello el usuario tiene que ser consciente de la forma en la que hay que reutilizar las vías. SI ya existiese uno de esos dos polígonos que muestras, el usuario tendría que desmontarla en una relation para reutilizar el way y luego crear la otra relation. En caso de que empezase desde cero tendría que conocer también cómo ir creando las vías separadas para reutilizarlas. Si ya teniendo solo que crear un polígono encima de una imagen de mapa aparecen fallos como estos, si usuarios inexpertos tienen que aprender la forma de reutilizar vías ¿no crees que habría muchas mas pifias por ahí sueltas? El 15 de junio de 2012 12:40, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 12:35, Ander Pijoan ander.pij...@deusto.es escribió: Podría plantear la pregunta al revés, ¿qué mejora la reutilización de ways? Evita esto: http://i.imgur.com/YDXRi.png -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
No pero no me refiero a eso Jynus. Me refiero a que utilizar relations para optimizar no me parece que sea correcto (ni que optimice). Las relations son para agrupar elementos con un mismo significado o relacionados, valga la redundancia, y eso lo estabamos haciendo bien. El 15 de junio de 2012 12:45, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 12:41, Ander Pijoan ander.pij...@deusto.es escribió: Si, por supuesto que es difícil. Pero a mi por lo menos me es más fácil moverme en dos niveles (nodos y vías) que además es muy visual ver y editarlo que tener que aplicar un tercer nivel (relations) que a veces no está muy claro a simple vista si lo hemos editado bien o no. Pues nada, cuando edites una línea de bus, borra ways y paradas y olvídate de las dichosas relaciones que te avisa que rompes. A ver: openstreetmap es complejo si quieres aprender todas sus características. Punto. No hay posible solución para eso. Otra cosa es que se plantee no permitir a los usuarios nuevos hacer las cosas de manera sencilla. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 12:48, Ander Pijoan ander.pij...@deusto.es escribió: No pero no me refiero a eso Jynus. Me refiero a que utilizar relations para optimizar no me parece que sea correcto (ni que optimice). Las relations son para agrupar elementos con un mismo significado o relacionados, valga la redundancia, y eso lo estabamos haciendo bien. Pues tienes una idea equivocadísima de las relaciones. ¿Juntamos en una relación todos los amenity=bar de una ciudad? ¿campus de Deusto? Obviamente no, usamos tags. Y qué obsesionados estáis todos con optimizar. ¿Acaso alguien ha hablado realmente con los sysadmins -y no con los de imports, que sus criterios son otros, de mantenimiento de los datos- sobre cuánto afecta eso a sus servidores? -- Respecto a la complejidad: No quiero usuarios vagos. Precisamente el hecho de que cosas complejas de por sí son complejas evita todos los vandalismos en OSM (si no sabes editar una frontera entre dos países, no lo hagas). Ahora bien, todo lo que sea sencillo, que sea lo más sencillo posible. La forma de los edificios se puede cambiar sin problemas por cualquier usuario (siguen siendo ways), y es probablemente más fácil con relaciones, porque no tiene que acertar cuál es el polígono correcto. OSM es un proyecto colaborativo, por lo que hay que anteponer la edición fácil a la optimización de los servidores. (Si tu software no es capaz de entender relaciones no es problema del modelo de datos de osm, sino de que tendrás que hacer una conversión antes, como hace mapnik). Y si los editores no lo hacen fácil, se modifican los editores para hacerlo fácil, no la forma de editar de la gente. Dicho esto, yo aquí hace un tiempo propuse subir masas (como ways, sin agujeros) a pelo y portales (como nodos) - mira qué fáciles de editar. Y ya estaría satisfecho. Eso sí, los de imports te dirán que no de nuevo (lo último de la lista es que deberían borrarse todos los edificios de OSM porque no tienen valor). -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Creo que no nos estamos entendiendo. Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm sacase los datos tal y como están en Alemania o Francia? El 15 de junio de 2012 13:06, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 12:48, Ander Pijoan ander.pij...@deusto.es escribió: No pero no me refiero a eso Jynus. Me refiero a que utilizar relations para optimizar no me parece que sea correcto (ni que optimice). Las relations son para agrupar elementos con un mismo significado o relacionados, valga la redundancia, y eso lo estabamos haciendo bien. Pues tienes una idea equivocadísima de las relaciones. ¿Juntamos en una relación todos los amenity=bar de una ciudad? ¿campus de Deusto? Obviamente no, usamos tags. Y qué obsesionados estáis todos con optimizar. ¿Acaso alguien ha hablado realmente con los sysadmins -y no con los de imports, que sus criterios son otros, de mantenimiento de los datos- sobre cuánto afecta eso a sus servidores? -- Respecto a la complejidad: No quiero usuarios vagos. Precisamente el hecho de que cosas complejas de por sí son complejas evita todos los vandalismos en OSM (si no sabes editar una frontera entre dos países, no lo hagas). Ahora bien, todo lo que sea sencillo, que sea lo más sencillo posible. La forma de los edificios se puede cambiar sin problemas por cualquier usuario (siguen siendo ways), y es probablemente más fácil con relaciones, porque no tiene que acertar cuál es el polígono correcto. OSM es un proyecto colaborativo, por lo que hay que anteponer la edición fácil a la optimización de los servidores. (Si tu software no es capaz de entender relaciones no es problema del modelo de datos de osm, sino de que tendrás que hacer una conversión antes, como hace mapnik). Y si los editores no lo hacen fácil, se modifican los editores para hacerlo fácil, no la forma de editar de la gente. Dicho esto, yo aquí hace un tiempo propuse subir masas (como ways, sin agujeros) a pelo y portales (como nodos) - mira qué fáciles de editar. Y ya estaría satisfecho. Eso sí, los de imports te dirán que no de nuevo (lo último de la lista es que deberían borrarse todos los edificios de OSM porque no tienen valor). -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
La logica que siempre se a seguido o por lo menos en general para decir que no se usen relaciones es que es mas sencillo de editar, y algo menos aunque tambien se a dicho que es menos carga para los servidores. Lo de mas sencillo de editar como ya han comentado por aqui no es así. Ponte a editar en un sitio que se junten varios trazados y me lo cuentas. Proceso que sigo yo y creo que al final es el mas facil. Coger a ver que poligono sale si no es el que quieres agregarle un nodo y apartarlo. Ir al siguiente si pasa lo mismo otra vez hasta que llegas al que quieres. Cuando llegas ya lo modificas y borrar los nodos que has creado que sobran, si hay algún nodo mio suelto raro ya sabeis porque puede ser. jejeje. Lo de la carga a los servidores creo que si que da mas carga eso no lo discuto. Se da mucho por hecho por aqui que ningún tipo de relación maxima va a ser aceptada por la lista de imports, entonces me pregunto ¿porque se acepto la de Girona?. Si no me equivoco se paso por la lista de imports. Creo que habría que reducir el numero de relaciones y después ver que dicen. El día 15 de junio de 2012 13:13, Ander Pijoan ander.pij...@deusto.es escribió: Creo que no nos estamos entendiendo. Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm sacase los datos tal y como están en Alemania o Francia? El 15 de junio de 2012 13:06, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 12:48, Ander Pijoan ander.pij...@deusto.es escribió: No pero no me refiero a eso Jynus. Me refiero a que utilizar relations para optimizar no me parece que sea correcto (ni que optimice). Las relations son para agrupar elementos con un mismo significado o relacionados, valga la redundancia, y eso lo estabamos haciendo bien. Pues tienes una idea equivocadísima de las relaciones. ¿Juntamos en una relación todos los amenity=bar de una ciudad? ¿campus de Deusto? Obviamente no, usamos tags. Y qué obsesionados estáis todos con optimizar. ¿Acaso alguien ha hablado realmente con los sysadmins -y no con los de imports, que sus criterios son otros, de mantenimiento de los datos- sobre cuánto afecta eso a sus servidores? -- Respecto a la complejidad: No quiero usuarios vagos. Precisamente el hecho de que cosas complejas de por sí son complejas evita todos los vandalismos en OSM (si no sabes editar una frontera entre dos países, no lo hagas). Ahora bien, todo lo que sea sencillo, que sea lo más sencillo posible. La forma de los edificios se puede cambiar sin problemas por cualquier usuario (siguen siendo ways), y es probablemente más fácil con relaciones, porque no tiene que acertar cuál es el polígono correcto. OSM es un proyecto colaborativo, por lo que hay que anteponer la edición fácil a la optimización de los servidores. (Si tu software no es capaz de entender relaciones no es problema del modelo de datos de osm, sino de que tendrás que hacer una conversión antes, como hace mapnik). Y si los editores no lo hacen fácil, se modifican los editores para hacerlo fácil, no la forma de editar de la gente. Dicho esto, yo aquí hace un tiempo propuse subir masas (como ways, sin agujeros) a pelo y portales (como nodos) - mira qué fáciles de editar. Y ya estaría satisfecho. Eso sí, los de imports te dirán que no de nuevo (lo último de la lista es que deberían borrarse todos los edificios de OSM porque no tienen valor). -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Se da mucho por hecho por aqui que ningún tipo de relación maxima va a ser aceptada por la lista de imports, entonces me pregunto ¿porque se acepto la de Girona?. Si no me equivoco se paso por la lista de imports. Creo que habría que reducir el numero de relaciones y después ver que dicen. Me que fue porque no se importaban ni las parcelas ni las alturas de los edificios. Quitando estas cosas el número de relaciones es muy inferior. Además, nuestro ficheros acojonan mucho por el parcelario rústico. Yo creo que eliminando alturas y agrupando el parcelario rústico por tipos de cultivos/tags no habría problemas para que nos acepten el import. Ahora bien, perderíamos el 3D, lo cual ahora no es muy problemático, aunque a largo plazo si que lo sea (a ver quien es el guapo que se pone a editar los edificios a mano para ponerles las alturas... o los interiores como han propuesto en algunos sitios...). -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 13:13, Ander Pijoan ander.pij...@deusto.es escribió: Creo que no nos estamos entendiendo. Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm sacase los datos tal y como están en Alemania o Francia? En Alemania nada, porque son alemanes, y son muchos. En Francia nada, porque no preguntaron. Ídem en USA. (nadie tiene de borrar toda esa información). En España, como preguntamos, pues no podemos. Lo siento, pero estoy un poco quemado con imports. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Yo no digo eliminar las relaciones de cuajo del resultado allí donde hagan falta (edificios con agujeros, lineas de autobus con sus paradas, carreteras muy largas, trazados de ferrocarril...). Para eso son las relaciones. Lo que digo que creo que no hay que hacer y que no aporta ninguna ventaja es utilizar relaciones para reutilizar ways. ¿En qué parte de la wiki de OSM se indica que tenga que hacerse eso así? Lo de Girona no se lo que dirían en su día y, también hay que decirlo, tal y como están esas, construcciones están correctas, pero ¿qué beneficia el hacerlo así? ¿Puestos a pedir por qué yo no podría hacer que una población sea una relation grande, cuyos members son otras relations que son sus manzanas con role inner, esas manzanas a su vez compuestas de otras relations que son las parcelas... El esquema lo permite, pero llega un momento en el que no tiene sentido y no mejora nada. Lo normal en OSM http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png Lo que se propuso para cat2osm en un principio pero que ya no lo veo lógico. http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png Esta reutilización de geometrías para evitar bordes superpuestos vuelvo a repetir que no mejora nada. Para todo lo demás, las relaciones siguen siendo totalmente necesarias. El 15 de junio de 2012 13:48, Jorge Sanz Sanfructuoso sanc...@gmail.comescribió: La logica que siempre se a seguido o por lo menos en general para decir que no se usen relaciones es que es mas sencillo de editar, y algo menos aunque tambien se a dicho que es menos carga para los servidores. Lo de mas sencillo de editar como ya han comentado por aqui no es así. Ponte a editar en un sitio que se junten varios trazados y me lo cuentas. Proceso que sigo yo y creo que al final es el mas facil. Coger a ver que poligono sale si no es el que quieres agregarle un nodo y apartarlo. Ir al siguiente si pasa lo mismo otra vez hasta que llegas al que quieres. Cuando llegas ya lo modificas y borrar los nodos que has creado que sobran, si hay algún nodo mio suelto raro ya sabeis porque puede ser. jejeje. Lo de la carga a los servidores creo que si que da mas carga eso no lo discuto. Se da mucho por hecho por aqui que ningún tipo de relación maxima va a ser aceptada por la lista de imports, entonces me pregunto ¿porque se acepto la de Girona?. Si no me equivoco se paso por la lista de imports. Creo que habría que reducir el numero de relaciones y después ver que dicen. El día 15 de junio de 2012 13:13, Ander Pijoan ander.pij...@deusto.es escribió: Creo que no nos estamos entendiendo. Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm sacase los datos tal y como están en Alemania o Francia? El 15 de junio de 2012 13:06, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 12:48, Ander Pijoan ander.pij...@deusto.es escribió: No pero no me refiero a eso Jynus. Me refiero a que utilizar relations para optimizar no me parece que sea correcto (ni que optimice). Las relations son para agrupar elementos con un mismo significado o relacionados, valga la redundancia, y eso lo estabamos haciendo bien. Pues tienes una idea equivocadísima de las relaciones. ¿Juntamos en una relación todos los amenity=bar de una ciudad? ¿campus de Deusto? Obviamente no, usamos tags. Y qué obsesionados estáis todos con optimizar. ¿Acaso alguien ha hablado realmente con los sysadmins -y no con los de imports, que sus criterios son otros, de mantenimiento de los datos- sobre cuánto afecta eso a sus servidores? -- Respecto a la complejidad: No quiero usuarios vagos. Precisamente el hecho de que cosas complejas de por sí son complejas evita todos los vandalismos en OSM (si no sabes editar una frontera entre dos países, no lo hagas). Ahora bien, todo lo que sea sencillo, que sea lo más sencillo posible. La forma de los edificios se puede cambiar sin problemas por cualquier usuario (siguen siendo ways), y es probablemente más fácil con relaciones, porque no tiene que acertar cuál es el polígono correcto. OSM es un proyecto colaborativo, por lo que hay que anteponer la edición fácil a la optimización de los servidores. (Si tu software no es capaz de entender relaciones no es problema del modelo de datos de osm, sino de que tendrás que hacer una conversión antes, como hace mapnik). Y si los editores no lo hacen fácil, se modifican los editores para hacerlo fácil, no la forma de editar de la gente. Dicho esto, yo aquí hace un tiempo propuse subir masas (como ways, sin agujeros) a pelo y portales (como nodos) - mira qué fáciles de editar. Y ya estaría satisfecho. Eso sí, los de imports te dirán que no de nuevo (lo último de la lista es que deberían borrarse todos los edificios de OSM porque no tienen valor). -- Jaime Crespo
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 13:59, Cruz Enrique Borges cruz.bor...@deusto.es escribió: Se da mucho por hecho por aqui que ningún tipo de relación maxima va a ser aceptada por la lista de imports, entonces me pregunto ¿porque se acepto la de Girona?. Si no me equivoco se paso por la lista de imports. Creo que habría que reducir el numero de relaciones y después ver que dicen. Es que cuando el State of The Map todavía había cordura en las listas de OSM (internacional, me refiero). -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Si, ya veo. ¿Pero sería erróneo ese resultado? El 15 de junio de 2012 14:04, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 13:13, Ander Pijoan ander.pij...@deusto.es escribió: Creo que no nos estamos entendiendo. Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm sacase los datos tal y como están en Alemania o Francia? En Alemania nada, porque son alemanes, y son muchos. En Francia nada, porque no preguntaron. Ídem en USA. (nadie tiene de borrar toda esa información). En España, como preguntamos, pues no podemos. Lo siento, pero estoy un poco quemado con imports. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: ander.pij...@deusto.es Móvil: +34 664471228 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 14:06, Ander Pijoan ander.pij...@deusto.es escribió: Si, ya veo. ¿Pero sería erróneo ese resultado? Para mí, ninguno de los dos es erróneo. Pero da igual, que a día de hoy no nos van a dejar importar de ninguna de las dos formas. Eso sí, si haces lo mismo a mano, sí. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Para mi tampoco es erroneo ninguno de los 2 resultados pero si veo mas correcto las relaciones. El JOSM si que te dice oye mira que esto de que 2 polígonos se solapen puede que sea un error, compruebalo. xD. Tampoco digo que por esto se tenga que hacer de una manera u otra ya que JOSM da muchos errores falsos. El día 15 de junio de 2012 14:09, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 14:06, Ander Pijoan ander.pij...@deusto.es escribió: Si, ya veo. ¿Pero sería erróneo ese resultado? Para mí, ninguno de los dos es erróneo. Pero da igual, que a día de hoy no nos van a dejar importar de ninguna de las dos formas. Eso sí, si haces lo mismo a mano, sí. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El día 15 de junio de 2012 13:04, Ander Pijoan ander.pij...@deusto.es escribió: Yo no digo eliminar las relaciones de cuajo del resultado allí donde hagan falta (edificios con agujeros, lineas de autobus con sus paradas, carreteras muy largas, trazados de ferrocarril...). Para eso son las relaciones. Lo que digo que creo que no hay que hacer y que no aporta ninguna ventaja es utilizar relaciones para reutilizar ways. ¿En qué parte de la wiki de OSM se indica que tenga que hacerse eso así? Lo de Girona no se lo que dirían en su día y, también hay que decirlo, tal y como están esas, construcciones están correctas, pero ¿qué beneficia el hacerlo así? ¿Puestos a pedir por qué yo no podría hacer que una población sea una relation grande, cuyos members son otras relations que son sus manzanas con role inner, esas manzanas a su vez compuestas de otras relations que son las parcelas... El esquema lo permite, pero llega un momento en el que no tiene sentido y no mejora nada. Lo normal en OSM http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png Lo que se propuso para cat2osm en un principio pero que ya no lo veo lógico. http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png Esta reutilización de geometrías para evitar bordes superpuestos vuelvo a repetir que no mejora nada. Para todo lo demás, las relaciones siguen siendo totalmente necesarias. Hay que buscar un término medio. Emplear vías superpuestas en unos casos y relaciones en otros según nos interese, y fusionar vías adyacentes con los mismos usos en los casos en que está claro como rústico. Ahora bien, veo dos formas de hacerlo. A) Reescribir todo el código para que genere vías superpuestas excepto relaciones en algunos casos. B) Dejar el código más o menos como está, generando relaciones para todo y pasar un proceso posterior que simplifique relaciones y sustituya por vías superpuestas en algunos casos. Supongo que B da menos trabajo pero tendrá más coste en tiempo de proceso. Javier. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
El 15/06/2012 14:09, Jaime Crespo jy...@jynus.com escribió: El día 15 de junio de 2012 14:06, Ander Pijoan ander.pij...@deusto.es escribió: Si, ya veo. ¿Pero sería erróneo ese resultado? Para mí, ninguno de los dos es erróneo. Pero da igual, que a día de hoy no nos van a dejar importar de ninguna de las dos formas. Eso sí, si haces lo mismo a mano, sí. Sigo defendiendo que lo vamos a hacer a mano. Por cierto... Una duda que me acaba de surgir... ¿Qué autoridad tiene imports sobre la comunidad de OSM España sobre lo que vamos a hacer o no en nuestro mapa? -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [Catastro] Elemtex
Hola El día 15 de junio de 2012 08:22, Cruz Enrique Borges cruz.bor...@deusto.es escribió: A mi lo idea del servidor intermedio me parece brutal y estoy con David en que, de hacerse así, es preferible importar todo e ir corrigiendo poco a poco. ¿Brutal de bueno o de malo? El problema es que como se está viendo en el otro hilo las cosas van a llevar su tiempo para empezar con el conjunto, mientras que si nos ponemos podríamos empezar en breve con elemtex. Por ahora parece que hay dos personas que opinan que no merece la pena empezar con elemtex y una (yo) que sí. ¿Alguien más? Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
Hola, Aunque soy un novato total y muchas de las implicaciones quizá no las entienda, creo que una solución podría ser dejarlo como está, para que genere las relaciones (que parece que 'formalmente' es más correcto en muchos casos) y añadir una opción (vía parámetro o vía fichero de configuración) para que lo haga todo con vías superpuestas. De esta forma no perderíamos funcionalidad y quedaría a criterio de cada uno generar la información como prefiera. Claro que no tengo ni idea de cómo sería de costoso técnicamente hacer esto :-) En mi opinión después de estar viendo los ficheros generados para Talavera y para Cazalegas, sinceramente no veo claro tanta relación. Lo de las vías superpuestas no es que sea la panacea, pero me parece más simple. Un saludo, -- Antonio Navarro mailto:anto...@hunos.net mailto:antonio.navarro...@gmail.com mailto:antonio.nava...@hispalinux.es El 15 de junio de 2012 18:23, Javier Sánchez javiers...@gmail.comescribió: El día 15 de junio de 2012 13:04, Ander Pijoan ander.pij...@deusto.es escribió: Yo no digo eliminar las relaciones de cuajo del resultado allí donde hagan falta (edificios con agujeros, lineas de autobus con sus paradas, carreteras muy largas, trazados de ferrocarril...). Para eso son las relaciones. Lo que digo que creo que no hay que hacer y que no aporta ninguna ventaja es utilizar relaciones para reutilizar ways. ¿En qué parte de la wiki de OSM se indica que tenga que hacerse eso así? Lo de Girona no se lo que dirían en su día y, también hay que decirlo, tal y como están esas, construcciones están correctas, pero ¿qué beneficia el hacerlo así? ¿Puestos a pedir por qué yo no podría hacer que una población sea una relation grande, cuyos members son otras relations que son sus manzanas con role inner, esas manzanas a su vez compuestas de otras relations que son las parcelas... El esquema lo permite, pero llega un momento en el que no tiene sentido y no mejora nada. Lo normal en OSM http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png Lo que se propuso para cat2osm en un principio pero que ya no lo veo lógico. http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png Esta reutilización de geometrías para evitar bordes superpuestos vuelvo a repetir que no mejora nada. Para todo lo demás, las relaciones siguen siendo totalmente necesarias. Hay que buscar un término medio. Emplear vías superpuestas en unos casos y relaciones en otros según nos interese, y fusionar vías adyacentes con los mismos usos en los casos en que está claro como rústico. Ahora bien, veo dos formas de hacerlo. A) Reescribir todo el código para que genere vías superpuestas excepto relaciones en algunos casos. B) Dejar el código más o menos como está, generando relaciones para todo y pasar un proceso posterior que simplifique relaciones y sustituya por vías superpuestas en algunos casos. Supongo que B da menos trabajo pero tendrá más coste en tiempo de proceso. Javier. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [Catastro] Elemtex
Brutal de buena. Yo creo que todo lo que no sean parcelas y edificios se puede ir trabajando. El día 15 de junio de 2012 20:26, Javier Sánchez javiers...@gmail.com escribió: Hola El día 15 de junio de 2012 08:22, Cruz Enrique Borges cruz.bor...@deusto.es escribió: A mi lo idea del servidor intermedio me parece brutal y estoy con David en que, de hacerse así, es preferible importar todo e ir corrigiendo poco a poco. ¿Brutal de bueno o de malo? El problema es que como se está viendo en el otro hilo las cosas van a llevar su tiempo para empezar con el conjunto, mientras que si nos ponemos podríamos empezar en breve con elemtex. Por ahora parece que hay dos personas que opinan que no merece la pena empezar con elemtex y una (yo) que sí. ¿Alguien más? Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...
La idea, que haga una cosa u otra, creo que era no perder lo que ya esta hecho del programa y aunque no se use no llegar y borrarlo. No van a tirar todo el trabajo que llevan hasta ahora mas cuando mas adelante a lo mejor hace falta. Lo de que cada uno elija como hacerlo en principio no seria factible. Esto nos tiene que dar un cierto permiso el resto de la comunidad y que cada uno lo haga de su manera va a ser que nos van a decir que no. Las relaciones a primera vista parecen muy difíciles y como están planteados los programas de edición aun mas. Pero cuando te metes con las relaciones, las manejas un poco y ves las 4 cosas básicas no es para tanto. Pensandolo ahora, que se usen para todo o solo para lo esencial vamos a tener igualmente relaciones y estaría bien hacer una pequeña guia de las 4 cosas básicas. El día 15 de junio de 2012 20:33, Antonio Navarro anto...@hunos.net escribió: Hola, Aunque soy un novato total y muchas de las implicaciones quizá no las entienda, creo que una solución podría ser dejarlo como está, para que genere las relaciones (que parece que 'formalmente' es más correcto en muchos casos) y añadir una opción (vía parámetro o vía fichero de configuración) para que lo haga todo con vías superpuestas. De esta forma no perderíamos funcionalidad y quedaría a criterio de cada uno generar la información como prefiera. Claro que no tengo ni idea de cómo sería de costoso técnicamente hacer esto :-) En mi opinión después de estar viendo los ficheros generados para Talavera y para Cazalegas, sinceramente no veo claro tanta relación. Lo de las vías superpuestas no es que sea la panacea, pero me parece más simple. Un saludo, -- Antonio Navarro mailto:anto...@hunos.net mailto:antonio.navarro...@gmail.com mailto:antonio.nava...@hispalinux.es El 15 de junio de 2012 18:23, Javier Sánchez javiers...@gmail.com escribió: El día 15 de junio de 2012 13:04, Ander Pijoan ander.pij...@deusto.es escribió: Yo no digo eliminar las relaciones de cuajo del resultado allí donde hagan falta (edificios con agujeros, lineas de autobus con sus paradas, carreteras muy largas, trazados de ferrocarril...). Para eso son las relaciones. Lo que digo que creo que no hay que hacer y que no aporta ninguna ventaja es utilizar relaciones para reutilizar ways. ¿En qué parte de la wiki de OSM se indica que tenga que hacerse eso así? Lo de Girona no se lo que dirían en su día y, también hay que decirlo, tal y como están esas, construcciones están correctas, pero ¿qué beneficia el hacerlo así? ¿Puestos a pedir por qué yo no podría hacer que una población sea una relation grande, cuyos members son otras relations que son sus manzanas con role inner, esas manzanas a su vez compuestas de otras relations que son las parcelas... El esquema lo permite, pero llega un momento en el que no tiene sentido y no mejora nada. Lo normal en OSM http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png Lo que se propuso para cat2osm en un principio pero que ya no lo veo lógico. http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png Esta reutilización de geometrías para evitar bordes superpuestos vuelvo a repetir que no mejora nada. Para todo lo demás, las relaciones siguen siendo totalmente necesarias. Hay que buscar un término medio. Emplear vías superpuestas en unos casos y relaciones en otros según nos interese, y fusionar vías adyacentes con los mismos usos en los casos en que está claro como rústico. Ahora bien, veo dos formas de hacerlo. A) Reescribir todo el código para que genere vías superpuestas excepto relaciones en algunos casos. B) Dejar el código más o menos como está, generando relaciones para todo y pasar un proceso posterior que simplifique relaciones y sustituya por vías superpuestas en algunos casos. Supongo que B da menos trabajo pero tendrá más coste en tiempo de proceso. Javier. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-lv] Bing esot pamatīgi atjaunināts
Iiiideali! Vecpiebalgas apkārtne ir smuki redzama, un tās vietas ko esmu observējis un zīmējis onsaitā izskatās bez nobīdēm. Vēl tikai vajadzētu kādas pāris stundas pie diennakts kautkā dabūt klāt :D Gasha On 06/13/2012 09:17 PM, Instigater wrote: On 2012.06.13. 21:02, cuu...@gmail.com wrote: Interesanti, Limbažos piem. ir bildes 18+ zoom līmeņiem (ultra-, super-), bet 15+ nav. Analizētājtūlī, attiecīgi, rāda visu sarkanu, līdz pievelk līdz 18+, un tad paliek zils. Tā ka, meklējot jaunas bildes, ir vērts pievilkt pavisam tuvu. Nu re, Limbaži OSM kartē diezgan minimāli sazīmēti (ielas, daži veikali, dažas stāvvietas, baznīca). Labs kandidāts mapping party ;-) Aha, paldies par hintu, tagad nodarbojos ar piespiedu updeitu lielākām Latvijas teritorijām. ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
