[Talk-transit] Should I split roads to create bus routes?
In order to create a bus route relation, I would have to split roads into many small segments with identical tags. This causes Andy Allan's transport render to repeat route labels more than necessary as a side effect. Should I split the road segments or use some other method for creating bus route relations? ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Should I split roads to create bus routes?
In order to create a bus route relation, I would have to split roads into many small segments with identical tags. This causes Andy Allan's transport render to repeat route labels more than necessary as a side effect. Should I split the road segments or use some other method for creating bus route relations? Don't map for renderer, map reality. You should split the road into segments if your route require that split. Good renderer can combine segments with same information before rendering. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping intercity bus routes
What about a three-level service scheme for buses: Service=local (transit system bus lines) Service=commuter (express commuter buses to the suburbs) Service=intercity (like the American Greyhound bus routes) There might be grey areas but it should be fairly easy to fit most routes in one of these three categories. Bill R. WASHBURN On May 26, 2014 11:03 AM, Teemu Ikonen tpiko...@gmail.com wrote: Hi, Thanks to all for the replies on coach route mapping. I don't agree that this is purely a rendering problem. The information needed to distinguish urban bus transit from long distance coach services simply does not exist in the database at the moment and there is no consistent way of tagging routes so that this distinction could be made. Looking at the active public transport proposal again, the network tag of route=bus/train/subway/tram could be part of a solution, but it seems that the usage is not really consistent everywhere. For example, in Helsinki the bus routes have network=Helsinki, subway has network='Helsingin metro' and so on, even though both can be used with the same ticket. This could be a local problem though. I still think that long distance services which are not part of an urban transit network should be distinguished somehow, so I like the idea of using service=express for coaches. This could mostly do what I was proposing, if it would be widely used and the rendered correctly. Currently this tag seems to be used only around Oxford and ignored by tile rendering style sheets. The rendering of coach routes should be de-emphasized in high zoom levels, i.e. they should be overdrawn by local transit bus lines, but on the other hand they should be also drawn in low zoom levels, like long distance train routes in Öpnvkarte are. Best, Teemu ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping intercity bus routes
While you could call all intercity buses express buses. Not all express buses are intercity buses. A common scheme around here is for rush hour express lines that stop at all stops in the suburbs/villages, then skip most/all stops in the city proper and end at the central (bus)station. The original Oxomoa scheme already contained a solution to your problem[1]. It simply is not widely used yet. See taginfo[2]: bus=long_distance (70 uses currently in the database) bus=interurban (59 uses currently in the database) It would be handy to standardize on one of those two. [1]http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema#Bus-_und_Oberleitungsbuslinien [2]http://taginfo.openstreetmap.org/keys/bus#values On 05/26/2014 05:02 PM, Teemu Ikonen wrote: Hi, Thanks to all for the replies on coach route mapping. I don't agree that this is purely a rendering problem. The information needed to distinguish urban bus transit from long distance coach services simply does not exist in the database at the moment and there is no consistent way of tagging routes so that this distinction could be made. Looking at the active public transport proposal again, the network tag of route=bus/train/subway/tram could be part of a solution, but it seems that the usage is not really consistent everywhere. For example, in Helsinki the bus routes have network=Helsinki, subway has network='Helsingin metro' and so on, even though both can be used with the same ticket. This could be a local problem though. I still think that long distance services which are not part of an urban transit network should be distinguished somehow, so I like the idea of using service=express for coaches. This could mostly do what I was proposing, if it would be widely used and the rendered correctly. Currently this tag seems to be used only around Oxford and ignored by tile rendering style sheets. The rendering of coach routes should be de-emphasized in high zoom levels, i.e. they should be overdrawn by local transit bus lines, but on the other hand they should be also drawn in low zoom levels, like long distance train routes in Öpnvkarte are. Best, Teemu ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit -- --- m.v.g., Cartinus ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping intercity bus routes
I just realized that for people living in a bigger country there might actually be a difference between those two. There is however no reason they could not be rendered the same (at least initially). On 05/26/2014 05:46 PM, Cartinus wrote: bus=long_distance (70 uses currently in the database) bus=interurban (59 uses currently in the database) It would be handy to standardize on one of those two. --- m.v.g., Cartinus ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[talk-ph] Highway Stats
Hi All Here are some OSMPH Highway Stats highway=* unclassified=29225 Track=4 footway=12643 motorway=694 proposed=14 raceway=27 motorway_link=577 steps=1159 FIXME=2 pedestrian=778 bridleway=25 unclassified;road=1 ford=3 trunk_link=610 cycleway=176 living_street=3448 residential=217094 service;track=1 ras=1 construction=312 yes=14 secondary=9585 primary=8703 track=33246 unclassified_link=6 trunk=5611 tertiary=19037 tertiary_link=474 tre=5 secondary_link=405 emergency_access_point=2 primary_link=844 services=1 crossing=3 rtra=1 service=34957 path=10976 residential;track=1 turning_circle=7 river=1 road=6320 passing_place=1 RO=1 Regards Mark Cupitt If we change the world, let it bear the mark of our intelligence See me on Open StreetMap https://www.openstreetmap.org/user/Mark_Cupitt See me on LinkedIn http://ph.linkedin.com/in/markcupitt *See me on StackExchange http://gis.stackexchange.com/users/17846/mark-c* === The contents of this email are intended only for the individual(s) to whom it is addressed and may contain confidential or privileged information. If you are not the intended recipient, you must not disclose, copy, distribute, or use the contents of this email. If you have received this email in error, please notify the sender immediately and delete the email and any attachments. === ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Highway POI's
And here is an analysis of the highway=* tags in the Nodes (Points) file turning_circle=1743 traffic_signals=1256 milestone=887 crossing=847 street_lamp=726 bus_stop=604 motorway_junction=363 mini_roundabout=174 emergency_access_point=128 trailhead=64 ford=28 stop=22 boundary=13 incline_steep=11 path=11 noexit=9 residential=9 incline=7 track=7 10_honeybear_stop=6 10_honeybear_street_lamp=6 rest_area=6 services=5 emergency_bay=5 passing_place=4 yes=4 jeepney_stop=3 =2 unclassified=2 motor_stop=1 jeep_stop=1 raceway=1 steps=1 pedestrian=1 bus_station=1 service=1 tricycle_station=1 road=1 ramp=1 FX/Jeep Terminal=1 Jeep_stop=1 Regards Mark Cupitt If we change the world, let it bear the mark of our intelligence See me on Open StreetMap https://www.openstreetmap.org/user/Mark_Cupitt See me on LinkedIn http://ph.linkedin.com/in/markcupitt *See me on StackExchange http://gis.stackexchange.com/users/17846/mark-c* === The contents of this email are intended only for the individual(s) to whom it is addressed and may contain confidential or privileged information. If you are not the intended recipient, you must not disclose, copy, distribute, or use the contents of this email. If you have received this email in error, please notify the sender immediately and delete the email and any attachments. === ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[OSM-talk-be] Neighborhood nodes
I have the following problem with Nominatim: http://nominatim.openstreetmap.org/details.php?place_id=36580812 It tells me that is part of the neighbourhood Bosstraat. This is not true, but it is the nearest neighbourhood node it can find in Boom. In order to fix this I have to draw a border around this neighbourhood. Could I use admin_level=10 for this ? it will be some kind of fuzzy border as there is no well defined one. regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Neighborhood nodes
On 2014-05-26 18:10, Marc Gemis wrote : I have the following problem with Nominatim: http://nominatim.openstreetmap.org/details.php?place_id=36580812 It tells me that is part of the neighbourhood "Bosstraat". This is not true, but it is the nearest neighbourhood node it can find in Boom. In order to fix this I have to draw a border around this neighbourhood. Could I use admin_level=10 for this ? it will be some kind of fuzzy border as there is no well defined one. You might add a nearer (better) neighborhood for that wrong "is part of", but you will start a never ending game ;-) Seriously, the problem, as you conclude, is of course defining a neighborhood with a node. The wiki says it can be tagged on polygons but, sadly, isn't clear about relations, this is why it's a pity... I have the same problem with the ubiquitous concept or region (place=region). That is the funniest tag ever: it cannot be put on a node, nor on a way, nor on an area nor on a relation!!! ;-) I have made a region Ourthe-Amblève with a boundary=region relation (that I'd better call touristic_region). It is not an administrative boundary, so, it has no admin_level. (yet, I used admin_center for the tourist desk). I should try to make it a plain multipolygon with place=region. In that case, the boundary is well defined because the region is a set of municipalities and I reused their borders as outer ways and subareas. But what if those fuzzy borders are not well defined as in your case? Well, that could be very simple in my mind. One uses a relation that has no borders (hence not a boundary and not a multipolygon) and one puts as members of this relation as many map elements as necessary and aesthetically to best define it: streets, any node, landuse areas, etc... Just a few nodes define your neighborhood reasonably. The Nominatim's job is then to choose the place= relation whose members surround the target. The Renderer's job is, as the best option failing to have a border to outline the area, to highlight all of its members. Simple enough isn't it? And probably just a few details to settle with Nominatim and Standard Map. And that would make less fuzzy place=region place=... articles too. Hoping this can help. André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk] Converting .osm file into shape file or mapinfo table
After a few months break from mapping I'm having dificulty converting .osm files into mapinfo tables. Before the break I could import the .osm into qgis then export is as needed but now Qgis wont do this. With the old wiki I could find a section that listed and described a number of tools for various manipulations of osm data, this seems to be missing or moved to somewhere not directly accessable from the wiki. Could someone help this old fool find it again please. mik ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Converting .osm file into shape file or mapinfo table
Below is what I would do on my MacBook. More info at http://www.gdal.org/drv_osm.html Hermann $ wget http://download.geofabrik.de/europe/liechtenstein-latest.osm.pbf $ mkdir outfiles $ ogr2ogr outfiles/ liechtenstein-latest.osm.pbf $ ls -1 outfiles/ lines.dbf lines.prj lines.shp lines.shx multilinestrings.dbf multilinestrings.prj multilinestrings.shp multilinestrings.shx multipolygons.dbf multipolygons.prj multipolygons.shp multipolygons.shx points.dbf points.prj points.shp points.shx On 2014-05-27 3:34, mick wrote: After a few months break from mapping I'm having dificulty converting .osm files into mapinfo tables. Before the break I could import the .osm into qgis then export is as needed but now Qgis wont do this. With the old wiki I could find a section that listed and described a number of tools for various manipulations of osm data, this seems to be missing or moved to somewhere not directly accessable from the wiki. Could someone help this old fool find it again please. mik ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Converting .osm file into shape file or mapinfo table
On Di, Mai 27, 2014 at 11:34:53 +1000, mick wrote: After a few months break from mapping I'm having dificulty converting .osm files into mapinfo tables. Before the break I could import the .osm into qgis then export is as needed but now Qgis wont do this. With the old wiki I could find a section that listed and described a number of tools for various manipulations of osm data, this seems to be missing or moved to somewhere not directly accessable from the wiki. Could someone help this old fool find it again please. Maybe you meant this page: http://wiki.openstreetmap.org/wiki/Shapefiles Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Definições Mapatona
Criei um formulário de inscrições e coloquei lá. Vamos fazer circular? Divulguem: https://wiki.openstreetmap.org/mapatona 2014-05-26 0:02 GMT-03:00 Wille wi...@wille.blog.br: Como não houve nenhuma opinião a mais sobre a data da Mapatona, vamos definir dia 31 de maio mesmo, a partir das 08h da manhã e sem hora para parar. Criei um redirecionamento mais simples para a página do wiki que podemos usar para a divulgação: http://wiki.osm.org/mapatona abraços, wille ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Tradução de highway=track
Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Restrições de curva no editor iD
Amigos, Parece que nas próximas versões do editor iD, vão adicionar suporte a restrições de curva: https://twitter.com/jfire/status/469244039791779840 que é uma das funcionalidades mais desejadas pela comunidade. Já está disponível para testes no servidor de desenvolvimento deles (link no final do tweet) Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Antes era trilha automotiva. Mas eu andei pensando que talvez trilha agrícola alinharia esses usuários melhor com a definição original em inglês. Isso os deixaria um pouco confusos ao ver essas trilhas em florestas, mas como é o caso mais raro, pode ser mais fácil explicar que é um caso especial da regra quando acontecer. Ou podemos traduzir como trilha agrícola/florestal e tudo fica resolvido. :P 2014-05-26 10:47 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.comescreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias ) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Acho trilha rural melhor. Em 26 de maio de 2014 11:22, Fernando Trebien fernando.treb...@gmail.comescreveu: Antes era trilha automotiva. Mas eu andei pensando que talvez trilha agrícola alinharia esses usuários melhor com a definição original em inglês. Isso os deixaria um pouco confusos ao ver essas trilhas em florestas, mas como é o caso mais raro, pode ser mais fácil explicar que é um caso especial da regra quando acontecer. Ou podemos traduzir como trilha agrícola/florestal e tudo fica resolvido. :P 2014-05-26 10:47 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias ) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
+1 O definicao do track e um trilha com largura suficiente para camionhetes, mas path e trilhas inferior Aun Johnsen Sent from my iPhone On 26. mai 2014, at 11:25, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Acho trilha rural melhor. Em 26 de maio de 2014 11:22, Fernando Trebien fernando.treb...@gmail.com escreveu: Antes era trilha automotiva. Mas eu andei pensando que talvez trilha agrícola alinharia esses usuários melhor com a definição original em inglês. Isso os deixaria um pouco confusos ao ver essas trilhas em florestas, mas como é o caso mais raro, pode ser mais fácil explicar que é um caso especial da regra quando acontecer. Ou podemos traduzir como trilha agrícola/florestal e tudo fica resolvido. :P 2014-05-26 10:47 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Hm mas você não acha que com trilha rural as pessoas (ou algumas delas) ainda marcariam como highway=track as estradas não-pavimentadas que aparecem fora das cidades? 2014-05-26 11:25 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Acho trilha rural melhor. Em 26 de maio de 2014 11:22, Fernando Trebien fernando.treb...@gmail.com escreveu: Antes era trilha automotiva. Mas eu andei pensando que talvez trilha agrícola alinharia esses usuários melhor com a definição original em inglês. Isso os deixaria um pouco confusos ao ver essas trilhas em florestas, mas como é o caso mais raro, pode ser mais fácil explicar que é um caso especial da regra quando acontecer. Ou podemos traduzir como trilha agrícola/florestal e tudo fica resolvido. :P 2014-05-26 10:47 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Trilha é um termo muito amplo usado em diversos contextos. Existem as: - trilhas de hiking/trekking - trilhas de mountain bike - trilhas de jipeiros (trekking) - trilhas de GPS (e deve ter outras por aí) Caminho sofre do mesmo problema. Praticamente tudo (inclusive motorways) é caminho para alguma coisa. Da última vez que discutimos sobre o termo, a conclusão foi que ele deve ser evitado sozinho: é melhor ter outra palavra pra ajudar a especificar à qual dessas trilhas você se refere. 2014-05-26 11:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.com escreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Achei a discussão anterior: http://forum.openstreetmap.org/viewtopic.php?pid=400258#p400258 On May 26, 2014 12:04 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Trilha é um termo muito amplo usado em diversos contextos. Existem as: - trilhas de hiking/trekking - trilhas de mountain bike - trilhas de jipeiros (trekking) - trilhas de GPS (e deve ter outras por aí) Caminho sofre do mesmo problema. Praticamente tudo (inclusive motorways) é caminho para alguma coisa. Da última vez que discutimos sobre o termo, a conclusão foi que ele deve ser evitado sozinho: é melhor ter outra palavra pra ajudar a especificar à qual dessas trilhas você se refere. 2014-05-26 11:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.com escreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias ) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Isso foi algo que eu aprendi com o tempo e acredito que para os novatos deva ser complicado absorver esses conceitos. De qualquer forma eu ainda fico com dúvidas de como eu posso mapear alguns logradouros realmente em péssimas condições. surface=unpaved não reflete de forma satisfatório o estado de alguns logradouros em bairros muito pobres, onde a superficie é bastante acidentada e o acesso é apenas a pé ou com carros grandes. Quando as vias são muito estreitas eu uso simplesmente o highway=path. Marcio Aguiar Ribeiro 2014-05-26 11:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.comescreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias ) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
2014-05-26 12:46 GMT-03:00 Márcio Aguiar Ribeiro aguiar.mar...@gmail.com: Isso foi algo que eu aprendi com o tempo e acredito que para os novatos deva ser complicado absorver esses conceitos. De qualquer forma eu ainda fico com dúvidas de como eu posso mapear alguns logradouros realmente em péssimas condições. surface=unpaved não reflete de forma satisfatório o estado de alguns logradouros em bairros muito pobres, onde a superficie é bastante acidentada e o acesso é apenas a pé ou com carros grandes. Quando as vias são muito estreitas eu uso simplesmente o highway=path. Se a superfície é muito ruim você pode usar a tag smoothnesshttp://wiki.openstreetmap.org/wiki/Key:smoothness (lisura?), eu tenho usado smoothness=bad para vias de terra em condições precárias onde seria necessário um carro mais robusto ou alto. Também tenho usado smoothness=bad em conjunto com surface=asphalt quando o asfalto existe mas está em condições muito ruins. Existe ainda uma tag de classificação de tracks chamada tracktypehttp://wiki.openstreetmap.org/wiki/Key:tracktype, mas esta eu não consigo usar de jeito nenhum, nunca consigo decidir em qual categoria encaixar a via. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Olá Marcio, Vou tentar adiantar a tradução das tags tracktype e smoothness pra auxiliar nessa questão. Elas servem para refinar a especificação da superficie. Um resumo: - surface especifica o material (e tem vários mais descritivos do que o genérico unpaved, que não diz muito) - tracktype especifica a rigidez do material (mais útil para materiais soltos como terra e grama) - smoothness especifica a regularidade da superfície A princípio qualquer combinação é possivel. Surface=paved ou surface=asphalt pode ser combinada com smoothness=bad pra indicar muitos buracos ou oscilações na pista. (Mas geralmente asfalto se combina com tracktype=grade1 porque difícilmente o asfalto é mole, como a terra é. Daí o costume seria colocar tracktype só em casos excepcionais, mas nada impede que você coloque.) Surface=earth (terra) pode se combinar ao mesmo tempo com smoothness=intermediate se normalmente tiver poucos buracos e com tracktype=grade5 se o material for solto e sujeito à erosão. (Isso daria a entender que os buracos da erosão são reparados rapidamente pela administração local.) Obs.: antes que alguém pergunte, tracktype não é para uso exclusivamente com highway=track. Diz no wiki faz uns anos já. On May 26, 2014 12:47 PM, Márcio Aguiar Ribeiro aguiar.mar...@gmail.com wrote: Isso foi algo que eu aprendi com o tempo e acredito que para os novatos deva ser complicado absorver esses conceitos. De qualquer forma eu ainda fico com dúvidas de como eu posso mapear alguns logradouros realmente em péssimas condições. surface=unpaved não reflete de forma satisfatório o estado de alguns logradouros em bairros muito pobres, onde a superficie é bastante acidentada e o acesso é apenas a pé ou com carros grandes. Quando as vias são muito estreitas eu uso simplesmente o highway=path. Marcio Aguiar Ribeiro 2014-05-26 11:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.comescreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias ) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Muito boa a explicação, Fernando! Acho que meu pior problema era justamente pensar que o tracktype era exclusividade do highway=track. Acabei de ir lá no wiki ver e confirmei o que você disse. Obrigado! Marcio Aguiar Ribeiro 2014-05-26 13:13 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Olá Marcio, Vou tentar adiantar a tradução das tags tracktype e smoothness pra auxiliar nessa questão. Elas servem para refinar a especificação da superficie. Um resumo: - surface especifica o material (e tem vários mais descritivos do que o genérico unpaved, que não diz muito) - tracktype especifica a rigidez do material (mais útil para materiais soltos como terra e grama) - smoothness especifica a regularidade da superfície A princípio qualquer combinação é possivel. Surface=paved ou surface=asphalt pode ser combinada com smoothness=bad pra indicar muitos buracos ou oscilações na pista. (Mas geralmente asfalto se combina com tracktype=grade1 porque difícilmente o asfalto é mole, como a terra é. Daí o costume seria colocar tracktype só em casos excepcionais, mas nada impede que você coloque.) Surface=earth (terra) pode se combinar ao mesmo tempo com smoothness=intermediate se normalmente tiver poucos buracos e com tracktype=grade5 se o material for solto e sujeito à erosão. (Isso daria a entender que os buracos da erosão são reparados rapidamente pela administração local.) Obs.: antes que alguém pergunte, tracktype não é para uso exclusivamente com highway=track. Diz no wiki faz uns anos já. On May 26, 2014 12:47 PM, Márcio Aguiar Ribeiro aguiar.mar...@gmail.com wrote: Isso foi algo que eu aprendi com o tempo e acredito que para os novatos deva ser complicado absorver esses conceitos. De qualquer forma eu ainda fico com dúvidas de como eu posso mapear alguns logradouros realmente em péssimas condições. surface=unpaved não reflete de forma satisfatório o estado de alguns logradouros em bairros muito pobres, onde a superficie é bastante acidentada e o acesso é apenas a pé ou com carros grandes. Quando as vias são muito estreitas eu uso simplesmente o highway=path. Marcio Aguiar Ribeiro 2014-05-26 11:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.comescreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias ) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tradução de highway=track
Como eu entendi o tracktype e o leitura, se o track e fazil p identificar (bem vicivel) ou nao. O tracktype 1 e quase visibel como um rua, mas tracktype 5 e quase invisivel Um tracktype 1 ainda pode ser cheia do buracos com smoothness=bad, e tracktype 5 ainda pode ter um smoothness mais agradavel Aun Johnsen Sent from my iPhone On 26. mai 2014, at 13:13, Fernando Trebien fernando.treb...@gmail.com wrote: Olá Marcio, Vou tentar adiantar a tradução das tags tracktype e smoothness pra auxiliar nessa questão. Elas servem para refinar a especificação da superficie. Um resumo: - surface especifica o material (e tem vários mais descritivos do que o genérico unpaved, que não diz muito) - tracktype especifica a rigidez do material (mais útil para materiais soltos como terra e grama) - smoothness especifica a regularidade da superfície A princípio qualquer combinação é possivel. Surface=paved ou surface=asphalt pode ser combinada com smoothness=bad pra indicar muitos buracos ou oscilações na pista. (Mas geralmente asfalto se combina com tracktype=grade1 porque difícilmente o asfalto é mole, como a terra é. Daí o costume seria colocar tracktype só em casos excepcionais, mas nada impede que você coloque.) Surface=earth (terra) pode se combinar ao mesmo tempo com smoothness=intermediate se normalmente tiver poucos buracos e com tracktype=grade5 se o material for solto e sujeito à erosão. (Isso daria a entender que os buracos da erosão são reparados rapidamente pela administração local.) Obs.: antes que alguém pergunte, tracktype não é para uso exclusivamente com highway=track. Diz no wiki faz uns anos já. On May 26, 2014 12:47 PM, Márcio Aguiar Ribeiro aguiar.mar...@gmail.com wrote: Isso foi algo que eu aprendi com o tempo e acredito que para os novatos deva ser complicado absorver esses conceitos. De qualquer forma eu ainda fico com dúvidas de como eu posso mapear alguns logradouros realmente em péssimas condições. surface=unpaved não reflete de forma satisfatório o estado de alguns logradouros em bairros muito pobres, onde a superficie é bastante acidentada e o acesso é apenas a pé ou com carros grandes. Quando as vias são muito estreitas eu uso simplesmente o highway=path. Marcio Aguiar Ribeiro 2014-05-26 11:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu tenho usado o seguinte critério: -Se a via é um logradouro, uso highway sem ser track e coloco surface=unpaved. -Se a via é um caminho de uso específico (jipeiros, máquinas agrícolas, motocross, etc.) eu uso highway=track. Parece-me que as traduções estão imprecisas. Track seria trilha e path seria caminho. Trilha inclusive é nome pelo qual os jipeiros conhecem essas vias. Em 26 de maio de 2014 10:47, Nelson A. de Oliveira nao...@gmail.com escreveu: Estava reparando que alguns usuários estão mapeando várias estradas de terra como highway=track Fui ver o porque e, de certa forma, estão fazendo isso corretamente pela tradução do iD (mas errado para o OSM). highway=track no iD está como Estrada rústica (assim como a recomendação em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#Rodovias) Estrada rústica leva muitos usuários a, erroneamente, classificar todas as estradas de terra como highway=track Não é mais correto utilizar trilha automotiva (assim como já se utiliza trilha não-automotiva para path)? (ou talvez outra frase que passe melhor o significado de track) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Usuário cintiadepinhopinto apagando dados
Descobri mais um usuário apagando dados válidos: http://naoliv.iq.unesp.br/osm/cintiadepinhopinto/ Ordenem pela coluna de Apagados Enviei mensagem, mas seria bom mais alguém perguntar o motivo. Vou verificar os changesets e reverter pelo menos os dados apagados de forma indevida. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Usuário cintiadepinhopinto apagando dados
A http://www.openstreetmap.org/user/cintiadepinhopinto me lembra muito as edições do http://www.openstreetmap.org/user/luisfelipevieirademedeiros Usuário foi criado um dia depois que o luis parou de editar (porque tomou block). Os dados são fictícios no mesmo nível: http://www.openstreetmap.org/way/277725151 Também há muita semelhança nos dados válidos que são apagados. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Usuário cintiadepinhopinto apagando dados
2014-05-26 15:40 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: 2.000.000 de pessoas na Groenlândia? Só pode estar de brincadeira... Para mim estão claras as intenções: vandalismo. Eu estou acabando de verificar os changesets (não tem nada de proveitoso até agora), mas pra mim é o mesmo usuário que antes. Faz exatamente a mesma coisa: brinca de SimCity e apaga os dados. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Usuário cintiadepinhopinto apagando dados
Pode entrar em contato com o DWG e pedir para bloquear. O DWG diz que prefere que as comunidades resolvam seus problemas localmente, mas ao menos tempo dizem que não veem muitos problemas com o Brazil porque não recebem muitos relatos. Sugiro que sempre que ocorram problemas desta natureza que a gente consiga resolver localmente o DWG seja informado da ocorrência. abraço Gerald PS: Nelson, sempre me impressiona como você descobre estas coisas. 2014-05-26 15:07 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Descobri mais um usuário apagando dados válidos: http://naoliv.iq.unesp.br/osm/cintiadepinhopinto/ Ordenem pela coluna de Apagados Enviei mensagem, mas seria bom mais alguém perguntar o motivo. Vou verificar os changesets e reverter pelo menos os dados apagados de forma indevida. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Dr. Gerald Weber gwebe...@gmail.com Personal website https://sites.google.com/site/geraldweberufmg/ Departamento de Física/Universidade Federal de Minas Gerais Department of Physics/Federal University of Minas Gerais Campus da Pampulha Av. Antônio Carlos, 6627, 31270-901 Belo Horizonte, MG, Brazil mobile: +55-(0)31-96462277 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de curva no editor iD
Não entendi. Não já tinha isso? Aquele tutorial de restrições elaborado pelo Nighto é o que? From: john.pack...@gmail.com Date: Mon, 26 May 2014 11:15:45 -0300 To: talk-br@openstreetmap.org Subject: [Talk-br] Restrições de curva no editor iD Amigos, Parece que nas próximas versões do editor iD, vão adicionar suporte a restrições de curva: https://twitter.com/jfire/status/469244039791779840 que é uma das funcionalidades mais desejadas pela comunidade. Já está disponível para testes no servidor de desenvolvimento deles (link no final do tweet) Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de curva no editor iD
É uma facilidade. Olhe http://i.imgur.com/X00FVxE.gif. Em 26 de maio de 2014 15:55, Raffaello Bruno Limongi Freire raffaellobr...@hotmail.com escreveu: Não entendi. Não já tinha isso? Aquele tutorial de restrições elaborado pelo Nighto é o que? -- From: john.pack...@gmail.com Date: Mon, 26 May 2014 11:15:45 -0300 To: talk-br@openstreetmap.org Subject: [Talk-br] Restrições de curva no editor iD Amigos, Parece que nas próximas versões do editor iD, vão adicionar suporte a restrições de curva: https://twitter.com/jfire/status/469244039791779840 que é uma das funcionalidades mais desejadas pela comunidade. Já está disponível para testes no servidor de desenvolvimento deles (link no final do tweet) Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de curva no editor iD
Ah, desculpem eu ter perguntado antes de conferir. Vai ajudar muito aos iniciantes. :) From: alexandre@gmail.com Date: Mon, 26 May 2014 16:13:24 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Restrições de curva no editor iD É uma facilidade. Olhe http://i.imgur.com/X00FVxE.gif. Em 26 de maio de 2014 15:55, Raffaello Bruno Limongi Freire raffaellobr...@hotmail.com escreveu: Não entendi. Não já tinha isso? Aquele tutorial de restrições elaborado pelo Nighto é o que? From: john.pack...@gmail.com Date: Mon, 26 May 2014 11:15:45 -0300 To: talk-br@openstreetmap.org Subject: [Talk-br] Restrições de curva no editor iD Amigos, Parece que nas próximas versões do editor iD, vão adicionar suporte a restrições de curva: https://twitter.com/jfire/status/469244039791779840 que é uma das funcionalidades mais desejadas pela comunidade. Já está disponível para testes no servidor de desenvolvimento deles (link no final do tweet) Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Usuário cintiadepinhopinto apagando dados
Eu reverti as edições dela/dele (vai saber quem realmente é) em http://www.openstreetmap.org/changeset/22569482 Pra mim é o mesmo usuário de antes. Inclusive apagou várias coisas que já tinha apagado com o outro usuário. Exemplo: http://www.openstreetmap.org/way/253716849/history (notem que foi apagado pelo luisfelipevieirademedeiros, restaurado pelo DWG e apagado de novo pela cintiadepinhopinto) PS: Nelson, sempre me impressiona como você descobre estas coisas. É na sorte que acabo achando isso :-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Usuário cintiadepinhopinto apagando dados
Complicadas essas coisas. Imagina o que pode passar despercebido em outros lugares. Ainda bem que se trata de um caso pontual. Date: Mon, 26 May 2014 17:19:43 -0300 From: nao...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br]Usuário cintiadepinhopinto apagando dados Eu reverti as edições dela/dele (vai saber quem realmente é) em http://www.openstreetmap.org/changeset/22569482 Pra mim é o mesmo usuário de antes. Inclusive apagou várias coisas que já tinha apagado com o outro usuário. Exemplo: http://www.openstreetmap.org/way/253716849/history (notem que foi apagado pelo luisfelipevieirademedeiros, restaurado pelo DWG e apagado de novo pela cintiadepinhopinto) PS: Nelson, sempre me impressiona como você descobre estas coisas. É na sorte que acabo achando isso :-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Usuário cintiadepinhopinto apagando dados
Também fico impressionado rs. A comunidade já pensou em criar um algoritmo para monitorar atividades suspeitas como grandes edições, remoções de usuários que foram acabados de criar? Poderia ser feita uma analise dessa forma para monitorar essas edições. Em 26/05/2014 17:19, Nelson A. de Oliveira escreveu: PS: Nelson, sempre me impressiona como você descobre estas coisas. É na sorte que acabo achando isso :-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Rotas circulares com OSM
Para quem ainda não conhece, com o RouteLoops http://www.routeloops.com/OSM/ dá para criar rotas circulares (iniciando e terminando no mesmo local) utilizando o OSM. É só especificar o local de partida e a distância que pretende percorrer. É bem útil para achar trajetos para fazer caminhadas, andar de bicicleta ou realizar survey. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] OSM e Folha de São Paulo
Folha de São Paulo coloca link em sua página principal para que os usuários tracem suas rotas, e o mapa é OSM, MOOVIT. Um passo interessante que o portal dá, pode fazer com que outros sites também olhem para a comunidade e posteriormente novos mapeadores. http://www1.folha.uol.com.br/cotidiano/transito/transportepublico/rotas.shtml ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OSM e Folha de São Paulo
Excelente. Em 27/05/2014 00:47, Tarcisio Oliveira tarci...@ymail.com escreveu: Folha de São Paulo coloca link em sua página principal para que os usuários tracem suas rotas, e o mapa é OSM, MOOVIT. Um passo interessante que o portal dá, pode fazer com que outros sites também olhem para a comunidade e posteriormente novos mapeadores. http://www1.folha.uol.com.br/cotidiano/transito/ transportepublico/rotas.shtml ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-is] Thank you Icelandic OSM!
Thank you for the nice compliments Carles and we are happy to see you use our work. Of course we have had many people, both locals and tourists, add stuff to the map for the past years. We are also getting more and more data released from the government with suitable licenses and are looking at more options there. This year we are starting some new initiatives to increase the quality even more, adding more farms, mapping more towns in detail and trying to enlist even more people! Do remember to tell your friend about OSM-apps, with Telenav switching their GPS Navigation (Scout) to OSM things got even better for iOs users! Best regards, Jóhannes / Stalfur on OSM Chairman of Hliðskjálf, www.hlidskjalf.is Þann 26.5.2014 22:19, skrifaði Carles Pina i Estany: Hi! I spent 5 days in Iceland - you have a beautiful country! (but this is off-topic here I guess). For the navigation I used OsmAnd which uses Open Street Map. This has been my first holidays with OsmAnd and I'm very satisfied. The quality of the Open Street Map in Iceland was very good! More than enough to get around without problems (we did from Reykjavik to the Glacier Lagoon). I could find all the guest houses in farms easily thanks to you guys (and OsmAnd), also in Reykjavik it served nicely too. Even when I was hiking I had the hiking paths! Please keep with the amazing job! And it made me proud of free software / free licenses that I've always supported. Meanwhile a friend is lost in another country searching for a data connection and using some other incomplete maps :-) I hope to return to iceland and I'll keep using OSM indeed :-) Regards! ___ Talk-is mailing list Talk-is@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-is
[Talk-de] Google Maps Pendant eigene Karte gesucht
Hallo, in Google Maps kann man Punkte, Linien und Flächen auf die Karte malen und als eigene Karte (eigentlich ja nur ein Layer mit den paar gemalten Sachen) abspeichern. Gibt es sowas auch in OSM-Format, d.h. OSM-Hintergrundkarte und speichern der gemalten Sachen in einer lokalen Datei oder auf dem Server? Gruß Johannes signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google Maps Pendant eigene Karte gesucht
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 05/26/2014 08:16 AM, Johannes wrote: Gibt es sowas auch in OSM-Format, d.h. OSM-Hintergrundkarte und speichern der gemalten Sachen in einer lokalen Datei oder auf dem Server? Da gibts verschiedenes, probier mal http://umap.openstreetmap.fr/ oder auch http://mapbbcode.org/ Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTgt2hAAoJEOx/uhGAJu9HPxgIAIuDmIi+SN5WHgHoVL9+s2bJ IqjS3L+sbcKV4FetzYiwGlCANG0+6Vn1+Zs6Fa5kcKqTep5gnd4SzHOYb6sTA4O9 jtXL2Xzif8xZlkZzOQeibrgdK6CfsWRCcGRoBnv7OwTF4n9yZa8rrBhvzM6fLX34 2XHcgP1msBJPG1ZfogipmV9r8PK/7HPFyzyID8R2aEiSbHUSFhWs/3Q8Xp2RCc4B rUyCH67YIhdzaxj4UFbdFrUxFAxnr2vItgjAFw42nUNHE41sTxGHrP1ov5GBIiQW I3/jcMlJjCuJ3Pyj/0iwbT7yeai02lhXwmf1vSo0UAGX6lZ1CaT0g+tgyil00sI= =p1kM -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 06:02, schrieb Dirk Sohler: simson.gert...@gmail.com schrieb: 1. Keine fehlertolerante Suchmaschine. … und dabei ist das doch nun wirklich eine der einfachsten Sachen, die man umsetzen kann :/ Ja sehe ich auch so. Idee wäre hier eine Autovervollständigung auf osm.org einzubauen. Sowas gibt es bereits auf Apache Solr-Basis, wobei die Daten aus Nominatim kommen. Siehe koomot.de, da läuft das bereits. Mit solr bekommst du auch ein Meinsten Sie... ? hin. 2. Kein guter Router. http://yournavigation.org/ funktioniert hier sehr gut, auch die Routenplanung in QLandkarte GT (gibt ja Tricks, dass das mit OSM wieder funktioniert *g*) funktioniert hier dank MapQuest oder OpenRouteService für verschiedene Verkehrsmittel sehr gut. Auch das Routing mit diversen Stand-Alone-Geräten funktioniert einwandfrei mit verschiedenen Verkehrsmitteln. Vergesst nicht graphhopper.com . Der hat auch verschiedene Modi und ist super einfach zu administrieren und braucht im Vergleich zu OSRM wenig RAM. Das ist mein Lieblingsrouter, der auch bei sehr langen Strecken nicht versagt, im Unterschied zu yournavigation.org . Was da auch neu ist, Anzeige vom Höhenprofil, weiß aber nicht wo die Daten herkommen und weiß auch nicht ob er höhenbewußt routet. Aber echt hilfreich bei der Planung. 3. Keine Satellitenbilder auf osm.org. OSM ist keine „Satellitenbilderseite“, sondern eine „Kartenseite“. Joo, Satellitenbilder sollten nicht auf osm.org erscheinen. Grüße Johannes signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie könnte man 5000 Euro für OSM sinnvoll verwenden?
Dieser Beitrag wurde auch im Forum gepostet: http://forum.openstreetmap.org/viewtopic.php?id=25619 Antworten gerne hier oder dort. -- Hallo, ich oute mich mal :-) Als Stipendiat der Studienstiftung des deutschen Volkes [1] darf ich mich für den Engagementpreis [2] der Studienstiftung bewerben. Zitat aus der Ausschreibung: Mit „weiter?geben! – der Engagementpreis der Studienstiftung“ möchte die Studienstiftung ihre Stipendiaten in ihren gesellschaftlichen Anliegen und dem Wunsch etwas zu verändern, erstmals öffentlich und auch finanziell unterstützen. Der Preis ist mit 5.000 Euro dotiert und kommt direkt dem prämierten Projekt zugute. Bei der Auswahl zählen der Beitrag und das persönliche Engagement der Bewerberinnen und Bewerber, die die gesellschaftliche Relevanz des Projektes und seine nachhaltige Wirkung des Projektes sowie die geplante Verwendung des Preisgeldes. Bei der Bewerbung muss ich angeben, wie die 5000 Euro verwendet werden würden. Besonders viele Ideen habe ich derzeit nicht. In der letzten Ausgabe von RadioOSM am 15. Mai (noch nicht veröffentlicht) habe ich in der Hörerrunde am Ende nach Ideen gefragt, aber auch keine tollen Vorschläge erhalten. Folgende Ideen habe ich derzeit: *Mappingparties in abgelegenen Gegenden in Deutschland* In Deutschland gibt es noch immer Gegenden, die sehr schlecht gemappt sind, vor allem im ländlichen Raum, z.B. Frankenwald [3]. Hier würde man mit dem Geld für einige Tage eine Ferienwohnung anmieten und ein paar Mapper, die gerade Zeit haben, würden die Gegend mappen (mit Fokus auf Sachen, die nicht so schnell veralten, denn es gibt dort ja niemanden, der die Daten aktuell hält). Wenn die Ferienwohnung (für 4 Personen) 40 Euro pro Nacht kosten würde, jeder der vier Mapper maximal 100 Euro Fahrtkostenzuschuss erhalten und alle pro Tag einen Essenzuschuss von 15 Euro erhalten würde, würde eine viertägige Mappingparty (5 Übernachtungen) 675 Euro kosten. Man könnte damit also sieben Mappingparties bezahlen. Ein Zuschuss für Mappingparties (z.B. für Getränke) wäre nicht so leicht möglich, da da der Verwendungszweck noch nicht klar feststeht. *Bessere Luftbilder als Bing* In manchen Gegenden in Deutschland sind die Bing-Bilder nicht besonders gut. Sie sind bei tiefstehender Sonne aufgenommen oder haben nur 30 cm Auflösung. Im Jahr 2010 wurde über das Programm Wissenswert von Wikimedia Deutschland der OSM-Community Aerowest-Luftbilder bezahlt [4]. Was haben die Bilder damals gekostet? Wichtig ist, dass solche Luftbilder ohne große Klimmzüge in den Editor einbindbar sein müssen. WMS (TMS muss nicht unbedingt sein) ist also Pflicht. *Schrägluftbilder* Für das 3D-Tagging benötigt man die Anzahl der Stockwerke eines Gebäudes. Man könnte daher auch mit den 5000 Euro (oder einem Teil davon) für gut gemappte Gegenden Schrägluftbilder kaufen, um die dritte Dimension in OSM zu fördern. Falls jetzt jemand meint Ach 3D, das ist Spielrei!, dann sei der mal auf die erste (?) richtige Nutzung von OSM-3D-Daten [5] hingewiesen. Genau so etwas macht sich halt recht schön. *Irgendeinen Serverdienst* Die anderere Idee wäre, irgendeinen Serverdienst des FOSSGIS im OSM-Bereich mit einem leistungsstärkeren Server auszustatten. Ich weiß aber nicht, welche Dienste gerade am Limit laufen und welche Kosten da monatlich anfallen würden (bzw. bis wann man wieder um Spenden bitten müsste). @Sven Geggus: Wie arg ist der deutsche Tileserver ausgelastet? Mit welchen Kosten müsste man monatlich rechnen, wenn man mit den 5000 Euro einen stärkeren Tileserver bezahlen würde? *Schlechte Ideen* Jemanden aus der Community zu bezahlen, damit er das Wiki aufräumt und Übersetzungen synchronisiert, finde ich keine so gute Idee, da es nicht schon vermarktbar ist als eine volle Karte (siehe oben). Man könnte die beiden Ideen auch mischen. Ich glaube nämlich, dass bei der Jury, in der so wie es aussieht, wenig technisch angehauchte Leute sitzen, eine Mappingparty besser ankommt als ein Server für ein paar Nerds (außer es handelt sich um den deutschen Tileserver). Gibt es von eurer Seite noch andere Vorschläge? Es können auch Vorschläge gebracht werden, die die 5000 Euro nur zum Teil ausschöpfen. Viele Grüße Michael [1] http://www.studienstiftung.de/ [2] http://www.studienstiftung.de/stipendiaten/engagementpreis.html [3] http://www.openstreetmap.org/#map=13/50.2445/11.4921 [4] http://meta.wikimedia.org/wiki/WissensWert/40_-_Luftbilder_f%C3%BCr_OpenStreetMap [5] http://interaktiv.morgenpost.de/tempelhofer-feld/ -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] taggen von Schwimmbaedern?
Am 25/mag/2014 um 21:45 schrieb Bernhard Weiskopf bweisk...@gmx.de: Was muss noch als Tag hinzu, damit man die großen Bäder mit vielen Besuchern auf der Karte, z. B. Mapnik, findet? vermutlich solltest Du ein Ticket dafür erstellen, sofern es nicht schon eins gibt. Ich würde nicht das Mapping anpassen sondern das Rendering Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Steinfelder Waschkeller == Lavoir?
Wenn ich das richtig verstanden habe dreht es sich um historische, d.h. nicht mehr benutzte oder nicht mehr benutzbare Objekte. In dem Zusammenhang faellt mireein, dass ich in Finnland zahlreiche Teppichwaschplaetze (in Benutzung) gesehen habe, alle mit Wasser, alle im Freien, alle mit Reihen von Teppichstangen. 2014-05-26 7:41 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 25/mag/2014 um 19:47 schrieb Volker Schmidt vosc...@gmail.com: Washhouse verlangt nach einem Dach. das hatte das ursprünglich beschriebene Objekt auch Gerade heute habe ich ein entsprechendes Objekt in Italien (bei Verona) gefunden, allerdings ohne Dach, aber wesentlich tiefere als die Strasse. anderer tag? evtl ist in dem Bereich Ort zum Waschen von Wäsche ja Platz für mehrere tags? Z.B. gibt es auch moderne Waschsalons. Die haben ggf. auch einen eigenen tag. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
simson.gert...@gmail.com schrieb am 26.05.2014 00:42: osm.org ist nunmal die Hauptseite von OSM, zumindest für Nun ja, beim ARD Bericht war openstreetmap.de die Seite die gezeigt wurde :) OSM-Unkundige. Daher sollten an dieser Stelle meiner Meinung nach auch möglichst alle für den gemeinen User wichtigen Features zu finden sein. routing ist angedacht, hoffe das geht bald online: https://github.com/openstreetmap/openstreetmap-website/pull/716 -- Grüße Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Steinfelder Waschkeller == Lavoir?
Am 26. Mai 2014 09:55 schrieb Volker Schmidt vosc...@gmail.com: Wenn ich das richtig verstanden habe dreht es sich um historische, d.h. nicht mehr benutzte oder nicht mehr benutzbare Objekte. ja, denselben tag wie für einen aktuellen Waschsalon oder eine Wäscherei oder ggf. Großwäscherei (die ersten beiden haben denselben Haupttag, wenn ich das Wiki richtig interpretiere) wird man für einen ehemaligen Waschplatz oder Waschhaus besser nicht benutzen, was ich gemeint hatte war, dass es nicht unbedingt ein tag sein muss, das für alle Arten von (Wäsche)-Waschstellen verwendet wird. Ein Ort ohne Dach, z.B. eine Waschstelle am Fluss, ist nicht unbedingt mit einem entsprechenden Gebäude vergleichbar, auch wenn dort evtl. ähnliche Aktivitäten stattgefunden haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
On Monday 26 May 2014, simson.gert...@gmail.com wrote: [...] 3. Keine Satellitenbilder auf osm.org. Wenn ich persönlich mir einen Punkt auf der Karte anschaue, dann möchte ich mir auch gerne die Satellitenbilder dazu anschauen. Dies ist sicher etwas schwieriger umzusetzen, denn copyrightfreie Satellitenbilder in brauchbarer Auflösung gibt es wohl nicht. Auf OSRM werden jedoch auch die mapbox-Satellitenbilder angezeigt. Wäre das nicht auch für osm.org denkbar oder würde das dem O in OSM zu sehr widersprechen? Andere haben sich hier ja schon kritisch geäußert, ich möchte noch einen anderen Punkt anbringen. Generell sehe ich hochauflösende Luft-/Satellitenbilder für den Kartenbetrachter sehr kritisch. Ein Foto vermittelt prinzipbedingt immer einen Anspruch von Objektivität und Neutralität, der Betrachter denkt in vielen Fällen, dass er durch das Betrachten der Luftbilder vermeidet, das Betrachtete nur durch die Brille des Kartographen zu sehen. Die Bilder sind jedoch nicht in einer Weise aufgenommen und aufbereitet, die diesem Anspruch gerecht wird, die Unterschiede im Aufnahmezeitpunkt (Alter, Jahreszeit, Tageszeit) und Wettereinflüsse bewirken, dass das von den Aufnahmen vermittelte Bild enorm subjektiv und verzerrt ist und die Karte - falls sie denn von guter Qualität ist - viel mehr dem Anspruch der Neutralität gerecht wird. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
On Mon, May 26, 2014 at 08:25:49AM +0200, Johannes wrote: Am 26.05.2014 06:02, schrieb Dirk Sohler: simson.gert...@gmail.com schrieb: 1. Keine fehlertolerante Suchmaschine. … und dabei ist das doch nun wirklich eine der einfachsten Sachen, die man umsetzen kann :/ Ja sehe ich auch so. Idee wäre hier eine Autovervollständigung auf osm.org einzubauen. Sowas gibt es bereits auf Apache Solr-Basis, wobei die Daten aus Nominatim kommen. Siehe koomot.de, da läuft das bereits. Mit solr bekommst du auch ein Meinsten Sie... ? hin. Ich habe hier ein solr für interne zwecken mit anderen Adressdaten am laufen. Ja solr kriegt man gut ans laufen wenn die Ausgangsdatenlage gegeben ist. Fehlertolerant im Sinne von Google ist _SEHR_ schwer. Google bezieht nicht nur das mit ein was du tippst - Sondern auch deine position/land und das was du im Kartenausschnitt siehst und vermutlich noch so einiges mehr. Solr kann autovervollständigung und in maßen auch tippfehler verdauen, aber das ist noch lange nicht die qualität von google maps. Und jetzt kommt noch das ganze preprozessieren dazu. Nominatim schlägt sich da schon relativ gut. Aber das ganze ist viel zu langsam und braucht viel zu viele resourcen. Für den heimuser völlig unmöglich zu benutzen. Ich habe mal angefangen mit dem C++ code von der Geofabik zu spielen mit der der Adress Debug view im OSM Inspector gefüttert wird. Das ganze ist zumindest für Adressen ziemlich brauchbar auch wenn ich auf dem Laptop so mit ach und krach NRW durchgenudelt kriege. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern-Mapping
On Sat, May 24, 2014 at 09:52:16AM +0200, Andre Hinrichs wrote: Moin Moin! In Sachen Hausnummern-Mapping bin ich auf (mindestens) zwei Probleme gestoßen und ich bin mir sicher, dass andere auf die gleichen Probleme gestoßen sind und wüsste gerne, wie diese in der Regel gelöst werden. 1.) Fehlende Hausnummern: Bei meinen Mapping-Touren finde ich sehr häufig Häuser, an denen keine Hausnummern angebracht (oder nicht findbar) sind. Das gilt auch für Häuser, bei denen ich das Grundstück betreten wüsste, um die Hausnummer zu erfahren. Bisher habe ich bei solchen Häusern ein fixme-Tag angebracht und die Hausnummer nicht eingetragen. Nun häufen sich diese fixmes langsam und fangen an zu nerven, da sie nicht wirklich korrigiert werden können. Frage also: Wie geht man damit um? Lösung 1: Die eben genannte fixme-Lösung mit dem Problem, dass sich fixmes langsam häufen. Lösung 2: Einfach (wie bei der Interpolation) raten und eintragen und gut is. Lösung 3: Einen Knoten setzen und eine addr:interpolation-Linie verwenden. (Was macht man dann mit Hausnummern wie 4a, 5c usw.?) Lösung 4: Dem Hausbesitzer eine Nachricht zukommen lassen, dass er doch bitte eine Hausnummer anbringen möchte. Diese Lösung favorisiere ich derzeit, bastele jedoch noch an der Formulierung und weiß auch nicht, ob das so OK wäre. Lösung 5: Gleich dem Ordnungsamt Bescheid geben. Das fände ich schon böse... Lösung 6: Etwas, woran ich noch nicht gedacht habe. Ich habe das auch mit den Fixmes gemacht und bin jetzt in NRW ja in der Luxuriösen Lage Mal im ALK spicken zu dürfen. Damit kriegt man die Lücken ja gefüllt. Ich würde so weitermachen und irgendwann findet sich ein weg die fixes alle abzuarbeiten. 2.) Interpolation mit Häusern: Das addr:interpolation-Tag (odd oder even oder all) kann nur mit Nodes verwendet werden. Wenn Häuser jedoch als Gebäude eingetragen sind, kann dieses Tag nicht verwendet werden (oder doch?), da man keine Linie zwischen zwei Gebieten ziehen kann. Z.B. in Clausthal-Zellerfeld meldet der housenumer validator deshalb einige Fehler, die aus diesem Problem resultieren. Daher meine Frage, was ihr von einer interpolation-Relation halten würdet. Dort könnten dann auch Gebäude als Start- oder End-Punkt herhalten. Würde ich lassen. Die verwerter interpolieren auch ohne einen interpolation way schon sehr gut. Ist IMHO wirklich nur Datenmüll. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern-Mapping
On Sat, May 24, 2014 at 10:27:19AM +0200, Andreas Neumann wrote: Das klingt böse, wäre aber der korrekte Weg. Zumal ich die verdutzten Gesichter im Ordnungsamt sehen möchte :D. Warum der korrekte Weg? Bei vielen Komunen ist es in einer Verordnung geregelt, dass jedes Grundstück eine von außen gut sichtbare Hausnummer haben muss. Leider halten sich, insbesondere auf den Vororten (wo doch jeder weiß, dass hier Nummer X ist), recht viele nicht an diese Anordnung. Die wundern sich nur das beim ableben der Rettungswagen 10 Minuten später kommt ;) Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] taggen von Schwimmbaedern?
vermutlich solltest Du ein Ticket dafür erstellen, sofern es nicht schon eins gibt. Ich würde nicht das Mapping anpassen sondern das Rendering https://github.com/gravitystorm/openstreetmap-carto/issues/370 __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 00:42, schrieb simson.gert...@gmail.com: Es ist richtig, OSM schneidet insgesamt recht gut ab. Die Reportage spricht jedoch genau die 3 großen Probleme an, die ich persönlich auch als Gründe sehe, warum OSM im Desktop-Bereich derzeit keine Chance hat sich großflächig durchzusetzen. Das Problem ist nicht technischer Natur, sondern zum Teil durch Konflikte in den Zielen und auch finanziell bedingt. Ob das von Anfang an so gedacht war oder nicht, jetzt ist OSM vor allem ein Datensammel und nicht ein wir machen jetzt google Konkurrenz Projekt. Als Folge ist auch openstreetmap.org nicht primär als noch ein weiteres Kartenportal gedacht, sondern eher als Werkzeug für die Beitragenden ans Projekt. Mindestens eine zeit lang war die Idee sicher auch, dass irgendein grosser Marktteilnehmer die OSM Daten nehmen würde und den google Konkurrenten damit bauen würde. Bis jetzt hat das niemand wirklich ernsthaft versucht, und ich halte es auch für eher unwahrscheinlich, dass das je ein Dritter machen wird, die Kartendaten sind nun mal das kleinste Problem für einen google Mitbewerber. Aber wer weiss, vielleicht versucht es DuckDuckGo doch. Die andere Seite davon ist das es durchaus kleinere Spieler im OSM Umfeld gibt, die solche Kartenportale anbieten, MapQuest, Skobbler, und natürlich auch die vielen an Spezialinteressen orientierten Sites. Dort ist eher das Problem, dass die im Raum zwischen uns und google überleben müssen und jedes mal wenn wir ein Feature auf osm.org freischalten, wir das Leben für solche Unternehmungen schwieriger machen. 1. Keine fehlertolerante Suchmaschine. Man ist da inzwischen durch 2. Kein guter Router. OSRM gefällt mir schon sehr gut, bietet jedoch nur Wie schon von anderen geschrieben: Routing wird wohl demnächst auf osm.org verfügbar sein. Ob eine fehlertolerante Suche sehr viel Sinn macht wenn man von der Sache her eher Fehler entdecken will, lass ich mal aussen vor, technisch muss noch etwas an photon gearbeitet werden, damit es tatsächlich als mehrsprachiges und aktuelles Frontend zu nominatim angeboten werden kann, denke aber das ist absehbar. 3. Keine Satellitenbilder auf osm.org. Wenn ich persönlich mir einen Punkt auf der Karte anschaue, dann möchte ich mir auch gerne die Satellitenbilder dazu anschauen. Dies ist sicher etwas schwieriger umzusetzen, denn copyrightfreie Satellitenbilder in brauchbarer Auflösung gibt es wohl nicht. Auf OSRM werden jedoch auch die mapbox-Satellitenbilder angezeigt. Wäre das nicht auch für osm.org denkbar oder würde das dem O in OSM zu sehr widersprechen? Es gibt global, frei verfügbar, im Augenblick nur Aufnahmen von Landsat die bis ca. 15m/pixel auflösen. Regional gibt es natürlich schon zusätzliche bessere offene Quellen, wir sind aber sehr sehr weit davon weg da global was anbieten zu können. Wikimedia De hat mal ein, etwas eingeschlafenen, Versuch gestartet was zu machen, siehe http://opengeoserver.at/ . Ich habe deshalb vor ein paar Wochen mal bei der WMF angeregt doch vielleicht zusammen mit uns das weiterzuführen, oder ganz neu zu starten, ob daraus was wird steht in den Sternen. Die Bilder von Mapbox, stammen genau so wie die von Bing, von Digital Globe und können nicht als Layer für normale Dienste verwendet werden (resp. man kann schon, es kostet einfach Geld), sondern nur als Hintergrund zum editieren. Simon signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26. Mai 2014 11:15 schrieb Simon Poole si...@poole.ch: Die andere Seite davon ist das es durchaus kleinere Spieler im OSM Umfeld gibt, die solche Kartenportale anbieten, MapQuest, Skobbler, und natürlich auch die vielen an Spezialinteressen orientierten Sites. kleiner als Google sind die beiden genannten natürlich schon, was auch nicht schwer ist, da Google mit rund 5 Beschäftigten, 111 Mld Assets und 60 Mld. $ Umsatz zu den größten Firmen überhaupt gehört, aber kleine Spieler sind die genannten auch nicht, vor allem seit Skobbler von Telenav gekauft wurde (und Mapquest vor längerem von AOL). (Für Mittelstand qualifizieren sich weder AOL noch Telenav). Vor allem aber sind das keine Community-Unternehmungen, wo man sich inhaltlich einbringen könnte, oder wo es irgendeine Art von Sicherheit gäbe, dass man deren Services auch in Zukunft noch nutzen kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 05/26/2014 10:50 AM, Florian Lohoff wrote: Google bezieht nicht nur das mit ein was du tippst - Sondern auch deine position/land und das was du im Kartenausschnitt siehst und vermutlich noch so einiges mehr. Leute mit ähnlichen Essensvorlieben wie Sie haben in der Vergangenheit meistens X gemeint, wenn sie Y tippten... Solr kann autovervollständigung und in maßen auch tippfehler verdauen, aber das ist noch lange nicht die qualität von google maps. Ich glaube auch, wer immer in diesem Thread geschrieben hat, dass eine fehlertolerante Suche wohl doch das einfachste von der Welt sei, hatte einen Smiley vergessen. Ich habe mal angefangen mit dem C++ code von der Geofabik zu spielen mit der der Adress Debug view im OSM Inspector gefüttert wird. Das ganze ist zumindest für Adressen ziemlich brauchbar auch wenn ich auf dem Laptop so mit ach und krach NRW durchgenudelt kriege. Ich glaube, RAM-maessig kann man da noch was sparen, wenn man auf drei statt zwei Einlesevorgänge umstellt. Dann kriegst Du vielleicht auch irgendwann Deutschland durchgenudelt ;) Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTgyr0AAoJEOx/uhGAJu9HOF4H/0diJE3/1Y8/QJZEBzsPYmmM laic0ImdwZdio8uzAIJ4ax6fss+GK9ETdn+A0KEAbma4wW5mQws5PxYWhC30LhJp rAzckt3haBYVTqgVcY5BHjRpc3VvekhxtdCiAeyBbq5EkC7LceCxd1WjJqOwDoVG zQG/uUjDdTvxgWXkTLrO76nbk5V9sjyPrmQUVKUPKiIzTLKBzpnfEggFLnT/iSD+ mmdsPUH7yXhv6LC27IdOvMhXbYDy37UDBQTa+6EyBXhiBLbIQzp6m4ZKAJdRQxHu qlArsp1YRXdM/XwKolDxAhUKIVkntkxvgCPjT7VAr6yzHHTDp6l2XIe2Ba1Gmow= =yLmG -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Ich habe mal angefangen mit dem C++ code von der Geofabik zu spielen mit der der Adress Debug view im OSM Inspector gefüttert wird. Das ganze ist zumindest für Adressen ziemlich brauchbar auch wenn ich auf dem Laptop so mit ach und krach NRW durchgenudelt kriege. Ich glaube, RAM-maessig kann man da noch was sparen, wenn man auf drei statt zwei Einlesevorgänge umstellt. Dann kriegst Du vielleicht auch irgendwann Deutschland durchgenudelt ;) Diese View habe ich ja verbrochen... Mit ein Grund weshalb das Ding viel RAM benötigt ist, dass die Positionen _aller_ Nodes beim Einlesen der Datei zwischengespeichert werden. Das macht die Programmierung einfacher: Beim Verarbeiten von Ways hat man so gleich Zugriff auf die Node-Positionen, nicht nur auf die IDs der Nodes. Möchte man das RAM-mässig schlanker machen, könnte man, wie von Frederik vorgeschlagen, am Anfang des Programms einen weiteren Durchlauf einführen, der notiert, von welchen IDs man die Koordinaten benötigt. Im nächsten Durchlauf würde man dann nicht alle Node-Koordinaten speichern, sondern nur die Koordinaten der Nodes mit den notierten IDs. Aber wir schweifen vom Thema ab... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Hoi Simon, Das Problem ist nicht technischer Natur *OpenStreetMap - die freie Weltkarte* so hiess unser OSM-Slogan früher. Irgendwann wurde aus der Weltkarte dann eine Geo-Datenbank... Für mich sind beides gegenabhängige Aspekte: - Daten werden nur sichtbar durch Kartografie (bzw durch Routing und andere grafische Darstellungen) - Kartografie basiert immer auf Daten. jetzt ist OSM vor allem ein Datensammel Projekt. Ich treffe vorwiegend Nutzer, die an *Karten* interessiert sind. /Dafür/ sammeln sie Daten (und arbeiten an Programmen und Taggingschemen). OSM ohne Karte wäre wie Wikipedia ohne Website ;-) Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 14:33, schrieb Markus: Hoi Simon, Das Problem ist nicht technischer Natur *OpenStreetMap - die freie Weltkarte* so hiess unser OSM-Slogan früher. Irgendwann wurde aus der Weltkarte dann eine Geo-Datenbank... Es ist nicht verboten dazu zu lernen und die Realität anzuerkennen, der Spruch war wohl immer falsch. Für mich sind beides gegenabhängige Aspekte: - Daten werden nur sichtbar durch Kartografie (bzw durch Routing und andere grafische Darstellungen) - Kartografie basiert immer auf Daten. Man kann natürlich alles als Karte definieren :-) jetzt ist OSM vor allem ein Datensammel Projekt. Ich treffe vorwiegend Nutzer, die an *Karten* interessiert sind. /Dafür/ sammeln sie Daten (und arbeiten an Programmen und Taggingschemen). Angesichts davon, dass es in diesem Thread gerade um die nicht-Karten Features geht die google hat und OSM nicht. eine mutige Aussage. OSM ohne Karte wäre wie Wikipedia ohne Website ;-) Wikipedia muss jetzt auch mit google als vermutlich grössten Distributionskanal für ihre Daten zurechtkommen. Simon signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 11:15, schrieb Simon Poole: Ob eine fehlertolerante Suche sehr viel Sinn macht wenn man von der Sache her eher Fehler entdecken will, lass ich mal aussen vor,... Ich sehe osm.org schon eher als Anwederseite. Um Fehler aufzuspüren gibt es doch Qualitätssicherungsseiten wie keepright, geofabrik osmi,... Außerdem, wenn man München eintippt und es wird nicht München angezeigt, sondern Meinten Sie Münschen, kann man ja trotzdem weiterhin den Tippfehler in den OSM-Daten entdecken und korrigieren wenn man das möchte. Die Bilder von Mapbox, stammen genau so wie die von Bing, von Digital Globe und können nicht als Layer für normale Dienste verwendet werden (resp. man kann schon, es kostet einfach Geld), sondern nur als Hintergrund zum editieren. OK, Satellitenbilder direkt auf osm.org ist wohl tatsächlich eher unangebracht. Sehe ich ein. VG Klumbumbus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 13:52, schrieb Frederik Ramm: Solr kann autovervollständigung und in maßen auch tippfehler verdauen, aber das ist noch lange nicht die qualität von google maps. Ich glaube auch, wer immer in diesem Thread geschrieben hat, dass eine fehlertolerante Suche wohl doch das einfachste von der Welt sei, hatte einen Smiley vergessen. Ich glaube es hat niemand behauptet, dass eine fehlertolerante Suchmaschine einfach umzusetzen wäre. Ich denke da sind wir uns alle einig. Hilfreich wäre eine solche meiner Meinung aber schon. Es muss ja auch nicht gleich google-Qualität haben. Das ist angesichts u.a. des finanziellen Hintergrundes wohl in Absehbarer Zeit nicht zu schaffen. VG Klumbumbus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 16:55, schrieb simson.gert...@gmail.com: ... Ich glaube es hat niemand behauptet, dass eine fehlertolerante Suchmaschine einfach umzusetzen wäre. Ich denke da sind wir uns alle einig. Hilfreich wäre eine solche meiner Meinung aber schon. Es muss ja auch nicht gleich google-Qualität haben. Das ist angesichts u.a. des finanziellen Hintergrundes wohl in Absehbarer Zeit nicht zu schaffen. Ich wüsste jetzt nicht von einem Projekt für osm.org, dass je an den finanziellen Mitteln gescheitert ist, am Willen tatsächlich was zu machen, ja daran scheitern viele. Für das Beispiel von oben wäre es sicher möglich Mittel zu bekommen, siehe z.B. Mapbox und iD (die Knight Foundation hat letzthin ausdrücklich mehr Projektvorschläge aus dem OSM Umfeld gewünscht). Simon signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 17:40, schrieb Simon Poole: Ich wüsste jetzt nicht von einem Projekt für osm.org, dass je an den finanziellen Mitteln gescheitert ist, am Willen tatsächlich was zu machen, ja daran scheitern viele. ACK! Ein Hinweis wenn wir speziell über Deutschland (bzw. generell den deutschsprachigen Raum) reden: beim FOSSGIS e.V. gibt es auch Geldmittel. Es muss sich nur jemand bereit finden, das Thema inhaltlich anzugehen und vor allem eine Aussicht auf erfolgreichen Abschluss bieten. Das bedeutet für die Finanzierung: beim FOSSGIS einen sinnvollen und aussagekräftigen Projekt-/Förderantrag zu stellen. Wenn es gute Ideen gibt werden diese im Allgemeinen mit viel Wohlwollen bewertet. Ein positives Beispiel: Roland mit der Overpass-API (soll bedeuten: die Kosten für den Server, welche der FOSSGIS eV für mehrere Jahre zugesichert hat)... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
On 24/05/14 21:25, Andreas Goss wrote: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-100.html ## Direktlinks: Alternativen zu Google-Maps: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-106.html Deeplink: Open Source: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-110.html Sind die Videos noch irgendwo verfügbar? Konnte sie mir mangels Breitbandverbindung bisher leider nicht ansehen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 19:24, schrieb Thorsten Alge: On 24/05/14 21:25, Andreas Goss wrote: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-100.html ## Direktlinks: Alternativen zu Google-Maps: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-106.html Deeplink: Open Source: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-110.html Sind die Videos noch irgendwo verfügbar? Konnte sie mir mangels Breitbandverbindung bisher leider nicht ansehen. ttps://lists.openstreetmap.org/listinfo/talk-de Die Links funktionieren noch. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
On 26/05/14 19:31, simson.gert...@gmail.com wrote: Sind die Videos noch irgendwo verfügbar? Konnte sie mir mangels Breitbandverbindung bisher leider nicht ansehen. ttps://lists.openstreetmap.org/listinfo/talk-de Die Links funktionieren noch. Also beim mir wird angezeigt „Das Video kann leider nicht abgespielt werden.“ und darunter „ Video verfügbar bis 24.05.2015“. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 26.05.2014 20:20, schrieb Thorsten Alge: Also beim mir wird angezeigt „Das Video kann leider nicht abgespielt werden.“ und darunter „ Video verfügbar bis 24.05.2015“. Dann schau dir nochmal genau die Jahreszahl in dem Datum an, ich war auch erst verwirrt ;) Bei mir laufen die videos. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
On 05/24/2014 09:25 PM, Andreas Goss wrote: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-100.html Die Kritik mit nicht existenten Wegen kann ich nachvollziehen. Hier und da herrscht doch etwas der Drang dazu zu viel einzutragen. Derjenige, der da langgelaufen ist, erinnert sich am Ende seiner Wandertour möglicherweise nicht mehr das er sich nicht auf einem richtigen Weg befunden hat. Oder jemand lädt ein GPS-Log hoch das eine Spur zeigt für die es keinen richtigen Weg gibt. Hier ist man auf Ortskundige angewiesen, die ihre Wege kennen und einen Weg, der komisch zu sein scheint, notfalls vor Ort prüfen und wenn nötig direkt wieder raushauen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-in] GeoBLR June Meetup.
I'll try to attend... If I don't have duty. Meanwhile.. A similar progress video of Bangalore I made.. Mapping Bangalore - Openstreetmap progress Timeline…: http://youtu.be/fpHKb-SZRh8 Sent from my Nexus 5 On May 26, 2014 2:48 PM, Arun Ganesh arun.plane...@gmail.com wrote: Wish I could attend, but I'm in Bangalore only at the end of June, early July. On a related note, here is a short animation showing the mapping progress of Bangalore over the years: http://4thmain.github.io/projects/osm/bangalore-mapping.html We sure have come a long way from the historic year of 2008 when Mikel and Schuyler did their freemap India tour. On Mon, May 26, 2014 at 8:12 AM, Sajjad Anwar m...@sajjad.in wrote: Hello everyone, Just wanted to announce our June meetup. June 5th, 6pm - 8pm at the Center for Internet and Society, Bangalore. In this edition, we thought it would be nice to spend couple of hours editing OpenStreetMap and fixing things specific to Bangalore to begin with. We will also do a quick introduction to OpenStreetMap editing and concepts. And there will be chai and samosas! More details and RSVP on the meetup page - http://www.meetup.com/GeoBLR/events/185031242/ Hope to see you some of you there! Cheers, Sajjad. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Arun Ganesh (planemad) ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] Servizio per Ottimizzare automaticamente tracciati GPX/KML online!
2014-05-24 22:32 GMT+02:00 Stefano Cudini stefano.cud...@gmail.com: ho appena realizzato un semplice servizio per ottimizzare tracce GPX/KML riducendo il numero di punti senza perdere qualita della traccia. Si, l'algoritmo Douglas-Peucker è ben noto, c'è anche un'implementazione all'interno di JOSM (simplify way). Il problema è che non è vero che non si perde la qualità della traccia, in situazioni con angoli molto stretti (tornanti e simile) si perde la forma della way, e in generale si perde l'informazione sulla qualità della traccia (non si vede più se la ricezione durante la registrazione della traccia era buona o cattiva). Personalmente preferisco tracce più grezze possibili (intendo inalterate rispetto a quello che il GPS ha registrato) per lavorare in OSM, ma ciò richiede che spegni la registrazione ogni volta che ti fermi (per evitare le nuvole), cosa non è commodo con tutti i gps (il vecchio 60Csx lo fa bene, ma il modello successivo 62... non te la fa più fare in maniera commoda). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] aggiornato geocoder osm
http://www.apposta.biz/prove/geo.php ora basta fare l'upload di qualsiasi file csv con gli indirizzi nella prima colonna. aggiornato anche github https://github.com/piersoft/GeocoderCSV2OSM ditemi come va per favore. Francesco Piero Paolicelli TW: @piersoft STORE: GooglePlay/AppStore WWW: www.apposta.biz Sorry for typos, sent by mobile. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Servizio per Ottimizzare automaticamente tracciati GPX/KML online!
Il giorno 26 maggio 2014 12:52, Martin Koppenhoefer dieterdre...@gmail.comha scritto: 2014-05-24 22:32 GMT+02:00 Stefano Cudini stefano.cud...@gmail.com: ho appena realizzato un semplice servizio per ottimizzare tracce GPX/KML riducendo il numero di punti senza perdere qualita della traccia. Si, l'algoritmo Douglas-Peucker è ben noto, c'è anche un'implementazione all'interno di JOSM (simplify way). Il problema è che non è vero che non si perde la qualità della traccia, in situazioni con angoli molto stretti (tornanti e simile) si perde la forma della way, e in generale si perde l'informazione sulla qualità della traccia (non si vede più se la ricezione durante la registrazione della traccia era buona o cattiva). Si in effetti hai ragione... ma diciamo che per i non addetti ai lavori... passare da una traccia che pesa 1MB ogni 100 metri a 1KB ogni 100 metri... direi che non ce molta perdinta di informazione utile.. soprattutto per quanto riguarda il mapping su OSM. Comunque a differenze di JOSM.. la cosa utile di questa app è che tramile lo slider si può regolare facilmente la qualita finale del tracciato!(cioè il fattore di approssimazione dell'algoritmo) Cosa che trovo molto molto utile in certi casi.. per questo l'ho creato! Personalmente preferisco tracce più grezze possibili (intendo inalterate rispetto a quello che il GPS ha registrato) per lavorare in OSM, Io siceramente credo che su OSM si debba invece ponderare bene la qualita senza aggiungere dati inutili... se tutti cominciassero a mappare col massimo della precisione possibile.. i server OSM imploderebbero dopo poco! e tutti i servizi collegati sarebbero molto piu lenti(overpass). Poi cmq mi sembra di aver notato che OSM stesso dopo qualche tempo tende ad eliminare in automatico nodi non indispensabili dai tracciati, probabilmente usando lo stesso algoritmo, ma di questo non sono sicuro, ho solo visto che tracce che ho aggiunto anni fa... e che nessun altro ha modificato oggi risultano con molti meno nodi. ma ciò richiede che spegni la registrazione ogni volta che ti fermi (per evitare le nuvole), cosa non è commodo con tutti i gps (il vecchio 60Csx lo fa bene, ma il modello successivo 62... non te la fa più fare in maniera commoda). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Servizio per Ottimizzare automaticamente tracciati GPX/KML online!
2014-05-26 18:44 GMT+02:00 Stefano Cudini stefano.cud...@gmail.com: Si in effetti hai ragione... ma diciamo che per i non addetti ai lavori... passare da una traccia che pesa 1MB ogni 100 metri a 1KB ogni 100 metri... direi che non ce molta perdinta di informazione utile.. soprattutto per quanto riguarda il mapping su OSM. io lo vedrei al contrario, quando devi presentare una traccia (per esempio in un app, o su web) utilizzerei questo sistema per risparmiare spazio e per ottenere un risultato apparentemente più pulito, mentre per la mappatura penso sia contraproduttivo. Comunque a differenze di JOSM.. la cosa utile di questa app è che tramile lo slider si può regolare facilmente la qualita finale del tracciato!(cioè il fattore di approssimazione dell'algoritmo) Cosa che trovo molto molto utile in certi casi.. per questo l'ho creato! si, bello :) Io siceramente credo che su OSM si debba invece ponderare bene la qualita senza aggiungere dati inutili... se tutti cominciassero a mappare col massimo della precisione possibile.. i server OSM imploderebbero dopo poco! e tutti i servizi collegati sarebbero molto piu lenti(overpass). va fatto distinzione tra dati (osm) e tracce (non sono proprio dati osm, anche se raccolte dallo stesso progetto non pesano sul database o su overpass). Poi cmq mi sembra di aver notato che OSM stesso dopo qualche tempo tende ad eliminare in automatico nodi non indispensabili dai tracciati, probabilmente usando lo stesso algoritmo, ma di questo non sono sicuro, ho solo visto che tracce che ho aggiunto anni fa... e che nessun altro ha modificato oggi risultano con molti meno nodi. Con tracce intendi tracce GPX, come visibili qui: http://www.openstreetmap.org/traces ? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Servizio per Ottimizzare automaticamente tracciati GPX/KML online!
Il giorno 26 maggio 2014 19:04, Martin Koppenhoefer dieterdre...@gmail.comha scritto: 2014-05-26 18:44 GMT+02:00 Stefano Cudini stefano.cud...@gmail.com: Con tracce intendi tracce GPX, come visibili qui: http://www.openstreetmap.org/traces ? Ah no no intendevo proprio le highway presenti nel db di OSM, le gpx credo che non vengano modificate.. mentre invece i tracciati che ho modificato molto tempo fa se li riguardo oggi spesso ho notato una maggiore approssimazione infatti spesso altri tratti li ho dovuto riaggiustare! ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Tag per Bottega Solidale
A Genova c'è una nota aperta con la segnalazione di una Bottega Solidale http://www.bottegasolidale.it/wordpress/chi-siamo Vendono un pò di tutto, dal cibo ai vestiti all'artigianato, all'insegna del commercio equo e solidale. Quale tag usare? Grazie Alessandro Ale_Zena_IT ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag per Bottega Solidale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 26/05/2014 19:47, Alessandro ha scritto: A Genova c'è una nota aperta con la segnalazione di una Bottega Solidale http://www.bottegasolidale.it/wordpress/chi-siamo Vendono un pò di tutto, dal cibo ai vestiti all'artigianato, all'insegna del commercio equo e solidale. Quale tag usare? Grazie Alessandro Ale_Zena_IT Sulla base della wiki, direi shop=charity http://wiki.openstreetmap.org/wiki/Tag:shop%3Dcharity - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlODf0gACgkQoVS0hKoD3PP1pgD/XPn18aiihuda9RZKCPLCnoNd rDR1Rv4d8seHojO71t8A/0ES/oLzPvBXr6DP4hDvWLMOB1E52m4VEJExylfmeedj =/rAQ -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-at] ÖPNV-Mapping und aufgetrennte Straßen = NOT FUNNY!
FRUST Ich hab das Auftrennen von Straßen in zwei Richtungsfahrbahnen noch nie gemocht, und seit ich ÖPNV-Mapping betreibe, finde ich es noch weniger lustig. In den vergangenen Tagen hab ich mich verstärkt dem Mappen von Buslinien gewidmet, und ich war manchmal nahe dran, aufgetrennte Straßen zu löschen und wieder als nur eine Linie einzuzeichnen. Die Auftrennung schaut auf der Karte bescheuert aus, weil da plötzlich zwei Einbahnen sind, wo eigentlich nur eine Straße ist. An manchen Kreuzungen sind jetzt mehrere Ampeln eingezeichnet, wo eigentlich nur eine hängt. Router liefern plötzlich an Kreuzungen falsche Ergebnisse (wo vorher alles korrekt war). Für eine Haltestelle, wo Straßenbahn und Buslinien halten, muß ich jetzt getrennte Haltestellen einzeichnen, weil erstens die Gleise von der Straße getrennt sind, und dann auch noch die Fahrbahnen in Richtungsfahrbahnen aufgetrennt wurden. CRAZY! GEHT'S NOCH? Ich finde, diejenigen, die Straßen auftrennen, sollten dann auch die Buslinien mappen müssen, die darüber fahren. Dann würden sie sehen, was das für Umstände macht. UND: Die OpenStreetMap ist NICHT Malen nach Zahlen! Eine Landkarte ist ein symbolisches Abbild der Welt. Wenn ich ein realistisches Abbild der Welt will, kann ich gleich ein Satellitenfoto oder eine Luftaufnahme verwenden. /FRUST So, das mußte ich jetzt los werden. LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ÖPNV-Mapping und aufgetrennte Straßen = NOT FUNNY!
On 26.05.14 11:10, Christian Aigner wrote: ich war manchmal nahe dran, aufgetrennte Straßen zu löschen und wieder als nur eine Linie einzuzeichnen. Also ich verstehe Deinen Frust (weil ich ihn auch schon hatte) und unterstütze das. Wobei ich's nicht löschen würde, sondern möglichst den alten Way reaktivieren (und ent-einbahnen) würde). Die Breitenfurter Straße vor der Altmannsdorfer Straße hatte ich Dir ja auf Video gezeigt, das ist für mich so ein typisches Beispiel von null baulicher Trennung (nicht mal Stuttgarter Schwellen). Einzig Straßenbahngleise würde ich lassen, die sind halt eine eigene Welt und da gibt's praktisch keine Interaktion mehr mit Wegen (im Sinne von Straßen oder Fußwegen etc). Bei Straßenbahnhaltestellen ist die stop_position auf dem Gleis, bei Bushaltestellen ist die stop_position auf der Straße. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ÖPNV-Mapping und aufgetrennte Straßen = NOT FUNNY!
On Mon, May 26, 2014 at 11:10:51AM +0200, Christian Aigner wrote: FRUST Für eine Haltestelle, wo Straßenbahn und Buslinien halten, muß ich jetzt getrennte Haltestellen einzeichnen, weil erstens die Gleise von der Straße getrennt sind, und dann auch noch die Fahrbahnen in Richtungsfahrbahnen aufgetrennt wurden. CRAZY! UND: Die OpenStreetMap ist NICHT Malen nach Zahlen! Eine Landkarte ist ein symbolisches Abbild der Welt. /FRUST Meine voll Zustimmung. Wenn die Fahrbahnen baulich getrennt sind, dann finde ich auch eine Auftrennung in den Daten sinnvoll ... sonst nicht. Zu den Strassenbahnen: Ich finde auch, dass es syntaktisch etwas anderes ist, ob Strassenbahngleise AUF der Fahrbahn sind (typischer Fall von highway=* railway=tram tracks=2) oder neben, sprich ein getrennter Gleiskörper. Da ich persönlich ja mehr im Rendering als im Mapping beschäftigt bin, muss ich auch sagen, dass das ziemlich arge Auswirkungen hat. Z.B. kann ich nicht mehr sagen, auf der Straße X fahren Linie A und B in beide Richtungen. Nein, ich muss drei oder mehr verschiedene Linien zeichnen - das macht auch das Ergebnis unübersichtlich. Theoretisch könnte man noch per Abstandsmessungen sagen: ok, die Gleise sind so knapp, dass sie wohl auf der Straße liegen und dies zusammenfassen, in der Praxis ist das aber nicht durchführbar und fehleranfällig. Um ehrlich zu sein hab ichs nie probiert, aber in Gedanken bin ichs schon 100mal durchgegangen, wie man das machen könnte. Als ich in meiner Gegend entdeckt hatte, wie ein User die Fahrbahn und die Straßenbahngeleise aufgetrennt hat, hab ich ihm geschrieben und versucht ihn davon abzuhalten - natürlich zwecklos. Inzwischen ist ja fast ganz Wien schon so verunstaltet worden ... gruesse, Stephan PS: Apropos Micromapping - letztens ist mir aufgefallen, dass viele Öffi-Wartehäuseln inzwischen nicht nur als Node mit amenity=shelter eingetragen sind, sondern (zusätzlich!) als Fläche mit building=roof. PPS: Ein paar Parks in Wien wurden ja vor einiger Zeit schon in viele kleine Parks (durch die Parkwege getrennt) aufgeteilt - sogar ohne Name, ohne zusammenfassende Relation. Sprich: Total falsch. Ein paar dieser Parks hab ich wieder in einzelne Flächen zurückverwandelt - dafür (wieder) mit Name und Link zu Wikipedia. PPPS: Von wegen Malen nach Zahlen: Schaut auch mal den Belvederegarten an: http://osm.org/go/0JrIZnNa -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Bösch-Plepelits,| | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at | | Twitter: twitter.com/plepe Jabber: sk...@jabber.at | `-' ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ÖPNV-Mapping und aufgetrennte Straßen = NOT FUNNY!
Zu dem Thema bitte auch die aktuelle Diskussion auf der talk-transit Liste beachten. MfG, LH -Ursprüngliche Nachricht- Gesendet: Montag, 26 Mai 2014 um 15:52:22 Uhr Von: Stephan Bösch-Plepelits sk...@xover.htu.tuwien.ac.at An: OpenStreetMap AT talk-at@openstreetmap.org Betreff: Re: [Talk-at] ÖPNV-Mapping und aufgetrennte Straßen = NOT FUNNY! On Mon, May 26, 2014 at 11:10:51AM +0200, Christian Aigner wrote: FRUST Für eine Haltestelle, wo Straßenbahn und Buslinien halten, muß ich jetzt getrennte Haltestellen einzeichnen, weil erstens die Gleise von der Straße getrennt sind, und dann auch noch die Fahrbahnen in Richtungsfahrbahnen aufgetrennt wurden. CRAZY! UND: Die OpenStreetMap ist NICHT Malen nach Zahlen! Eine Landkarte ist ein symbolisches Abbild der Welt. /FRUST Meine voll Zustimmung. Wenn die Fahrbahnen baulich getrennt sind, dann finde ich auch eine Auftrennung in den Daten sinnvoll ... sonst nicht. Zu den Strassenbahnen: Ich finde auch, dass es syntaktisch etwas anderes ist, ob Strassenbahngleise AUF der Fahrbahn sind (typischer Fall von highway=* railway=tram tracks=2) oder neben, sprich ein getrennter Gleiskörper. Da ich persönlich ja mehr im Rendering als im Mapping beschäftigt bin, muss ich auch sagen, dass das ziemlich arge Auswirkungen hat. Z.B. kann ich nicht mehr sagen, auf der Straße X fahren Linie A und B in beide Richtungen. Nein, ich muss drei oder mehr verschiedene Linien zeichnen - das macht auch das Ergebnis unübersichtlich. Theoretisch könnte man noch per Abstandsmessungen sagen: ok, die Gleise sind so knapp, dass sie wohl auf der Straße liegen und dies zusammenfassen, in der Praxis ist das aber nicht durchführbar und fehleranfällig. Um ehrlich zu sein hab ichs nie probiert, aber in Gedanken bin ichs schon 100mal durchgegangen, wie man das machen könnte. Als ich in meiner Gegend entdeckt hatte, wie ein User die Fahrbahn und die Straßenbahngeleise aufgetrennt hat, hab ich ihm geschrieben und versucht ihn davon abzuhalten - natürlich zwecklos. Inzwischen ist ja fast ganz Wien schon so verunstaltet worden ... gruesse, Stephan PS: Apropos Micromapping - letztens ist mir aufgefallen, dass viele Öffi-Wartehäuseln inzwischen nicht nur als Node mit amenity=shelter eingetragen sind, sondern (zusätzlich!) als Fläche mit building=roof. PPS: Ein paar Parks in Wien wurden ja vor einiger Zeit schon in viele kleine Parks (durch die Parkwege getrennt) aufgeteilt - sogar ohne Name, ohne zusammenfassende Relation. Sprich: Total falsch. Ein paar dieser Parks hab ich wieder in einzelne Flächen zurückverwandelt - dafür (wieder) mit Name und Link zu Wikipedia. PPPS: Von wegen Malen nach Zahlen: Schaut auch mal den Belvederegarten an: http://osm.org/go/0JrIZnNa -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Bösch-Plepelits,| | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at | | Twitter: twitter.com/plepe Jabber: sk...@jabber.at | `-' ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ÖPNV-Mapping und aufgetrennte Straßen = NOT FUNNY!
Am 26.05.2014 18:16, schrieb Stephan Bösch-Plepelits: On Mon, May 26, 2014 at 06:10:04PM +0200, liberalerhuman...@gmx-topmail.de wrote: Zu dem Thema bitte auch die aktuelle Diskussion auf der talk-transit Liste beachten. Meinst Du das hier? https://lists.openstreetmap.org/pipermail/talk-transit/2014-May/001736.html Das ist vollkommen unrelated, weil es ja um das Aufsplitten in Segmente geht, also sprich eine Straße wird nur auf der ersten Hälfte von einer Linie befahren, danach biegt sie ab. Das gleiche bei Wechseln in der Einbahn und so. Das, was Christian meint ist aber das Aufsplitten der Fahrspuren bzw. Schienenstränge in Längsrichtung. Stimmt, das hab ich gemeint. Beim ÖPNV-Mapping werden zwangsläufig die Straßen in kleinere Teilstücke (an Weggabelungen bzw. -kreuzungen) getrennt, damit man die Route erstellen kann. Das ist normal und behindert in keinster Weise. Die Aufsplittung in Längsrichtung ist dagegen ein richtiger PITA (pain in the ass). LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cat] Renderitzador o encaminador
Més adient per què? Són coses diferents. El renderitzador crea una imatge a partir d'unes dades digital. Per exemple, fa un mapa raster (imatge de puntets de colors) a partir d'un mapa vectorial (punts i ratlles amb propietats). L'encaminador calcula una ruta amb les dades d'un mapa vectorial. El dia 26 maig de 2014 11:07, Carlos Sánchez erielk...@gmail.com ha escrit: Quina paraula és més adient? Són totes dues vàlides? -- *Carlos Sánchez*About.me http://about.me/carlos.sanchez ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Renderitzador o encaminador
Francament prefereixo rúter o router.Encaminador em sona a taka-taka... Salut, mapes i diccionaris yopaseopor 2014-05-26 11:38 GMT+02:00 Joan Montané j...@montane.cat: El dia 26 maig de 2014 11:18, Jaume Figueras i Jové jaume.figue...@upc.edu ha escrit: Hola, de 'renderizer' no en conec traducció correcte: Joan? de 'router' és encaminador Com dèieu, són coses diferents. El terme renderitzar i els seus derivats, com ara renderitzador estan normalitzats. S'usen en programes d'edició d'imatges o vídeo, per exemple. Sobre router, la traducció més acurada és encaminador. També s'empra en context informàtic (l'aparell que encamina paquets). He d'admetre que em grinyola una mica, potser per la llargada, però tant la definició com l'arrel del mot (camí) s'ajusta perfectament en el nostre cas, i és la millor opció possible. L'alternativa potser seria enrutador (de ruta), però no ho veig clar. Afortunadament, no és un terme que s'usi moltíssim, per tant usar encaminador, per a referir-nos a servei que calcula camins (o rutes) per anar d'un punt A a un altre B ja em sembla bé. Més informació sobre la terminologia **proposada** per a a l'OSM aquí [1] Joan Montané [1] http://wiki.openstreetmap.org/wiki/WikiProject_Catalan/Recull_de_termes ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] com dibuixar interseccions
leisure=park : seria per a un parc, una àrea per anar a gaudir del temps d'oci, d'aquí lo de leisure landuse=meadow : seria per a un prat, on pasturen les vaques, que també és d'herba però no seria el cas d'una rotonda Que tal landuse=grass?? http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dgrass A tag for a smaller areas of mown and managed *grass* for example in the middle of a roundabout, verges beside a road or in the middle of a dual-carriageway. Should not be used where a more specific tag is available. que traduït ve a dir: Una etiqueta per a una àrees més petites d'herba tallada i gestionada, per exemple enmig d'una rotonda, vorals al costat d'una carretera o al mig d'una carretera de doble calçada. No ha de ser usat quan hi hagi una etiqueta més específica disponible. ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cz] prapodivné tvary domů
Ahoj! (+) míněno na budově samotné, jinak jsou tam přistavěny balkony, ale jednak samozřejmě úplně jinak než tam jsou ty výstupky, a jednak nevim, jak by se měly značit, ale určitě ne stejně jako obvodový plášť Ja myslim, ze balkon je soucasti budovy, a ano, znacil by se stejne jako obvodovy plast aspon do chvile, nez bude k dispozici podrobnejsi znaceni. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Nominatim a české adresy
Chtěl jsem si napsat skriptík, který by ze sady adres vygeneroval v nějakém rozumném formátu (SVG, PDF) mapu s rozložením adres na mapě. Předpokládám, že něco takového už milionkrát existuje, ale stejně asi budu muset parsovat nesmyslně uložené adresy (pokud to nevyřeším převodem interního adresáře našeho církevního sboru na Google Contacts) takže kdybych měl dobré knihovny na: * generování souřadnic z adresy, * generování mapy tak by to snad neměl být problém (famous last words!). Tím se dostávám ale k problému, který mě štve už hodně dlouho: tomu, že Nominatim neumí parsovat české adresy. Když napíšu do http://nominatim.openstreetmap.org/ normální českou adresu (např. Květná 43, Praha 3) tak se zblázní a oznámí No search results found. Musím napsat americký formát 43 Květná, Praha 3. Kupodivu http://www.openstreetmap.org/ český formát adresy zvládá. Je to problém s nominatim (který by se snad dal nějak opravit ... např. nadefinovat nějaký Country Address Format dle https://wiki.openstreetmap.org/wiki/Nominatim/Country_Address_Format) nebo je to jenom otázka, jak se ten systém používá? Hezký den, Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
Ahoj, pokud opravdu dáváš do Nominatimu to Praha 3, tak to nenajde zejména proto, protože žádná Praha 3 v OSM není. Městské části nejsou v OSM importované. Máš pravdu, že po americku to najde, ovšem ta Praha 3 tam trochu přebývá. Možná si z toho vezme jen Praha a tu 3 ignoruje. Shrnuto - Praha 3 v OSM neexistuje. Existuje jen Praha, Žižkov, Vinohrady, Strašnice atd. Jelikož se zabývám importem adres z RUIAN do OSM, tak něco málo už o adresách vím a možná bych mohl být užitečný. Například mám v postgresql tabulku, která obsahuje všechny adresy, co jsou v OSM (a leží v ČR) včetně příslušných geometrií. Vlastně by nebyl moc problém udělat další vrstvu na http://ruian.poloha.net . Potřebuješ to generovat jednorázově nebo opakovaně? Jak to má vypadat? Kolik těch adres má být? -- Petr On Mon, May 26, 2014 at 01:05:54PM +0200, Matěj Cepl wrote: Chtěl jsem si napsat skriptík, který by ze sady adres vygeneroval v nějakém rozumném formátu (SVG, PDF) mapu s rozložením adres na mapě. Předpokládám, že něco takového už milionkrát existuje, ale stejně asi budu muset parsovat nesmyslně uložené adresy (pokud to nevyřeším převodem interního adresáře našeho církevního sboru na Google Contacts) takže kdybych měl dobré knihovny na: * generování souřadnic z adresy, * generování mapy tak by to snad neměl být problém (famous last words!). Tím se dostávám ale k problému, který mě štve už hodně dlouho: tomu, že Nominatim neumí parsovat české adresy. Když napíšu do http://nominatim.openstreetmap.org/ normální českou adresu (např. Květná 43, Praha 3) tak se zblázní a oznámí No search results found. Musím napsat americký formát 43 Květná, Praha 3. Kupodivu http://www.openstreetmap.org/ český formát adresy zvládá. Je to problém s nominatim (který by se snad dal nějak opravit ... např. nadefinovat nějaký Country Address Format dle https://wiki.openstreetmap.org/wiki/Nominatim/Country_Address_Format) nebo je to jenom otázka, jak se ten systém používá? Hezký den, Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
Cus, Květná 43, Praha najde. Potiz bude v Praha 3, to totiz neexistuje. Respektive ne v datech, ktera jsou prohledavana. Podle me to pri tom alternativnim zapisu tu 3ku proste ignoruje. Duvodem bude IMO prave to, ze pokud napises cislo pred, tak se detekuje US format ... a predpoklada se vsude cislo nazev, cislo nazev, Kdezto kdyz to napises evropsky, tak to cislo za mestem bere v uvahu nazev cislo, nazev cislo, ... = nenajde. Ale to je jen spekulace. Tuhle mas seznam poli, ktery se rohledavaj: http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview Dne 26.5.2014 13:05, Matěj Cepl napsal(a): Chtěl jsem si napsat skriptík, který by ze sady adres vygeneroval v nějakém rozumném formátu (SVG, PDF) mapu s rozložením adres na mapě. Předpokládám, že něco takového už milionkrát existuje, ale stejně asi budu muset parsovat nesmyslně uložené adresy (pokud to nevyřeším převodem interního adresáře našeho církevního sboru na Google Contacts) takže kdybych měl dobré knihovny na: * generování souřadnic z adresy, * generování mapy tak by to snad neměl být problém (famous last words!). Tím se dostávám ale k problému, který mě štve už hodně dlouho: tomu, že Nominatim neumí parsovat české adresy. Když napíšu do http://nominatim.openstreetmap.org/ normální českou adresu (např. Květná 43, Praha 3) tak se zblázní a oznámí No search results found. Musím napsat americký formát 43 Květná, Praha 3. Kupodivu http://www.openstreetmap.org/ český formát adresy zvládá. Je to problém s nominatim (který by se snad dal nějak opravit ... např. nadefinovat nějaký Country Address Format dle https://wiki.openstreetmap.org/wiki/Nominatim/Country_Address_Format) nebo je to jenom otázka, jak se ten systém používá? Hezký den, Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] prapodivné tvary domů
Dne 26.5.2014 09:14, Pavel Machek napsal(a): Ahoj! (+) míněno na budově samotné, jinak jsou tam přistavěny balkony, ale jednak samozřejmě úplně jinak než tam jsou ty výstupky, a jednak nevim, jak by se měly značit, ale určitě ne stejně jako obvodový plášť Ja myslim, ze balkon je soucasti budovy, a ano, znacil by se stejne jako obvodovy plast aspon do chvile, nez bude k dispozici podrobnejsi znaceni. Pavel Ona je asi podstatné, co by se vlastně mělo v OSM mapovat: Střecha? Základy? Obrys? Střecha je vidět na satelitní mapě. Základy jsou vidět v katastru/RUIAN. Obrys je asi kombinací obého. U něj je ale problém určit, co je ještě obrys. Patří schody/nájezdová rampa k domu? A terasa? I v KM/RUIAN to je pokaždé jiné, záleží kdo a kdy to zpracovával. A i ty balkóny. Pokud jsou pěkně v řadě nad sebou, tak je to v klidu, ale ony bývají i různě na přeskáčku a to pak z obrysu nejde poznat, co je balkón a co už ne. Takže asi záleží případ od případu. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
On 2014-05-26, 15:06 GMT, Marián Kyral wrote: Kde ses schovával poslední čtyři měsíce? :-D Ignoroval jsem tenhle list, protože jsem byl zavalen jinejma věcma ;). A nedalo by se na tohle nějak využít overpass API? http://wiki.openstreetmap.org/wiki/Overpass_API http://wiki.openstreetmap.org/wiki/Overpass_turbo Tohle má být jednoduché? Proč XML? Mohl bych dostat normální API pro Python, s objekty, metodami a tak? Taky nějaké příklady by se hodily. Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] dotaz na nově digitalizovaná k. ú.
Chtěl jsem se zeptat, kde se dá získat seznam nově digitalizovaných katastrálních území - jedná se mi o letošní rok Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres a vzdálenost AM od SO
Dobrý den, děkuji za objevení tohoto problému. Již to máme zapsané v našem interním helpdesku a problém řešíme. Ozvu se hned, jak zjistíme příčinu a opravíme ji. Vypadá to na nějakou chybu v párování budov z ISKN a stavebních objektů v ISÚI, které se provádí až v RÚIAN. Petr Souček -Original Message- From: hanoj [mailto:eha...@gmail.com] Sent: Saturday, May 24, 2014 10:52 PM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Import adres a vzdálenost AM od SO Uz to vidim (UZSZ neni UKSH), mas recht. Ta geometrie so 51833077 je ukradena tomuto domu so 51474468: http://pastebin.com/G0RXydht http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/51474468 hezky ;) ha hanoj Dne 24. května 2014 22:25 Petr Vejsada o...@propsychology.cz napsal(a): Ahoj, UZSZ - vybral sis základní datovou sadu. Ta polygony neobsahuje, je třeba použít sadu UKSH. Bez ohledu na to, zda DKM v Klatovech je či není, tak soubor 20140430_OB_555771_UKSH.xml.gz tam ten polygon prostě má a leží v Poličce. http://pastebin.com/6SeTEnUb Dne So 24. května 2014 21:56:59, hanoj napsal(a): ano, to je ono. Adresní místo v tomto případě má geometrii a ta je shodná s definičním bodem. Až na tu maličkost, že hranice, tedy vlastní polygon budovy, se nenachází v Klatovech, ale 221km odsud, v Poličce. *** IMHO so 51833077 polygon budovy nema: http://pastebin.com/AvUQxjvf http://vdp.cuzk.cz/vymenny_format/soucasna/20140430_OB_555771_UZSZ.xm l.gz k.ú. Klatovy, kam Kal č.p.25 spadá nemá ještě DKM, tudíž ani polygony v RUIAN. http://vdp.cuzk.cz/vdp/ruian/katastralniuzemi/665797 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Další, zajímavá, duchařina
Dobrý den, děkuji za zprávu a důvěru :-). Již jsem tento problém předal kolegům, kteří budou kontaktovat příslušného editora, aby situaci prověřil/opravil. Věřím, že Vám v nejbližší době budu moct napsat, jak postupují opravy na straně editora - obce Hlásná Třebáň. Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Friday, May 23, 2014 11:01 PM To: talk-cz@openstreetmap.org Subject: [Talk-cz] Další, zajímavá, duchařina Dobrý den,, zpráva hlavně pro p. Součka: Hlásná Třebáň, SO 1534190 má ev. č. 537. Asi 4 metry od něho se nachází další SO typu duch, tedy nejspíš fiktivní SO z UIR-ADR, který má rovněž ev.č. 537. Je jich tam v okolí takových více. Asi tedy došlo k zavedení fiktivních SO s adresami a proti tomu existovaly i reálné SO v jiném registru, které mají tutéž adresu. Pak už je nikdo nespároval a tyto duplicity z RUIAN nevyndal. Je to nový objev, oproti dvojicím typu ev.č. 34 a 5034, zde mají oba z dvojice stejné ev.č. -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
Dobrý den, možná bude můj dotaz OOT, ale z jakého důvodu neimportujete v OSM tyto údaje (Praha 3)? Chápu městské části (v členěných statutárních městech), protože ty se do adresy nezapisují. Ale v Praze se do adresy vypisuje Městský obvod Prahy (http://vdp.cuzk.cz/vdp/ruian/mestskeobvody/vyhledej?mp.nazev=mp.kod=mpg.sort=NAZEVsearch=Vyhledat), tj. právě ta níže zmiňovaná Praha 3. Adresa dle vyhlášky č. 359/2011 by se měla pro adresní místo Květná 43, Praha 3 http://vdp.cuzk.cz/vdp/ruian/adresnimista/21764409 vypisovat takto: Květná 2097/43 Vinohrady 13000 Praha 3 Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Monday, May 26, 2014 3:18 PM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Nominatim a české adresy Ahoj, pokud opravdu dáváš do Nominatimu to Praha 3, tak to nenajde zejména proto, protože žádná Praha 3 v OSM není. Městské části nejsou v OSM importované. Máš pravdu, že po americku to najde, ovšem ta Praha 3 tam trochu přebývá. Možná si z toho vezme jen Praha a tu 3 ignoruje. Shrnuto - Praha 3 v OSM neexistuje. Existuje jen Praha, Žižkov, Vinohrady, Strašnice atd. Jelikož se zabývám importem adres z RUIAN do OSM, tak něco málo už o adresách vím a možná bych mohl být užitečný. Například mám v postgresql tabulku, která obsahuje všechny adresy, co jsou v OSM (a leží v ČR) včetně příslušných geometrií. Vlastně by nebyl moc problém udělat další vrstvu na http://ruian.poloha.net . Potřebuješ to generovat jednorázově nebo opakovaně? Jak to má vypadat? Kolik těch adres má být? -- Petr On Mon, May 26, 2014 at 01:05:54PM +0200, Matěj Cepl wrote: Chtěl jsem si napsat skriptík, který by ze sady adres vygeneroval v nějakém rozumném formátu (SVG, PDF) mapu s rozložením adres na mapě. Předpokládám, že něco takového už milionkrát existuje, ale stejně asi budu muset parsovat nesmyslně uložené adresy (pokud to nevyřeším převodem interního adresáře našeho církevního sboru na Google Contacts) takže kdybych měl dobré knihovny na: * generování souřadnic z adresy, * generování mapy tak by to snad neměl být problém (famous last words!). Tím se dostávám ale k problému, který mě štve už hodně dlouho: tomu, že Nominatim neumí parsovat české adresy. Když napíšu do http://nominatim.openstreetmap.org/ normální českou adresu (např. Květná 43, Praha 3) tak se zblázní a oznámí No search results found. Musím napsat americký formát 43 Květná, Praha 3. Kupodivu http://www.openstreetmap.org/ český formát adresy zvládá. Je to problém s nominatim (který by se snad dal nějak opravit ... např. nadefinovat nějaký Country Address Format dle https://wiki.openstreetmap.org/wiki/Nominatim/Country_Address_Format) nebo je to jenom otázka, jak se ten systém používá? Hezký den, Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
Dne 26.5.2014 19:44, Petr Souček napsal(a): Dobrý den, možná bude můj dotaz OOT, ale z jakého důvodu neimportujete v OSM tyto údaje (Praha 3)? Chápu městské části (v členěných statutárních městech), protože ty se do adresy nezapisují. Ale v Praze se do adresy vypisuje Městský obvod Prahy (http://vdp.cuzk.cz/vdp/ruian/mestskeobvody/vyhledej?mp.nazev=mp.kod=mpg.sort=NAZEVsearch=Vyhledat), tj. právě ta níže zmiňovaná Praha 3. Adresa dle vyhlášky č. 359/2011 by se měla pro adresní místo Květná 43, Praha 3 http://vdp.cuzk.cz/vdp/ruian/adresnimista/21764409 vypisovat takto: Květná 2097/43 Vinohrady 13000 Praha 3 Petr Souček Dobrý den, předně velice děkujeme za odkaz na konkrétní vyhlášku - konečně tedy víme přesně, které členění Prahy se v adrese má používat (městské obvody Praha 1-10). (Zatím) se tyto data neimportují především proto, že nebylo příliš jasné, jaké členění a kde všude by se mělo do OSM importovat - jen Praha, nebo všechna statutární města; v Praze použít městské části (54), správní obvody (22), nebo městské obvody (10). Osobně jsem se (zjevně mylně) domníval, že číslo městského obvodu do adresy nepatří. Dokonce i formulář pro ověření adresy [1] obsahuje jen políčko Obec, nikoliv Městský obvod, takže je potřeba zadat jen Praha bez čísla, v opačném případě sice vyhledávání zafunguje, ale objeví se upozornění: Nebyla nalezena adresa přesně odpovídající zadání, systém se pokusil nalézt adresy přibližně splňující požadavek. Zdraví, Petr Morávek [1] http://vdp.cuzk.cz/vdp/ruian/overeniadresy/vyhledej ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dotaz na nově digitalizovaná k. ú.
Ahoj, v seznamu mi chybí pouze změny, které se provedly mezi lednem a únorem, jinak seznam je zde: http://wiki.openstreetmap.org/wiki/Cs:RUIAN/nove_budovy Zdraví Pavel Kwiecien -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 26. 5. 2014 18:24:09 Předmět: [Talk-cz] dotaz na nově digitalizovaná k. ú. Chtěl jsem se zeptat, kde se dá získat seznam nově digitalizovaných katastrálních území - jedná se mi o letošní rok Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
Dne 26.5.2014 17:56, Matěj Cepl napsal(a): On 2014-05-26, 15:06 GMT, Marián Kyral wrote: Kde ses schovával poslední čtyři měsíce? :-D Ignoroval jsem tenhle list, protože jsem byl zavalen jinejma věcma ;). A nedalo by se na tohle nějak využít overpass API? http://wiki.openstreetmap.org/wiki/Overpass_API http://wiki.openstreetmap.org/wiki/Overpass_turbo Tohle má být jednoduché? Proč XML? Mohl bych dostat normální API pro Python, s objekty, metodami a tak? Taky nějaké příklady by se hodily. Ask Google ;-) https://launchpad.net/osmxapi - neznám, nezkoušel jsem a prý už se o to nikdo nestará. Nicméně, fungovat by to mohlo. Pokud ne, tak zkus pohledat na netu. Overpass turbo má i jednoduchého průvodce. A výstup nemusí být jen xml, ale třeba i GeoJSON, gpx, kml, raw. Bohužel, žádnou jinou a jednoduchou cestu neznám. Marián Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] Evaluer les kms de voies cyclables
Bonjour, je fais partie de vélocité de l'Angoumois et depuis 1 an nous contribuons à OSM pour répertorier les équipements cyclables de l'agglo, rajouter les rues manquantes ... Nous aimerions avoir une idée du kilométrage de voies cyclables de l'agglomération d'Angoulême Est- ce qu'il y a une méthode pour cela ? Merci d'avance Dominique ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Sur le modèle des adresses (était Rendu BANO)
2014-05-24 15:04 GMT+02:00 DH dhel...@free.fr: Ainsi, par exemple, je n'avais pas assimilé l'intérêt des relations AssociatedStreet, maintenant si. Au risque de me répéter, il y aurait un grand danger à vouloir généraliser les relations associatedStreet dans OSM pour des raisons que j'ai déjà expliqué par ailleurs mais que je vais résumer ici: - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je les défie de modifier ces relations avec iD ou P2, ne serait-ce que de déplacer un numéro d'une rue à sa voisine. C'est très difficile et chia.. même pour les habitués. Et ne parlons pas des nouveaux contributeurs ou irréguliers. - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient pas au long cours. On le voit avec toutes les relations comme les limites administratives, toutes les relations de type route ou même les multipolygones (pensez landuse corine), elles sont plus difficiles à maintenir parce qu'elles sont souvent cassées par les néophites. Ou pire, si l'éditeur est préventif à l'égard de toute modification comme dans JOSM, elle bloquera la bonne volonté du débutant. - nous serions le seul pays à utiliser à une telle échelle une relation par rue dans OSM. Si aucun autre pays n'a fait ce choix, il faudrait au moins se demander pourquoi (alors qu'ils sont nombreux à faire des imports du même type et à se poser les mêmes questions que nous). L'habitude du village gaullois qui a raison seul contre tous ? - l'argument d'éviter les redondances ne tient pas. C'est même le contraire. Faute de support dans les outils externes autres que nominatim, les noms de rues sont de toute façon répétés sur la rue et la relation, si ce n'est pire, sur la rue et chaque numéro. Sans parler de l'internationalisation, des alt_name ou autres liens externes, on verra au final tous les tags doublonner. Certains ici prônent même la redondance comme solution à leurs problèmes lorsqu'ils doivent rédiger des règles de rendu pour mapnik et qu'ils trouvent au final la gestion des relations bien lourdes au niveau logiciel. - sur la modélisation elle-même, tout ce qui peut s'identifier par une relation peut se faire sans elle. Des solutions existent déjà pour les name, ref ou ref:FR:FANTOIR, même pour des rues appartenant à deux communes. - l'argument du changement de nom de rue qui serait plus facile est, là encore, discutable. Comme on l'a vu, les noms sont déjà répétés et il y faudra de toute façon surveiller la cohérence entre noms et numéros avec des outils QA (ce que fait déjà l'outil de geofabrik, par exemple). Et de toute façon, les changements de noms sont assez rares et on sera d'avantage confronté à du vandalisme ou des interprétations orthographiques divergentes. - finalement, le principal avantage des relations se trouve du côté des utilisateurs des données. Pour eux, il est effectivement plus facile de travailler avec une relation par rue que de chercher à assembler des morceaux de rues pas toujours attachés entre eux avec des noeuds ou des polygones éparses. Mais dans OSM, il y a une règle de base : c'est le terrain qui prime, et 90% des contributeurs sont des contributeurs uniques ou de très faible niveau. Même si ça n'est pas eux qui produisent le plus de données en quantité, ce sont eux qui sont les plus proches du terrain et qui fournissent les meilleures données en qualité. S'il faut donc choisir entre faciliter la vie des consommateurs des données OSM (les développeurs) et celle des contributeurs néophites, il faudra toujours essayer de priviligier autant que possible les seconds, quitte à donner un peu plus de travail aux premiers. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr