Re: [Talk-hr] Hrvatska biciklistička mreža
On Mon, 12 Oct 2009 11:51:26 +0200, hbogner wrote: Htio bih pokrenuti wiki stranicu sa podatcima o hrvatskim biciklističkim mrežama. Prva dilema mi je pisati na engleskom ili na hrvatskom? Druga dilema mi je kako imenovati stranicu? Pogledao sam i vidio da razne zemlje imaju na razne načine: http://wiki.openstreetmap.org/wiki/Croatia/Cycle_Routes http://wiki.openstreetmap.org/wiki/Croatia_Cycle_Routes http://wiki.openstreetmap.org/wiki/Croatia/Cycle_Network http://wiki.openstreetmap.org/wiki/Croatia_Cycle_Network Ili na hrvatski Biciklističke_staze, Biciklistička_mreža što sam izbjegavao zbog slova sa kvačicama. Kaj vi predlažete?? Ja uopće ne bi imao dileme, napravi na hrvatskom i na engleskom, a moglo bi i na deutsch (pošto su nam to najjači turisti) :-) Onako da gore ima link za mjenjanje jezika (to bi mogli odraditi i na stranici Wikiproject Croatia) p.s. ako ti se to neda, onda barem napraviš link Translate to English übersetzen in deutsch(translate.google.com). ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Hrvatska biciklistička mreža
Druga dilema mi je kako imenovati stranicu? Pogledao sam i vidio da razne zemlje imaju na razne načine: http://wiki.openstreetmap.org/wiki/Croatia/Cycle_Routes http://wiki.openstreetmap.org/wiki/Croatia_Cycle_Routes http://wiki.openstreetmap.org/wiki/Croatia/Cycle_Network http://wiki.openstreetmap.org/wiki/Croatia_Cycle_Network Eh da zaboravih oko ovih linkova: http://wiki.openstreetmap.org/wiki/Croatian_Cycle_Routes (engleski) http://wiki.openstreetmap.org/wiki/En:Croatian_Cycle_Routes (english) http://wiki.openstreetmap.org/wiki/De:Croatian_Cycle_Routes (deutsch) http://wiki.openstreetmap.org/wiki/Croatian_Cycle_Network http://wiki.openstreetmap.org/wiki/En:Croatian_Cycle_Network http://wiki.openstreetmap.org/wiki/De:Croatian_Cycle_Network ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Hrvatska biciklistička mreža
Marjan Vrban wrote: Neznam da li si radio s relacijama, ali evo opisa i za ostale koji nisu: Stavi pod network, a ako će se detaljnije opisivati pojedniačne rute onda bi bilo dobro oboje, a network čine pripadajuće rute. Route je ruta (biciklistička, pješačka, automobilska, linije javnog prijevoza) npr. cesta D2 (od SLO-VŽ-KC-VT-NA-OS-VU-do SRB) je ruta sastavljena od nekoliko ili puno dijelova (ulice, ceste, kužni tokovi, mostovi). Ruta D2 - http://www.openstreetmap.org/browse/relation/255413 Network : npr. http://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network http://www.openstreetmap.org/browse/relation/20645 Route: wiki: http://wiki.openstreetmap.org/wiki/Relation:route Radio sam biciklističke relacije i ZET relacije i neke multipoligon relacije tako da znam što su relacije :D Interesira me čisto tehnički naziv, onda bolje ispada network, jer unutar te stranice mislim ukomponirati i national i regional i local network biciklističke relacije. Za sad imam smao lokalne turističke biciklističke rute, poput Sljemena, Samoborskog gorja i Topuskog, ali s vremenom će se skupiti i ostale. Bitno mi ej sve sad definirati da se kasnije mogu navući biciklisti na to da mogu i oni sami popunjavati :D Još da se napiše kratki opis svake rute :D ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [talk-ph] Ground Truth
Hi, Yes this is a nifty tool. I am experimenting on this one for a couple of weeks now generating contours (10 meter interval) for garmin devices. So far I was able to generate the whole Philippines from SRTM. Anyone who wants one I can give it. The problem is, it is a .NET based apps (with dependencies on cgpsmapper). I had mixed results before with using mono so I had to use a virtualbox for groundtruth to work easily. Moreover, free cgpsmapper doesn't support road routing so I had to use mkgmap for roads while groundtruth for contour generation which is OK since you had to generate garmin contours only one. Make sure you have a lot of RAM and disk space allotted for your vbox to produce the whole Philippine contour. On Mon, Oct 12, 2009 at 10:18 AM, Jim Morgan j...@datalude.com wrote: Hi All. Been a bit quiet recently as I went off to UK and France for a couple of weeks. Just got back in the middle of the typhoon, and have been catching up with work since then. Anyway today I had a bit of spare time, and found myself browsing the OSM site. I found some software called GroundTruth which looked interesting, so I thought I'd share it. http://wiki.openstreetmap.org/wiki/GroundTruth It will apparently make Garmin maps of a given area. It will also make maps in image format as well, like the OSM export function. However, what I found interesting, is that you can play with the way it renders the data, by using a Map Rules file. The examples given on the wiki are for eg driving maps, cycling maps, hiking maps, and you can choose whether or not to include contour data etc. But you can also write your own map rules files, so you can customise how the data displays to your own taste. There are a few user examples of this as well. It seemed like worth mentioning, as a couple of questions on the list this year have been related to this custom rendering function. I don't have a use for it right now, but I'm thinking ... Jim -- datalude: information security e: j...@datalude.com Philippines: +63 2 403 1311 / mob: +63 920 912 5830 Hong Kong: +852 6840 6693 w: http://www.datalude.com/ ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fwd: Planning ahead of disasters with GIS
Incredible! it just might be a ploy to justify more government spendings :) I guess its up to us to really inform the government that OSM can really help. Bigay na lang natin sa mga biktima ang cost savings :) On Mon, Oct 12, 2009 at 4:09 PM, maning sambale emmanuel.samb...@gmail.comwrote: Pucha! I almost fell-off my chair! With each map sheet costing P500,000, creating a GIS base map will cost P6.5 billion. I know data creation is expensive, but is it really that much (500K per mapsheet)? -- Forwarded message -- From: r...@cp-union.com r...@cp-union.com Date: Mon, Oct 12, 2009 at 3:31 PM Subject: Planning ahead of disasters with GIS To: maning sambale emmanuel.samb...@gmail.com Sagutin natin na may available ng mga opensource tools for this and what we need are more support from the government to complete base maps ng phil. Much cheaper din kung open source gagamitin. http://technology.inquirer.net/infotech/infotech/view/20091012-229676/Planning-ahead-of-disasters-with-GIS What you think? Rick -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fwd: Planning ahead of disasters with GIS
I'm all for unifying GIS data for the whole Philippines, but before they get on another mapping spending spree, please let us know whatever happened to the geohazard mapping they initiated after the leyte landslides: http://www.newsflash.org/2004/02/pe/pe003835.htm Was it successful? Did LGUs used the data? Were lives saved because of these maps? [with apologies for ranting] On Mon, Oct 12, 2009 at 6:18 PM, George Tujan gtu...@gmail.com wrote: Incredible! it just might be a ploy to justify more government spendings :) I guess its up to us to really inform the government that OSM can really help. Bigay na lang natin sa mga biktima ang cost savings :) On Mon, Oct 12, 2009 at 4:09 PM, maning sambale emmanuel.samb...@gmail.com wrote: Pucha! I almost fell-off my chair! With each map sheet costing P500,000, creating a GIS base map will cost P6.5 billion. I know data creation is expensive, but is it really that much (500K per mapsheet)? -- Forwarded message -- From: r...@cp-union.com r...@cp-union.com Date: Mon, Oct 12, 2009 at 3:31 PM Subject: Planning ahead of disasters with GIS To: maning sambale emmanuel.samb...@gmail.com Sagutin natin na may available ng mga opensource tools for this and what we need are more support from the government to complete base maps ng phil. Much cheaper din kung open source gagamitin. http://technology.inquirer.net/infotech/infotech/view/20091012-229676/Planning-ahead-of-disasters-with-GIS What you think? Rick -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fwd: Planning ahead of disasters with GIS
How big an area do the data sheets cover? Maybe the budget also covers data maintenance over a set number of years? Then again, the government tends to overbudget on IT projects like this. :-/ On Mon, Oct 12, 2009 at 4:09 PM, maning sambale emmanuel.samb...@gmail.comwrote: Pucha! I almost fell-off my chair! With each map sheet costing P500,000, creating a GIS base map will cost P6.5 billion. I know data creation is expensive, but is it really that much (500K per mapsheet)? -- Forwarded message -- From: r...@cp-union.com r...@cp-union.com Date: Mon, Oct 12, 2009 at 3:31 PM Subject: Planning ahead of disasters with GIS To: maning sambale emmanuel.samb...@gmail.com Sagutin natin na may available ng mga opensource tools for this and what we need are more support from the government to complete base maps ng phil. Much cheaper din kung open source gagamitin. http://technology.inquirer.net/infotech/infotech/view/20091012-229676/Planning-ahead-of-disasters-with-GIS What you think? Rick -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fw: Philippines
I joined the Typhoon Ondoy Google Groups ( http://groups.google.com/group/typhoonondoy) and brought up the OSB map and the use of OSM tiles as an alternative layer for areas where Google Maps is poor (like Laguna). Anyway, check out this interface they developed incorporating OSM Mapnik tiles as another layer to the default Google Maps tiles. http://www.google.com/maps/mpl?moduleurl=http://sugo-katta.appspot.com/neoMapplet35.xml The discussion there is centering towards aggregating all the disparate data into a unified repository of sorts. This will include rescue, relief, rehabilitation, and rebuilding data. On Sun, Oct 11, 2009 at 12:22 PM, Mikel Maron mikel_ma...@yahoo.com wrote: Received the message below from MapAction .. major kudos, plus requests for data, if there's any possibility of collecting it. - Forwarded Message From: Andrew Smith Subject: RE: Philippines Hi Mikel, Thanks for your email. The OSM data has been fantastic - please pass on our congratulations and thanks to the OSM Philippines team. There is a big need for roads data outside Metro Manila, in particularly in Region III and Region I. The Provinces of La Union, Pangasinan, Tarlac and Pampanga are the worst hit by Pepeng/Parma. Additionally there is the need for the current road status throughout all of the above areas, all the western edge of Laguna De May (see the AOI map attached - this was made for a different purpose, but suffices for this.) There is GIS officer from WFP/Logs Cluster arriving soon, so I will mention your interest and OSM PH's efforts to them. Longer term they would be the people on the international side of thing who will be wanting to know about roads. If you've not already found it, you may be interested in the Typhoon Ondy Google Group: http://www.google.com/landing/typhoon-ondoy.html We have been in contact with them. They have setup a crowd-source mapping effort with some success - helped by the fact that they have some Google alumni amongst their numbers, meaning that they where for a while on the www.google.com.ph landing page. There are quite a lot of other crowd source efforts about and they are now attempting to aggregate them. They have been after roads and road status data recently. I'd recommend you and/or OSM PH introducing themselves on that list. The boundaries are a definite no I'm afraid. This was given to us by GeoData (www.geodata.com.ph) the local ESRI supplier - under a use but don't share arrangement. The other publicly available boundary data was a bit of a mess I'm afraid. Best wishes, Andy Andy Smith - Philippines Field Team MapAction (www.mapaction.org) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fw: Philippines
Great, just joined that group too That's a really nice Google Maps hack :) From: Eugene Alvin Villar sea...@gmail.com To: Mikel Maron mikel_ma...@yahoo.com Cc: osm-ph talk-ph@openstreetmap.org Sent: Mon, October 12, 2009 9:41:16 AM Subject: Re: [talk-ph] Fw: Philippines I joined the Typhoon Ondoy Google Groups (http://groups.google.com/group/typhoonondoy) and brought up the OSB map and the use of OSM tiles as an alternative layer for areas where Google Maps is poor (like Laguna). Anyway, check out this interface they developed incorporating OSM Mapnik tiles as another layer to the default Google Maps tiles. http://www.google.com/maps/mpl?moduleurl=http://sugo-katta.appspot.com/neoMapplet35.xml The discussion there is centering towards aggregating all the disparate data into a unified repository of sorts. This will include rescue, relief, rehabilitation, and rebuilding data. On Sun, Oct 11, 2009 at 12:22 PM, Mikel Maron mikel_ma...@yahoo.com wrote: Received the message below from MapAction .. major kudos, plus requests for data, if there's any possibility of collecting it. - Forwarded Message From: Andrew Smith Subject: RE: Philippines Hi Mikel, Thanks for your email. The OSM data has been fantastic - please pass on our congratulations and thanks to the OSM Philippines team. There is a big need for roads data outside Metro Manila, in particularly in Region III and Region I. The Provinces of La Union, Pangasinan, Tarlac and Pampanga are the worst hit by Pepeng/Parma. Additionally there is the need for the current road status throughout all of the above areas, all the western edge of Laguna De May (see the AOI map attached - this was made for a different purpose, but suffices for this.) There is GIS officer from WFP/Logs Cluster arriving soon, so I will mention your interest and OSM PH's efforts to them. Longer term they would be the people on the international side of thing who will be wanting to know about roads. If you've not already found it, you may be interested in the Typhoon Ondy Google Group: http://www.google.com/landing/typhoon-ondoy.html We have been in contact with them. They have setup a crowd-source mapping effort with some success - helped by the fact that they have some Google alumni amongst their numbers, meaning that they where for a while on the www.google.com.ph landing page. There are quite a lot of other crowd source efforts about and they are now attempting to aggregate them. They have been after roads and road status data recently. I'd recommend you and/or OSM PH introducing themselves on that list. The boundaries are a definite no I'm afraid. This was given to us by GeoData (www.geodata.com.ph) the local ESRI supplier - under a use but don't share arrangement. The other publicly available boundary data was a bit of a mess I'm afraid. Best wishes, Andy Andy Smith - Philippines Field Team MapAction (www.mapaction.org) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fw: Philippines
On Tue, Oct 13, 2009 at 12:41 AM, Eugene Alvin Villar sea...@gmail.com wrote: I joined the Typhoon Ondoy Google Groups (http://groups.google.com/group/typhoonondoy) and brought up the OSB map and the use of OSM tiles as an alternative layer for areas where Google Maps is poor (like Laguna). Anyway, check out this interface they developed incorporating OSM Mapnik tiles as another layer to the default Google Maps tiles. http://www.google.com/maps/mpl?moduleurl=http://sugo-katta.appspot.com/neoMapplet35.xml The discussion there is centering towards aggregating all the disparate data into a unified repository of sorts. This will include rescue, relief, rehabilitation, and rebuilding data. Nice! The interface looks cool. But I can't seem to get it working. I tested submitting reports but I can't add an address nor a point. There are no reports generated (probably my poor internet connection). A couple of questions: 1. Do I need a google account to submit reports? 2. Is it possible to close/fix a report? Other than that, the design is excellent especially when we can aggregate other info. A major plus factor to google is the aerials, even when there is no roads we can at least pinpoint a location by looking at the imagery. (You don't need 6.5 B PHP to do this btw, pun intended) On Sun, Oct 11, 2009 at 12:22 PM, Mikel Maron mikel_ma...@yahoo.com wrote: Received the message below from MapAction .. major kudos, plus requests for data, if there's any possibility of collecting it. - Forwarded Message From: Andrew Smith Subject: RE: Philippines Hi Mikel, Thanks for your email. The OSM data has been fantastic - please pass on our congratulations and thanks to the OSM Philippines team. There is a big need for roads data outside Metro Manila, in particularly in Region III and Region I. The Provinces of La Union, Pangasinan, Tarlac and Pampanga are the worst hit by Pepeng/Parma. Additionally there is the need for the current road status throughout all of the above areas, all the western edge of Laguna De May (see the AOI map attached - this was made for a different purpose, but suffices for this.) There is GIS officer from WFP/Logs Cluster arriving soon, so I will mention your interest and OSM PH's efforts to them. Longer term they would be the people on the international side of thing who will be wanting to know about roads. If you've not already found it, you may be interested in the Typhoon Ondy Google Group: http://www.google.com/landing/typhoon-ondoy.html We have been in contact with them. They have setup a crowd-source mapping effort with some success - helped by the fact that they have some Google alumni amongst their numbers, meaning that they where for a while on the www.google.com.ph landing page. There are quite a lot of other crowd source efforts about and they are now attempting to aggregate them. They have been after roads and road status data recently. I'd recommend you and/or OSM PH introducing themselves on that list. The boundaries are a definite no I'm afraid. This was given to us by GeoData (www.geodata.com.ph) the local ESRI supplier - under a use but don't share arrangement. The other publicly available boundary data was a bit of a mess I'm afraid. Best wishes, Andy Andy Smith - Philippines Field Team MapAction (www.mapaction.org) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Fwd: Planning ahead of disasters with GIS
On Tuesday 13 October 2009 11:00:35 am maning sambale wrote: :-/I hope so, but what worries me is when we start doing this, can we sustain the effort? In some LGUs , they have way better GIS database than what NAMRIA has. Moreover, does it make much sense to do 1:10K mapping for rugged, uninhabited areas of the Philippines? When you are looking at water flows, then this data can be very important, as it may be a drainage area for a location quite a distance away. Also when they have proper Radar installed they can then see that the rain is falling in these areas, and inform the concerned citizens miles away that they could expect a flash flood. Flash floods caused by rain in isolated areas probably kills more people, since people think it is all safe then the water rises unexpectedly elsewhere. If you are going to do a job like this it is better to do it all correctly than what they have done before which is piece meal which just adds to the frustration when disasters like this occur and you cannot even go back 20 or 40 years to get a good topographical map of the areas concerned. Do it right or not at all. Yes they can prioritise populated areas, but map the lot and then later also the other departments like land use planning, Land titles, can use them. MY 2 Centavos, I do think it is a little costly, but then again looked at your electricity bill lately (2nd most expensive in Asia) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Fwd: osb
I replied to this inquiry on using the osb disaster reporting webmap. -- Forwarded message -- From: maning sambale emmanuel.samb...@gmail.com Date: Tue, Oct 13, 2009 at 12:00 PM Subject: Re: osb To: Ronnel Golimlim ronnel, Glad to know you find it useful. You can add as much info as you want. One of the features of the system is to be able to easily submit a report (no login needed), once you have provided relief to certain areas, you can mark the report as fixed the icon will change to a blue check mark. You can unfix and fix a report anytime. This way we can monitor which areas need immediate concern. Another feature is you can monitor specific areas given a certain zoom level. For example, if your efforts are concentrated on areas around Dagupan City: http://osb.maps.jsintl.org/?lon=120.381lat=16.05923zoom=12layers=BTTT You can get RSS reports for this area only: http://osb.maps.jsintl.org/osb-cgi/getRSSfeed?b=15.90708t=16.21127l=120.1441r=120.61789 or if you have a GPS, you can download a GPX file showing locations of the report: http://osb.maps.jsintl.org/osb-cgi/getGPX?b=15.90708t=16.21127l=120.14411r=120.61789open=yes We can generate reports for you just let us know what specific info you need. Openstreetmap can also provide you with volunteer mapping services (to update the background map) and since the data (map and submitted reports) can be freely downloaded, we can create additional map-based information. Good luck and more power! On Tue, Oct 13, 2009 at 11:42 AM, Ronnel Golimlim Hi there... i would like to ask on how we can use more that mapping system..i have already tested it and i find it very useful..im already promoting osm-ph..but i would like to ask if we can still improve this..like reporting if we have already provided relief to the affected area, so that other organizations can divert their support to other areas who havent reached by relief, also evac center mapping, etc...love to hear from you RONNEL T. GOLIMLIM, RSW -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] bot vandalism
Apo, I don't know about the specific case you are talking about. But on a more general note, I am sure that we will be seeing stricter rules for bots, where instead of *politely asking* for things to be discussed before the bot runs properly documented, we will in the future *demand* that this is the case and threaten to suspend bot accounts that don't play by the rules, and revert their edits. I don't think that there will be an approval process for bots in the near future (simply because of the manpower required for such approval). We might also ask bot users to flag the relevant accounts as bot accounts, to allow easier filtering on the user side (I am not interested in changes done by bots). Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] bot vandalism
2009/10/12 Matthias Versen s...@mversen.de: Should we allow to register everyone only with a valid email address and let him edit the whole planet with JOSM/potlatch/script without quality check ? This new users are doing the same mistakes I did at the beginning and they often break valid data and they sometimes don't respond to emails if you have questions unlike the bot owner of that bot. snip I have a flood of edits as well : http://www.openstreetmap.org/user/Nightdive/edits The difference between a prolific user and a bot is depending on how the bot is coded it has the potential to do a lot more damage if left unchecked, in the case of a new user they are more likely to check the results (rendering) of their edits and adjust or correct their work before making further mistakes, bots don't have this feed back loop once they're let loose and the results could be very devastating. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] bot vandalism
On 11 Oct 2009, at 22:37 , Matthias Versen wrote: Apollinaris Schoell wrote: I know it has been discussed before but found a lot of broken data created by bot bugbuster and this is important enough to bring it up again. There was some lame response but never really an explanation what this bot is doing. Some edits are correct others are not. Always include examples that are bad (changeset + relation/way/node ). wanted to raise the problem of bots in general, don't need help to revert or anyone to check the data. There is little information in the wiki that there has been some bug fixes. But how can I know if the bot doesn't break my fixed data again. What did the owner of the but answered ? Should we allow bots at all? Sure if they are useful and documented. But there should be a need to do a quality check and review first before someone is allowed to run a bot against the whole planet. Should we allow to register everyone only with a valid email address and let him edit the whole planet with JOSM/potlatch/script without quality check ? This new users are doing the same mistakes I did at the beginning and they often break valid data and they sometimes don't respond to emails if you have questions unlike the bot owner of that bot. the difference is no Potlatch or Josm user can edit that fast and destructive unless it's some evil vandal. a broken bot can destroy lot of data before even anyone detects it. If it's real vandalism we can simply revert but a 90% useful bot change is hard to justify for a full revert to make sure the 10% are fixed. this bot does so many edits and it's very difficult to even find all the bad edits in a flood of edits. I have a flood of edits as well : http://www.openstreetmap.org/user/Nightdive/edits a lot but this doesn't qualify for a flood yet. 60k changesets in 8 months compared to ~1.3m in less than 1.5 months Is this a candidate for the new block feature to stop the bot until it's clearly documented and approved by voting or an other form of agreement? Provide examples, try to communicate with the owner of the bot and if you fail to find a solution with him and the other people agreeing he will be a candidate for a block. there was some communication but never a detailed explanation and documentation. At that time I didn't have an example but John Smith had one. The real problem is now to find out what went wrong, why did it brake and where do we need to fix it. But again my main concern is that users with best indention but not enough knowledge run bots on the whole planet. Every mapper will make mistakes from time to time but it's limited. a bot will multiply each mistake. this needs more than 2 eyes to review the resiks Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] bot vandalism
On 12 Oct 2009, at 24:05 , Frederik Ramm wrote: Apo, I don't know about the specific case you are talking about. But on a more general note, I am sure that we will be seeing stricter rules for bots, where instead of *politely asking* for things to be discussed before the bot runs properly documented, we will in the future *demand* that this is the case and threaten to suspend bot accounts that don't play by the rules, and revert their edits. this is exactly why I raised this again. I don't think that there will be an approval process for bots in the near future (simply because of the manpower required for such approval). we need some process. doesn't have to be formal or same each time. Just a minimum 1 user to make such a risky thing like a bot. If a bot user can't prove this was done and documented it will be blocked on any user request without waiting for feedback to keep damage under control. I am sure there will be at least 5 volunteers to check the concept and code for each bot if it's posted to talk. Still no guarantee but fundamental bugs will be fixed before any big damage. a second step must be a dry run with verification of the changes done. We might also ask bot users to flag the relevant accounts as bot accounts, to allow easier filtering on the user side (I am not interested in changes done by bots). this should be a requirement. maybe we should even monitor accounts for big edits across the planet in short time and block them automatically if they are not approved bot accounts. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] bot vandalism
2009/10/12 Apollinaris Schoell ascho...@gmail.com: I know it has been discussed before but found a lot of broken data created by bot bugbuster and this is important enough to bring it up again. There was some lame response but never really an explanation what this bot is doing. Some edits are correct others are not. There is little information in the wiki that there has been some bug fixes. But how can I know if the bot doesn't break my fixed data again. Should we allow bots at all? Sure if they are useful and documented. But there should be a need to do a quality check and review first before someone is allowed to run a bot against the whole planet. this bot does so many edits and it's very difficult to even find all the bad edits in a flood of edits. Is this a candidate for the new block feature to stop the bot until it's clearly documented and approved by voting or an other form of agreement? I guess this is a good topic for http://lists.openstreetmap.org/pipermail/moderation/. It's worth at least notifying those on that list of this conver -- Matt Williams http://milliams.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Google has dual carriage way where it's not built yet
Martin Koppenhoefer wrote: 2009/10/10 OJ W ojwli...@googlemail.com: multiple plans would overlap each other and look weird? look weird where? I guess these would not be rendered in standard maps (or just in advanced planning phases and for main plans like motorways, airports, etc.). I made a proposal: http://wiki.openstreetmap.org/wiki/Key:planned So what's the difference with highway=proposed + proposed=...? I can't seem to find the wiki page, but highway=proposed is already in use and it's rendered in the Mapnik layer. Greetings Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visual map for the blind
Hi, 2009/10/12 John Smith deltafoxtrot...@gmail.com: 2009/10/12 Lulu-Ann lulu-...@gmx.de: What tag would you use for bus/tram stops with a i button that reads out the information about trams soonest to arrive, aloud? I have never seen those before. Not proposed yet, but I guess many things need explanation, so I would tag it like that: tourism=information information=acoustic_textinformation=acoustic_text description:en:blind=There is an information button that reads out schedule times It doesn't seem like a tourism thing to me, wouldn't they be designed for people that live in the area? Yes, and specifically for those who cannot read text because the same information is displayed real-time on LED screens on top of the same post with the big button. I was thinking more along the lines of tram_stop:voice=schedules Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Instead of voting
On 11/10/2009, at 12:08 AM, Martin Koppenhoefer wrote: This proposal includes the deletion of all voting-related stuff including the casted votes of the past. I'd say that this helps prove the point that different people reading different things into what pages on the wiki say. The proposal wasn't really serious, but I didn't intend it to mean that we would delete all voting-related content from the wiki, only ban new votes. the thing is that not everybody will write a documentation for every key he uses, and in the end (we're already in some tags at this stage), there will be many same tags with different intended meanings. By deleting the voting-process things will get worse. I'm not entirely sure how not having the voting process will make things worse. Instead of having a tag with several different meanings, one of which is approved but may not even be the most common meaning, we'll just have a tag with several different meanings. The voting process doesn't mean that the approved version is what people actually use. If there is a wiki page which describes a tag in a limited way, and I want to document how I've used it, what should I be doing? * edit the main page, which could annoy the people who created the page * add a note to the discussion page, which someone searching the wiki for how to tag things won't read * create a new page describing my version, which leads to conflicting information ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Freemap Mobile (mobile map application): version 3 now available
Hello everyone, TBH I thought I had announced this in June but a quick search of the mailing lists suggest I didn't, must have been too distracted with organising my holiday. Anyway, an updated version (3) of Freemap Mobile, a Java ME based mobile mapping application orientated towards countryside users is now available to download, from http://www.free-map.org.uk/downloads/FreemapMobile/ The latest version is FreemapMobile_r3.zip, which is a source package. A binary version (.jar/.jad) is also available from the same place. Features include: - Ability to display Freemap maps of your current location at 3 zoom levels (13, 14, 16). Note that Freemap maps are only available in England and Wales away from the big cities. - As an alternative to Freemap, you can display standard OSM Mapnik, or Osmarender tiles. This should work internationally. - New Popular Edition maps are available at the middle zoom level (14) - useful for navigation and locating new paths in the field! - You can download nearby points of interest from Freemap's copy of the OSM database. Only features of particular interest to countryside users are downloaded (currently pubs, villages, towns, and hills). This will only work in England and Wales away from big cities, as the data is downloaded from Freemap, not OSM. - You can download Freemap specific data (hazards, path directions) - see below - You can contribute data to Freemap, including hazards (broken stiles, barbed wire, cows etc), path directions and interesting views. This may be a possible jump-off point for the in-the-field countryside surveying tool I talked about a couple of weeks back. - You can write comments on a pub or other point of interest. This data is sendt to Freemap, not OSM (see mailing-list discussions from way back) Credits are available in the source package, so if you download the binary package, please note: * Map tiles are derived from OSM data and are CC-by-SA; * The hourglass icon is (c) Mark James and licenced under Creative Commons (attribution) * Source code is licenced LGPL generally; the MIDlet is licenced under GPL. See the COPYING file in the source distribution. A lot of experimental features, which was really just me exploring the limits of what you can do with Java ME on an N95, have been removed for the moment however, as they were a bit clunky (e.g. photos). However revision 2 of the app retains such features (available from the same site) Also from now on, Footnav tarballs (selected revisions only) will be available to download from the same URL, as well as through Sourceforge SVN. See http://www.free-map.org.uk/downloads/footnav/ Really need to get the freemap blog up and running again. Will update when I have done so. Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Freemap Mobile (mobile map application): version 3 now available
TBH I thought I had announced this in June but a quick search of the mailing lists suggest I didn't, must have been too distracted with organising my holiday. Anyway, an updated version (3) of Freemap Mobile, a Java ME based mobile mapping application orientated towards countryside users is now available to download, from Forgot to say: - only tested on the WTK and on an N95. It may not work on other phones; it requires JSR179 support and XML parsing support. - *USE AT YOUR OWN RISK* !!! This is experimental software and almost certainly has bugs. Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visual map for the blind
What tag would you use for bus/tram stops with a i button that reads out the information about trams soonest to arrive, aloud? I have never seen those before. Not proposed yet, but I guess many things need explanation, so I would tag it like that: tourism=information information=acoustic_text description:en:blind=There is an information button that reads out schedule times It doesn't seem like a tourism thing to me, wouldn't they be designed for people that live in the area? Well, ordinary maps and tactile maps are used by people living in that area, too, but the information tag is placed in tourism. That does not matter, because we can display elements from any namespaces on any map. Regards Lulu-Ann -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Freemap Mobile (mobile map application): version 3 now available
Works very nicely on my N96. Thanks! 2009/10/12 Nick Whitelegg nick.whitel...@solent.ac.uk: TBH I thought I had announced this in June but a quick search of the mailing lists suggest I didn't, must have been too distracted with organising my holiday. Anyway, an updated version (3) of Freemap Mobile, a Java ME based mobile mapping application orientated towards countryside users is now available to download, from Forgot to say: - only tested on the WTK and on an N95. It may not work on other phones; it requires JSR179 support and XML parsing support. - *USE AT YOUR OWN RISK* !!! This is experimental software and almost certainly has bugs. Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] RFC - military boundary for areas used by military
Hi there, For those interested, please have a look at this proposition : http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base It's intended use is to permit the same area to be for example a forest and a military restricted area (while the landuse=military doesn't permit that) Comment on the wiki welcome -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] RFC - military boundary for areas used by military
sly (sylvain letuffe) li...@letuffe.org writes: Hi there, For those interested, please have a look at this proposition : http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base It's intended use is to permit the same area to be for example a forest and a military restricted area (while the landuse=military doesn't permit that) seems somewhat sensible, but it's really a bandaid around serious brokenness about landuse. The notions of what people use land for and what the condition of the land is are massively conflated. Plus, there should be no intrinsic problem with nested uses. pgppZqSrpFsmR.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] licentie op nieuwekaart.nl
Op 11 oktober 2009 22:09 heeft Rejo Zenger osm-talk...@subs.krikkit.nl het volgende geschreven: Het is inmiddels aangepast. Op de kaart staat nu prominent de tekst Data by OpenStreetMap.org contributors under CC BY-SA 2.0 license, met links naar de OpenStreetMap website en de tekst van de licentie. Zie http://www.kaart.nieuwekaart.nl/?page_id=13. Top! Henk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] front end web designer
Hi, Ik ben eigenlijk benieuwd of er op deze mailinglist ook begenadigd front end web designers meelezen. Ik ben op zoek naar mensen die me willen helpen met het ontwerp van een fraaie, OSM gerelateerde, website. Met nadruk gaat het daarbij om de frontend en (ook) om het tikken van de (CSS, HTML, etc) code zelf, niet alleen om het ontwerp. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] front end web designer
Hallo Rejo, Gelet op resultaten op gelijksoortige verzoeken vermoed ik dat het antwoord, zeker als de pecunia achterwege blijven nee is. Herhaaldelijk is er gesproken over het verbeteren van de usability van de openstreetmap websites, herhaaldelijk heb ik hierbij ook geroepen dat het goed zou zijn eens iemand van buiten te halen ZONDER openstreetmap kennis of achtergrond. Misschien komt er wel een compleet nieuw inzicht met betrekking tot het verbeteren van de toegankelijkheid en de drempel van openstreetmap. Ik zou namelijk graag zien dat openstreetmap leden gaat krijgen uit alle gelederen van de bevolking. Momenteel is Henk Hoff in de stichting OpenGeo al voorzichtig stappen op dit gebied aan het zetten, wellicht kan je met hem overleggen om eens te kijken wat jullie voor elkaar kunnen betekenen? Je stelt je vraag in principe al in twee delen, je zoekt iemand om ook te tikken, deze kwaliteiten zijn voldoende aanwezig. Het gaat er nu juist om om eens vanuit usability en design te starten, dan is het voor veel van ons waarschijnlijk relatief eenvoudig om dat om te zetten in een werkende css/html/javascript/php omgeving. Vriendelijke groet, Milo van der Linden Rejo Zenger schreef: Hi, Ik ben eigenlijk benieuwd of er op deze mailinglist ook begenadigd front end web designers meelezen. Ik ben op zoek naar mensen die me willen helpen met het ontwerp van een fraaie, OSM gerelateerde, website. Met nadruk gaat het daarbij om de frontend en (ook) om het tikken van de (CSS, HTML, etc) code zelf, niet alleen om het ontwerp. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] How to tag a non-existent road
John Smith wrote: 2009/10/12 Ross Scanlon i...@4x4falcon.com: If it's from the DCDB data then highway=gazetted_road and don't put anything in the renderer to show them. At the moment it's suggested to use highway=road and I was thinking of doing a special style sheet for mapnik to highlight these sorts of roads so they'd be easier to find to verify, your suggestion would be fine too, but we still need some other tag then to know they don't exist, compared to haven't been checked. They will then show up in the editors and people can then map them using gps etc when able. Once we have figured out what we can submit patches so they show up differently if they don't exist, compared to maybe exist. highway=ghost_road I just made that up... so don't actually use :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Rural Road Numbering...
There has been some discussion on the tagging list about what to do with rural road numbering. For people unaware there was a standard created to renumber rural roads to make it easier for services, especially emergency services, to locate properties. They used decametres (10s of metres) from some arbitary start point, usually from a locality outwards. Odds are always allocated to the left, and even numbers to the right. While this won't be useful for rendering it would be potentially very useful for routing software, since the software just has to know the start point and estimate the approximate distance and then point to the left or right side of the road. Routing software could even be coded to collect all such requests to a central database, or the OSM DB directly to be used for rendering. This numbering scheme is published as an Australian/New Zealand Standard, AS/NZS 4724:2000 Geographic Information – Rural Addressing. Currently I'm thinking we could tag roads as numbering=as/nzs or something similar, and then the only problem then is how to tag the start/end of a numbering section, based on that standard major roads are broken up into sections of 100km. Liz found a document produced by Land Victoria, including some useful tips in section 6 on how councils could renumber properties safely may be useful for us. http://tinyurl.com/yhv7ady ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
On Mon, 12 Oct 2009 00:50:31 +0200, Frederik Ramm frede...@remote.org wrote: Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - Ausnahme die minute-replicate-Diffs - wird langsam inkonsistent, weil prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei so einem Diff (auch Stunden- oder Tagesdiffs). Kannst du das näher erläutern? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, Stephan Knauss wrote: Wo würdest du denn speziell ansetzen um signifikant Zeit gegenüber einem Neuimport zu sparen? Meine Hoffnung stuetzt sich auf zweierlei: Erstens haette ich eine stundenlange Lese-Operation gefolgt von ein paar wenigen Schreiboperationen - ich nehme an, dass die Datenbank die ganze Zeit ueber relativ ungestoert weiter zur Nutzung zur Verfuegung stehen kann, waehrend ein Komplett-Import (selbst wenn er auf einer anderen Datenbankinstanz gemacht wird) die Kiste eher ausbremst. Zweitens wuerde die Index-Erzeugung, die nach meiner Erfahrung mindestens ein Drittel der Planet-Import-Zeit einnimmt, auf ein vernachlaessigbares Mass zusammenschrumpfen. Ich hatte mal mit imports für einzelne Länder gespielt. Da war neu einlesen schneller als Diff einspielen. Da hast Du das Neu-Einlesen dann aber ohne --slim gemacht, oder? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
On Mon, Oct 12, 2009 at 12:22:19AM +0200, Stephan Knauss wrote: Frederik Ramm wrote: Stephan Knauss wrote: select distinct (osm_id*-1) as id, name, name:en as name_en from planet_osm_line where osm_id 0 AND admin_level='2' Da musst du jetzt aber noch diejenigen Relationen herausfiltern, die nur als Subrelationen gebraucht werden, also zum Beispiel #51239 Deutschland - Schweiz. Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? Oder hat es bei mir im Laufe der Zeit mal den Import zerbröselt? Die DB bekommt schon länger nur die Tages-Diffs. Das ist normal. planet_osm_line enthält nur einfache Wege. Wenn eine Relation zerstückelt ist, taucht jedes Teilstück einzeln in planet_osm_line auf. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Hallo, Tirkon wrote: Und demnach liegt dann hier der Casus knacktus, denn die ist eben langsam. Und das ist auch der Grund dafür, dass wir in JOSM mit runtergeladenen Daten statt live arbeiten und die Änderungen nur als rudimentäre Striche, statt beispielsweise in Mapnik Darstellung erscheinen. Um Ulfs Statement hier etwas auszukleiden: Was Du schreibst ist unlogisch, denn der Datenbankserver hat genau gleichviel zu tun, egal, ob ich auf Benutzerseite nur graue Striche oder eine farbenpraechtige Mapnik-Karte darstelle. Das hat also miteinander nichts zu tun. Es waere theoretisch denkbar, einen Editor zu machen, der mit Mapnik rendert - lediglich, wenn Du dann ein Objekt mit der Maus anfasst und Nodes verschiebst, wirst Du davon Abstand nehmen muessen, denn *so* schnell, dass das Rendering live Deiner Maus folgen kann, ist Mapnik dann auch wieder nicht. Ergo konnte der Flaschenhals, dem durch die damalige Spendenaktion für den Server der Foundation begegnet werden sollte, nicht beseitigt werden. Das wird auch nie gelingen. - Es sind aber sehr viele Mischformen denkbar. Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. Leseoperationen koennen durchaus etwas zeitverzoegert von Mirrors kommen. Ein Editor koennte Dir den (schnell zugreifbaren, aber 2 Minuten verzoegerten) Datenstand vom Mirror anzeigen, sobald Du aber eine Aenderung machst, koennte er schnell pruefen, ob das Objekt wirklich noch auf dem zentralen Server unveraendert ist und anderenfalls sagen: Sorry, das Objekt hat gerade eben schon jemand anders geaendert. Sowas kann einem ja auch bei Wikis usw. passieren, die Sache wuerde dadurch nicht unbenutzbar. Also bringt der Strato Server hier auch keine Abhilfe. Der Strato-Server wird bestimmt nicht magisch fuer schnelleres Editieren sorgen, soviel ist sicher. Aber die logische Kette, mit der Du diesen Schluss erreichst, ist nicht ganz stimmig. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, marcus.wolsc...@googlemail.com wrote: Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - Ausnahme die minute-replicate-Diffs - wird langsam inkonsistent, weil prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei so einem Diff (auch Stunden- oder Tagesdiffs). Kannst du das näher erläutern? Osmosis erzeugt die Diffs auf dem zentralen Server aufgrund der History-Tabelle mit einem Query, der alles abfragt, was zwischen zwei Zeitpunkten passiert ist. Aufgrund der Transaktionsisolierung bekommt Osmosis aber nur die Daten, die einen Timestamp im fraglichen Fenster haben UND deren Transaktion schon committed ist. Durch diff-Uploads kann es einige sehr lang laufende Transaktionen geben. Beispiel: Das stuendliche Diff fuer den Zeitraum 13:00-14:00 wird um 14:20 erzeugt und hat alle Daten mit Timestamp 13:00-14:00. Wenn um 12:59 eine Transaktion begonnen wird, die bis 13:21 laeuft, so erscheinen um 13:21 ploetzlich lauter Daten in der Datenbank, die einen Timestamp von 12:59 haben. Diese verpasst das Diff, und sie werden auch im 14:00-15:00-Diff nicht drin sein. Fuer alle anderen Arten von diffs gilt das vergleichbar. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs
On Mon, 12 Oct 2009 09:23:29 +0200, Frederik Ramm frede...@remote.org wrote: Hallo, marcus.wolsc...@googlemail.com wrote: Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - Ausnahme die minute-replicate-Diffs - wird langsam inkonsistent, weil prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei so einem Diff (auch Stunden- oder Tagesdiffs). Kannst du das näher erläutern? Osmosis erzeugt die Diffs auf dem zentralen Server aufgrund der History-Tabelle mit einem Query, der alles abfragt, was zwischen zwei Zeitpunkten passiert ist. Aufgrund der Transaktionsisolierung bekommt Osmosis aber nur die Daten, die einen Timestamp im fraglichen Fenster haben UND deren Transaktion schon committed ist. Durch diff-Uploads kann es einige sehr lang laufende Transaktionen geben. Beispiel: Das stuendliche Diff fuer den Zeitraum 13:00-14:00 wird um 14:20 erzeugt und hat alle Daten mit Timestamp 13:00-14:00. Wenn um 12:59 eine Transaktion begonnen wird, die bis 13:21 laeuft, so erscheinen um 13:21 ploetzlich lauter Daten in der Datenbank, die einen Timestamp von 12:59 haben. Diese verpasst das Diff, und sie werden auch im 14:00-15:00-Diff nicht drin sein. Fuer alle anderen Arten von diffs gilt das vergleichbar. Danke für die Erklährung Frederik. Mir ist da gerade etwas zu eingefallen: Werden die Changeset-IDs linear hochgezählt? Falls ja könnte man die Query so gestalten: Select * from changesets where id [grösste Chageset ID des letzten Laufes] OR id in [alle nicht aufgetauchten changeset IDs in einem geeignetem Intervall] der zweite Teil könnte möglicherweise genau diese Lücken finden. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs
Hallo, marcus.wolsc...@googlemail.com wrote: Werden die Changeset-IDs linear hochgezählt? Ich glaube ja (ist halt eine Postgres-Sequenz). Falls ja könnte man die Query so gestalten: Select * from changesets where id [grösste Chageset ID des letzten Laufes] OR id in [alle nicht aufgetauchten changeset IDs in einem geeignetem Intervall] der zweite Teil könnte möglicherweise genau diese Lücken finden. Grundsaetzlich ja, aber die normalen Diffs gehen nicht nach Changesets, dort werden einfach nodes/ways/relations in einem bestimmten Zeitfenster rausgesucht! Die minute-replicate-Diffs machen es ungefaehr so, wie Du oben beschreiben hast. Die sind relativ neu, einige Hinweise dazu finden sich im Thread hourly diffs are missing edits (too) auf der dev-Liste. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude über Straße
Paul Baumbach schrieb: Hier hab ich ein Beispiel: Das Gebäude 09 der Universität ist als layer 1 getagt. Osmarender kann es korrekt, Mapnik hingegen nicht. http://www.openstreetmap.org/?lat=52.13963lon=11.64197zoom=17layers= 0B00F Verläuft der Weg unter dem Gebäude oder durch das Gebäude? Ich habe nochmal versucht ein gute Bild vom Gebäude zu finden, aber leider war da nichts zu machen. Allerdings geht der Weg auf Höhe der Erdoberfläche durch das Gebäude hindurch. Ahnlich verhält es sich mit der Bibliothek, die etwas weiter östlich auf dem Campus steht. Auch hier verlaufen Wege unter dem Gebäude, allerdings kragt hier ein Teil des Gebäudes heraus (siehe http://tinyurl.com/yf5da2q ). Hier wird es definitv nicht richtig gerendert. Grüße, Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. wenn OSM weiter so rasant wächst, wächst auch die Wartezeit exponentiell. Leseoperationen koennen durchaus etwas zeitverzoegert von Mirrors kommen. Ein Editor koennte Dir den (schnell zugreifbaren, aber 2 Minuten verzoegerten) Datenstand vom Mirror anzeigen, sobald Du aber eine Aenderung machst, koennte er schnell pruefen, ob das Objekt wirklich noch auf dem zentralen Server unveraendert ist und anderenfalls sagen: Sorry, das Objekt hat gerade eben schon jemand anders geaendert. Sowas kann einem ja auch bei Wikis usw. passieren, die Sache wuerde dadurch nicht unbenutzbar. das kann einem auch jetzt schon passieren. aber das kann nur eine Zwischen-Lösung sein Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem lösen können bevor die Wartezeiten so groß werden, dass keiner mehr Lust hat bei OSM mitzumachen Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vereinfachte OSM-Karte Ausdrucken
Hallo, möchte eine Karte meines Wirkungsgebietes auf einem Tintenstrahldrucker (A4) vereinfacht ausdrucken, so dass nur die Linien dargestellt ausgedruckt werden (Tinte sparen). Straßennamen usw. sind nicht notwendig. Diesen Ausdruck möchte ich verwenden, um z. B. Hausnummern und POI's auf dem Ausdruck einzutragen, um sie später am Rechner in die Datenbank einzupflegen. Der Ausschnitt und der Zoomfaktor sollten wählbar sein. Gibt es dafür schon eine Anwendung (OS Vista 32bit)? Gruß Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vereinfachte OSM-Karte Ausdrucken
Am 12.10.2009 um 10:58 schrieb dieter jasper dieter_jas...@web.de: Hallo, möchte eine Karte meines Wirkungsgebietes auf einem Tintenstrahldruc ker (A4) vereinfacht ausdrucken, so dass nur die Linien dargestellt ausgedruckt werden (Tinte sparen). Straßennamen usw. sind nicht notw endig. Diesen Ausdruck möchte ich verwenden, um z. B. Hausnummern und POI's auf dem Ausdruck einzutragen, um sie später am Rechner in die Datenbank einzupflegen. Der Ausschnitt und der Zoomfaktor sollten wählbar sein. Gibt es dafür schon eine Anwendung (OS Vista 32bit)? Entweder schaust du bei walking-papers.org vorbei oder du nutzt Kosmos und nutzt einen einfachen Style aus dem Wiki oder erstellst einen eigenen. Gruß Jonas Gruß Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vereinfachte OSM-Karte Ausdrucken
Jonas Krückel schrieb: Gibt es dafür schon eine Anwendung (OS Vista 32bit)? Entweder schaust du bei walking-papers.org vorbei Danke, genau so etwas habe ich gesucht. oder du nutzt Kosmos und nutzt einen einfachen Style aus dem Wiki oder erstellst einen eigenen. Gruß Jonas Gruß Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM case sensitiv?
Hi, sehe ich das richtig dass OSM generell case sensitiv ist, sowohl für Tags als auch für Werte ? Also oneway=yes ist was anderes als Oneway=yes und oneway=YES, etc. ? Ich stolpere nämlich gerade über die verschiedenen Schreibweisen von maxspeed=DE:urban (de:urban, DE:Urban, De:urban, De:Urban)... Grüße Chris :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Hallo, Josias Polchau wrote: Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. Die Schreib-Last ist doch aber nur ein Bruchteil von der Lese-Last. Wenn unsere Tools die Leseoperationen besser trennen - auch JOSM koennte doch problemlos von einem leicht verzoegerten nur-Lese-Mirror lesen statt von der Zentrale - dann kann die zentrale Datenbank die Schreiblast noch eine ganze Weile aushalten. Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem lösen können Es ist nichts dagegen einzuwenden, dass Leute darueber nachdenken, wie sie die Schreibanforderungen auf mehrere Datenbanken verteilen koennen. Ich glaube nur nicht, dass viel bei herauskommt. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Hallo, Josias Polchau wrote: Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. Die Schreib-Last ist doch aber nur ein Bruchteil von der Lese-Last. Wenn unsere Tools die Leseoperationen besser trennen - auch JOSM koennte doch problemlos von einem leicht verzoegerten nur-Lese-Mirror lesen statt von der Zentrale - dann kann die zentrale Datenbank die Schreiblast noch eine ganze Weile aushalten. In der Richtung kann man mit Sicherheit dann auch noch mehr tricksen. Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem lösen können Es ist nichts dagegen einzuwenden, dass Leute darueber nachdenken, wie sie die Schreibanforderungen auf mehrere Datenbanken verteilen koennen. Ich glaube nur nicht, dass viel bei herauskommt. Insbesondere da die Leute, die in diesem Bereich wirklich die Arbeit machen (und die durchaus wissen was sie tun) hier eh nicht mitlesen :-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
On Mon, Oct 12, 2009 at 11:58:43AM +0200, Chris-Hein Lunkhusen wrote: sehe ich das richtig dass OSM generell case sensitiv ist, sowohl für Tags als auch für Werte ? Also oneway=yes ist was anderes als Oneway=yes und oneway=YES, etc. ? Ja, richtig. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Original-Nachricht Datum: Mon, 12 Oct 2009 10:53:34 +0200 Von: Josias Polchau sp...@youseeus.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Strato sponsort 3 Server für OSM Hallo, das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. Na ja, mal schaun. wenn OSM weiter so rasant wächst, wächst auch die Wartezeit exponentiell. Solange die Maschine nicht am Limit kraechtzt, ist eher ein lineares Problem. Fruehere Engpaesse wurden wohl hauptsaechlich mit internen Verfeinerungen (Quadtrees, etc.) behoben. Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem lösen können bevor die Wartezeiten so groß werden, dass keiner mehr Lust hat bei OSM mitzumachen Ein paar machen schon noch mit ;) Loesungsanseatze gabs schon immer, z.B. die Regionalisierung der DB. Der amerikanische Kontinent ist ja dank Massenimport einer der groessten Brocken, hat aber wenig verbindung mit dem Rest der Welt und waere damit ein guter Testkandidat. Ich denke auch, dass sich bei Datenorganisation und API noch einiges machen liesse. Dass z.B. alle Nodes gleich behandelt werden, egal ob die als POI Attribute abbilden, oder nur als Stuetznodes fungieren, macht die Arbeit mit der API z.B. auch nicht einfacher. Ein Satz von effizienten Basiselementen wie Flaechen und Polygone, auf die man ohne Umweg ueber die Nodes zugreifen kann, koennte so einiges vereinfachen. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Chris-Hein Lunkhusen schrieb: Ich stolpere nämlich gerade über die verschiedenen Schreibweisen von maxspeed=DE:urban (de:urban, DE:Urban, De:urban, De:Urban)... Das ist die übliche Verwirrung zwischen Sprach- und Länderkürzeln, siehe auch http://de.wikipedia.org/wiki/ISO_3166#Geographische_.28ISO_3166.29_und_sprachliche_.28ISO_639.29_Einteilung DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland gültigen Dingen, wie eben deinem Beispiel. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Tobias Knerr schrieb: DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland gültigen Dingen, wie eben deinem Beispiel. Also ist DE:Kommunikation auch falsch? Demnach müsste es ja eigentlich de:communication heißen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Tobias Wendorff schrieb: Tobias Knerr schrieb: DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland gültigen Dingen, wie eben deinem Beispiel. Also ist DE:Kommunikation auch falsch? Demnach müsste es ja eigentlich de:communication heißen. Ich nehme an, du sprichst vom Wiki? Für die meisten Seiten ist die Benennung der Namensräume dort tatsächlich nicht mit dieser Norm konform; nämlich dort, wo es sich bei den DE:*-Seiten (wie meist der Fall) um reine Übersetzungen handelt, und nicht um Übertragungen auf die hiesigen Verhältnisse. Gerade bei DE:Kommunikation liegt aber eher der Fall vor, dass es tatsächlich (nach einem kurzen Blick jedenfalls) um Kommunikation mit Datenspendern in Deutschland (im deutschsprachigen Raum?) geht. Es ist auch zu bedenken, dass Seitentitel in einem MediaWiki nicht mit Kleinbuchstaben anfangen können. Trotzdem ist mir nicht ganz klar, warum auf DE: statt De: vereinheitlicht wurde - letzteres kam früher nämlich durchaus auch vor. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Hallo, Josias Polchau wrote: Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. Die Schreib-Last ist doch aber nur ein Bruchteil von der Lese-Last. Wenn unsere Tools die Leseoperationen besser trennen - auch JOSM koennte doch problemlos von einem leicht verzoegerten nur-Lese-Mirror lesen statt von der Zentrale - dann kann die zentrale Datenbank die Schreiblast noch eine ganze Weile aushalten. wenn ich es richtig verstanden hab geht es also um das schnelle Ausliefern von Informationen, die sehr klar eingegrenzt werden können, oder? also eine Weiterentwicklung der XAPI? die XAPI wurde von 80n entwickelt Xapi source code uses GT.M a high-performance schemaless database. warum wurde keine geo DB genommen? damit schneller logische Operationen ausgeführt werden können? http://xapi.openstreetmap.org/scripts/ anscheinend ist es in Pascal geschrieben (hatte das eigentlich anders in Erinnerung) letztendlich ist die Programmiersprache ja egal, wenn entsprechend gute DB abfragen gestellt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Hallo, Josias Polchau wrote: wenn ich es richtig verstanden hab geht es also um das schnelle Ausliefern von Informationen, die sehr klar eingegrenzt werden können, oder? Ja. Erschwerend kommt hinzu, dass wir fuer sehr viele Anwendungen diese Informationen im topologisch sauberen OSM-Modell ausliefern wollen und *nicht* in Form von Standardgeometrien. Das heisst, wir wollen schoen ordentlich alle betroffenen Nodes, Ways und Relations haben und nicht einfach eine in die Landschaft gezeichnete Linie. Auf letzteres sind die einschlaegigen Geodatenbanken aber in der Regel spezialisiert. In der API sieht eine typische gib mir alles in diesem Bereich-Anfrage so aus: 1. Suche alle Nodes in diesem Bereich. Geht schnell, kann aber schon mal einige zigtausend Nodes ergeben. 2. Suche alle Ways, in denen irgendwo einer von diesen Nodes vorkommt. 3. Suche alle Nodes aus den in Schritt 2 gefundenen Ways; vergleiche die Liste mit der Liste aus 1; fuege all jene hinzu, die noch nicht drin waren 4. Suche alle Relationen, die einen der Nodes oder Ways aus 1/2/3 enthalten Insgesamt ist das halt eine nicht ganz primitive Operation. also eine Weiterentwicklung der XAPI? Oder eine Weiterentwicklung der API, koennte man genauso sagen. die XAPI wurde von 80n entwickelt Xapi source code uses GT.M a high-performance schemaless database. warum wurde keine geo DB genommen? Erstens ist eine geo DB nicht unbedingt besser (s.o.), zweitens gilt bei OSM ja wer das Programm schreibt, darf entscheiden, und 80n hat sich fuer M entschieden, eine Datenbankprogrammiersprache aus dem medizinischen Bereich, die deutlich aelter als SQL ist. anscheinend ist es in Pascal geschrieben Irrtum. letztendlich ist die Programmiersprache ja egal, wenn entsprechend gute DB abfragen gestellt werden. Die Programmiersprache ist dann egal, wenn genuegend Leute die gewaehlte Sprache gut beherrschen *oder* der Programmierer auf absehbare Zeit willens und in der Lage ist, jede Anpassung und sonstige Arbeit am Code selbst vorzunehmen. Beim XAPI haben wir zum Beispiel genau das Problem - es gibt Engpaesse, aber es gibt auf der ganzen Welt nur eine Person, die sich mit dem Einsatz der Programmiersprache M speziell fuer OSM-Daten beschaeftigt hat. Das ist knapp. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Hallo, Frederik Ramm schrieb: Insgesamt ist das halt eine nicht ganz primitive Operation. und wenn man diese Operationen auf geographischer Ebene verteilen würde, soweit es geht? Abfragen über ganz Deutschland oder Europa sollten dann gleich unterbunden werden. Auch wäre es vielleicht sinnvoll, Anfragen ab einer bestimmten Anzahl von Nodes schon bei der Überschreitung eines Wertes bei den Inner-Selects abzubrechen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reminder: OSM-Vortrag in Zürich am 13.10.
Hallo Liste, nicht vergessen: OpenStreetMap - die freie Landkarte und Geodatenbank - Dienstag, 13. Oktober Warum OpenStreetMapper mit GPS Empfängern durch die Gegend laufen und die Weltkarte neu zeichnen. Von Andreas Brauchli, OpenStreetMap. Die Kurzvorträge beginnen jeweils um 17.15 Uhr. Danach DJ-Set mit Creative Commons lizenzierter Musik. Ort: bQm, unter der Polyterrasse, Leonhardstrasse 34, 8092 Zürich Veranstalter: [project 21] - studentische Organisation für nach- haltige Entwicklung der Uni und ETH Zürich Weitere Infos unter www.project21.ch/cc-bqm Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Und das ist auch der Grund dafür, dass wir in JOSM mit runtergeladenen Daten statt live arbeiten tun wir doch mit Potlatch (bzw. angeblich tun einige das ;) und die Änderungen nur als rudimentäre Striche, statt beispielsweise in Mapnik Darstellung erscheinen. Dann werf mal nen Blick auf http://www.merkaartor.org/ :) Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reminder: OSM-Vortrag in Zürich am 13.10.
nicht vergessen: [Vortrag in Zürich] Ups, das sollte eigentlich an die Schweizer Liste gehen. Nujo, vielleicht ist ja morgen jemand per Zufall in Zürich.. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ATMEL-Programmierer für OSM-Projekt g esucht
Hallo Community, gibt es hier vielleicht Mitglieder, die Software für ATMEL-Chips (ATmega88) programmieren können (C etc.)? Es handelt es sich um einen sehr genauen barometrischen Höhenmesser für OpenStreetMap, der vor einigen Wochen angeplant wurde. Schaltpläne und Bauteile sind schon vorhanden, Platinenfertiger stellt kostenlose Prototypen bereit - nur die Software für den ATMEL fehlt noch (Linux- und Windows-Software sind kein Problem). Würde mich über PMs freuen, ggf. kann ich eine eigene Mailingliste einrichten. Mehr Details dann dort, weil Off-Topic. Viele Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Hallo, Josias Polchau wrote: wenn ich es richtig verstanden hab geht es also um das schnelle Ausliefern von Informationen, die sehr klar eingegrenzt werden können, oder? Ja. Erschwerend kommt hinzu, dass wir fuer sehr viele Anwendungen diese Informationen im topologisch sauberen OSM-Modell ausliefern wollen und *nicht* in Form von Standardgeometrien. Das heisst, wir wollen schoen ordentlich alle betroffenen Nodes, Ways und Relations haben und nicht einfach eine in die Landschaft gezeichnete Linie. Auf letzteres sind die einschlaegigen Geodatenbanken aber in der Regel spezialisiert. In der API sieht eine typische gib mir alles in diesem Bereich-Anfrage so aus: [..] das ist die geo-Herangehensweise. eine weitere nötige Operation ist das Finden aller Knoten mit dem Tag XY und natürlich auch anders herum Wenn sowohl das Gebiet (ist ja meist der fall) als auch die tags eingeschränkt sind müsste das Programm so intelligent sein, heraus zu finden, welches der beiden die Auswahl am meisten einschränkt... also zb bei den Babyklappen in Deutschland sollte das prog natürlich erst mal alle Babyklappen suchen und erst später regional einschränken. http://osm.youseeus.de/osmolt/babyklappe/deutschland/ Bei Straßen würde man natürlich zuerst nach Gebiet einschränken. Insgesamt ist das halt eine nicht ganz primitive Operation. also eine Weiterentwicklung der XAPI? Oder eine Weiterentwicklung der API, koennte man genauso sagen. die XAPI wurde von 80n entwickelt Xapi source code uses GT.M a high-performance schemaless database. warum wurde keine geo DB genommen? Erstens ist eine geo DB nicht unbedingt besser (s.o.), zweitens gilt bei OSM ja wer das Programm schreibt, darf entscheiden, und 80n hat sich fuer M entschieden, eine Datenbankprogrammiersprache aus dem medizinischen Bereich, die deutlich aelter als SQL ist. älter ist ja nicht immer besser (bei Informatik eher andersrum ^^) Die Programmiersprache ist dann egal, wenn genuegend Leute die gewaehlte Sprache gut beherrschen *oder* der Programmierer auf absehbare Zeit willens und in der Lage ist, jede Anpassung und sonstige Arbeit am Code selbst vorzunehmen. MUMPS ist ja wirklich schwer zu lesen, und ich weiß nicht, ob sich wirklich später jemand findet den code zu warten. ^^ Beim XAPI haben wir zum Beispiel genau das Problem - es gibt Engpaesse, aber es gibt auf der ganzen Welt nur eine Person, die sich mit dem Einsatz der Programmiersprache M speziell fuer OSM-Daten beschaeftigt hat. Das ist knapp. ich würd ja Java vorschlagen, weil ich das sehr gut kann, und C++ nicht wirklich mag Skripsprachen scheinen mir nicht effizient genug (ich weiß Java auch nicht.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Hi, Josias Polchau wrote: ich würd ja Java vorschlagen, weil ich das sehr gut kann, und C++ nicht wirklich mag Skripsprachen scheinen mir nicht effizient genug (ich weiß Java auch nicht.) Ich habe meine eigenen Vorlieben, aber es ist wirklich so, wie ich oben schrieb: Wer eine gescheite Software programmiert, der darf aussuchen, welche Sprache er dazu benutzt. Und wer nichts programmiert, der darf auch anderen nicht reinreden ;-) Wobei man fairerweise schon gestehen muss: Waere die XAPI in Ruby geschrieben gewesen, dann haette sie vielleicht schon lang den Weg auf die zentralen Server gefunden... aber welcher von den Admins bindet sich schon gern was ans Bein, wo er im Krisenfall nicht in der Lage ist, mal selber was zu reparieren... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Frederik Ramm wrote: Meine Hoffnung stuetzt sich auf zweierlei: Erstens haette ich eine stundenlange Lese-Operation gefolgt von ein paar wenigen Schreiboperationen - ich nehme an, dass die Datenbank die ganze Zeit ueber relativ ungestoert weiter zur Nutzung zur Verfuegung stehen kann, waehrend ein Komplett-Import (selbst wenn er auf einer anderen Datenbankinstanz gemacht wird) die Kiste eher ausbremst. Wie findest du Leichen in der DB? Du müsstest dir ja zu jedem Eintrag merken ob er noch gültig ist, oder nicht. Wenn du von einem Planet File ausgehst findest du recht einfach die geänderten und die neuen Einträge. Vielleicht nur die IDs speichern, die gefunden wurden? Und später ein SELECT per EXCEPT drüber? Im schlimmsten Fall ein SeqScan pro Tabelle. Zweitens wuerde die Index-Erzeugung, die nach meiner Erfahrung mindestens ein Drittel der Planet-Import-Zeit einnimmt, auf ein vernachlaessigbares Mass zusammenschrumpfen. Wodurch wird denn die Indexerzeugung gestartet VACUUM ANALYZE? Ich hatte mal mit imports für einzelne Länder gespielt. Da war neu einlesen schneller als Diff einspielen. Da hast Du das Neu-Einlesen dann aber ohne --slim gemacht, oder? Ja. Das brauche ich ja nur wenn ich updaten will oder der Speicher knapp wird. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs
Frederik Ramm wrote: Die minute-replicate-Diffs machen es ungefaehr so, wie Du oben beschreiben hast. Die sind relativ neu, einige Hinweise dazu finden sich im Thread hourly diffs are missing edits (too) auf der dev-Liste. Ich habe das mal ausprobiert, läuft ganz gut. Auf dem Server werde ich das wohl so verwenden. Für meine Workstation daheim finde ich es etwas unpraktisch. Der Rechner ist über Nacht aus, dann bin ich ein paar Stunden arbeiten. Dann ist es doch wieder ein größeres Stück das fehlt. Da würden Stunden-Diffs auch reichen. Eventuell wären die auch ein wenig kleiner. Ist bekannt ob es wenn die Minutendiffs rund laufen das auch für Stunden/Tage geben wird? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Sarah Hoffmann wrote: select distinct (osm_id*-1) as id, name, name:en as name_en from planet_osm_line where osm_id 0 AND admin_level='2' Da musst du jetzt aber noch diejenigen Relationen herausfiltern, die nur als Subrelationen gebraucht werden, also zum Beispiel #51239 Deutschland - Schweiz. Schade. Dann wird es wohl nicht ohne Handarbeit gehen. Die Liste kann zumindest als Ausgangspunkt dienen. Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? Das ist normal. planet_osm_line enthält nur einfache Wege. Wenn eine Relation zerstückelt ist, taucht jedes Teilstück einzeln in planet_osm_line auf. Klingt einleuchtend. Da hätte ich auch selbst drauf kommen können. Vielen Dank für die Erklärung. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Tobias Knerr wrote: DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland gültigen Dingen, wie eben deinem Beispiel. Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung. Brauchen wir diese Freiheit wirklich? Es gibt sicher genügend Beispiele bei denen es sinnvoll sein könnte. Und eben so viele warum eben nicht. Hier kann man auch prächtig seine Meinung dazu haben. Siehe die Diskussion letztens um die Übersetzungstabelle von Steve. Lass uns lieber mit etwas einfachem beginnen. Wenn wir mal so weit sind, dass wir mit einfachen keys das nicht mehr abbilden können dann können wir immer noch das lockern. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude über Straße
Hallo Martin, (1) Es gibt Gebäude, die wirken eher wie eine Brücke über eine Strasse. Z. B. Autobahn-Raststätten: http://upload.wikimedia.org/wikipedia/commons/7/78/Bridge_service_area_Frankenwald.jpg (Es sieht aus, als hätte man das Gebäude drüber gelegt) es sieht nicht nur so aus, es ist so. Ja, meine Aussage war da sehr verkürzt.. (2) Es gibt Strassen, die wirken eher wie Tunnels durch ein Gebäude. Z. B. Einkaufs-Passagen: http://sanasol.de/galleries/ladenpassage/web/ladenpassage2.jpg (Es sieht aus, als hätte man aus dem Gebäude etwas herausgenommen) aha? Du findest, das sieht so aus, als hätte jemand was aus dem Gebäude herausgenommen? Abgesehen davon, dass ich schon einen Unterschied sehe zwischen Erde und einem Gebäude, finde ich pers. auch nicht, dass es so aussieht. Ich finde es sieht so aus, als hätte jemand das Gebäude so gebaut, dass es einen Durchgang gibt. Wieder verkürzt. Das Gebäude wurde nicht über die Passage geplant, sondern als Quader und dann hat der Architekt ein Loch ins Modell gesägt und gesagt: Hier führt die Passage durch. (3) Es gibt Tunnels, die wurden nicht gegraben und sind nicht unter der Erdoberfläche: http://www.blogwiese.ch/archives/33 http://osm.org/go/0CZ9B7IAO-?layers=B000FFF Ich vermute mal, dass das im eigentlichen Sinn kein Tunnel ist, sondern eine Einhausung der Strecke. Meinetwegen könnte man solche Spezialfälle evtl. auch als Tunnel taggen, da der Unterschied hier wirklich nicht riesig ist (allerdings ist das Teil z.B. ein Hindernis, das mal nicht so ohne weiteres queren kann, während ein Tunnel in Querrichtung normalerweise kein Hindernis darstellt. Guter Einwand! Aber auch wenn auf beiden Seiten Erde aufgeschüttet wird, so dass man über den Tunnel hinweg spazieren kann, liegt der Tunnel für mich gefühlt nicht unter der Erdoberfläche. Ich schreibe extra wirken, denn ein normaler OSMler ist weder exakter Wissenschaftler noch DIN-auswendig-Könner. das ist auch beides nicht nötig, es reicht, es im Wiki klar zu machen, was ein Tunnel ist. Übrigens würde m.E. fast kein Mensch ausserhalb von OSM auf die Idee kommen, eine Ladenpassage Tunnel zu nennen. Es sind ja auch nur diejenigen _innerhalb_ OSM wichtig. ;-) Was ist eigentlich eine Unterführung für Dich? Laut Wikipedia zählen Unterführungen nicht zu den Tunnels.. Vorallem bei so Allerweltswörtern wie Tunnel oder Brücke kommt der nämlich gar nicht auf die Idee, dass die Begriffe irgendwie normiert sein könnten. wie gesagt: eine Durchfahrt oder Passage wird kaum jemand Tunnel nennen. Hm, ja.. eine gedeckte Einfahrt zum Innenhof würde ich nicht Tunnel nennen.. Passagen aber irgendwie schon.. Ich finde deshalb, die Grund-Keys sollten so einfach wie möglich sein - wer's genauer ausdrücken will, kann zusätzliche Keys verwenden. +1. Die Straße/der Durchgang könnte also z.B. im Passagenfall wie eine normale Straße/Weg getaggt werden, und wer darstellen will, dass es im Gebäude ist, der wählt dafür einen Extratag, der dieses ausdrückt. Tunnel hat damit nichts zu tun. So meinte ich das eigentlich nicht. :) tunnel steht für mich sinnbildlich für es geht nur nach vorne oder hinten raus, links/rechts/oben ist's zu, darum würde ich solche Stellen auch allgemein mit tunnel=yes tagen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Ulf Lamping ulf.lamp...@googlemail.com wrote: Erstmal Danke an Dich und die Anderen, die meine Fragen so ausführlich beantworten. Oft freue ich mich auch über diejenigen, welche meine Fragen weitergehend diskutieren, denn daraus erwachsen Antworten, zu denen ich nicht einmal die Frage kannte. P.S: Wieso fragst du eigentlich? Ich möchte meine Antwort mit ein paar Gegenfragen einleiten: Es war einmal eine Zeit ohne Computer. Niemand hätte sich im Geringsten etwas wie Google Maps oder gar OSM vorstellen können. Und ich stellte mir die Frage: Warum trabe und fahre ich einer Straße in Bau nach, nur um zu wissen, wo entlang und wohin sie führt. Warum fahre ich mit einer Bahn, nur um zu wissen, wo ihre Endhaltestelle ist. Warum versuche ich den Unterschied zwischen einer Autobahn und einer autobahnähnlichen Straße zu ergründen? Warum hinterfrage ich Straßen und ÖPNV, obwohl ich damit die anderen Verkehrsteilnehmer aufhalte? Warum nutze ich die Straßen und den ÖPNV nicht wie diese, um von A nach B kommen, sondern um Ihrer selbst willen? Heute kenne ich die Antwort: OSM! ;-) Dir ist schon bewußt, daß du andere von der Arbeit abhälst? Tut das nicht jeder, der hier fragt? Jeder, der hier antwortet, wird wissen, warum er dies tut, möglicherweise aus Transparenzgründen. Meine Fragen waren aus Interesse an den Möglichkeiten und Grenzen von OSM gestellt. Im konkreten Fall denke ich schon, dass sich so mancher fragt, warum der Aufbau einer Seite beim Navigieren in Potlatch mitunter Minuten dauert. Manchmal befördert dieses lange Andauern sogar den Firefox ins Jenseits. Und das nicht nur an meinem Computer und meinem DSL Anschluss. Die Antwort macht transparent, warum das trotz den entgegengesetzen Erwartungen bezüglich des neuen Servers so ist, und weckt sicher nicht nur bei mir Verständnis dafür. Ich denke, dieser Zustand ist besser, als wenn sich jemand wutschnaubend über die da oben oder über ein unpersonifiziertes OSM ausläßt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Ancora su ordinamento alfabetico
Per l'ordinamento alfabetico destinato ad esempio agli stradari come siamo rimasti? Facciamo un esperimento su un paese completamente mappato? Nel caso io mi offro, oppure meglio discutere la cosa in ambito internazionale? Iin questo caso c'è qualcuno che lo fa? Io non posso contare sul mio inglese per una cosa così articolata e piena di eccezioni. Luigi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] alpine_hut e shelter nei render
2009/10/11 Martin Koppenhoefer dieterdre...@gmail.com: al momento in talk c'è una discussione per non fare i shelter più vedere al Z13, mi ricordo che qui c'erano persone a chi importa... anche questa pagina è stata nominata: http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings Qualcuno sa quanto siano ufficiali le nuove proposte? Vedo che tourism=alpine_hut è rimasto (meno male) ma l'impatto maggiore è la ridefinizione di amenity=shelter. In precedenza (http://wiki.openstreetmap.org/wiki/Proposed_features/Shelter it could also be used for a Bothy or small alpine huts) shelter era usato anche per i bivacchi, e questo è il motivo per cui è visibile a Z13. Quando ho importato i bivacchi della Valle d'Aosta (più di 50) li ho taggati amenity=shelter. Mi dispiacerebbe che sparissero dalla mappa. D'altra parte potrei ri-taggarli, anche se mi piacerebbe che 1. il nuovo tag che scelgo sia ufficiale, cioè non cambi di nuovo in futuro 2. la mappa li visualizzi a Z13 come fa ora per gli shelter 3. (bonus) sia sufficientemente ufficiale da essere supportato dagli utenti di OSM, come la OpenHikingMap e le varie conversioni in formato Garmin Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ancora su ordinamento alfabetico
2009/10/12 Luigi Chiesa lchi...@tiscalinet.it: Facciamo un esperimento su un paese completamente mappato? Nel caso io mi offro, oppure meglio discutere la cosa in ambito internazionale? La mia proposta era di prendere l'ottimo stradario realizzato per i comuni italiani e modificarne il codice in modo da appoggiarsi dapprima alla nuova chiave sort_name (o sort_key o altro che decidiamo), quindi di mettere mano ad un paese già mappato e piccolo (es. Storo) per vedere se l'approccio funziona o emergono bug imprevisti. Idealmente l'algoritmo dello stradario andrebbe comunque reso più intelligente in modo da indovinare, per le vie a cui manca la nuova chiave, un probabile ordinamento. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Editor semitestuale
Il 10/10/2009 02:53, Carlo Stemberger ha scritto: Il 09/10/2009 23:43, David Paleino ha scritto: Si accettano proposte per il nome OSMartEditor: the OSM smart editor OSMart: come sopra ma più in breve. -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ancora su ordinamento alfabetico
Anche io pensavo ad un test come quello proposto da Federico. Penso sia possibile inserire su Storo i tag sort_name (dove necessari) poi nell'applicativo dello stradario potrei importare questi valori nel db e, dove presenti, usarli per l'ordinamento. Dopo averla testata potremmo proporre la key in maniera ufficiale. Penserei inoltre di creare, in fase di import, una tabelle unica di codifica tra name e sort_name da cui andare a pescare i sort_name nei casi in cui questo manca. Ad esempio se a Storo ho Via Giuseppe Mazzini - Mazzini Giuseppe, Via ed a Pisa ho Via Giuseppe Mazzini senza sort_name potrei forzare lo stradario ad usare Mazzini Giuseppe, Via anche a Pisa. Controindicazioni? Purtroppo non ho tanto tempo da dedicare allo stradario, pensavo, appena ho tempo, di mettere tutto su un svn per poterci lavorare in gruppo. Ciao, Diego 2009/10/12 Federico Cozzi f.co...@gmail.com 2009/10/12 Luigi Chiesa lchi...@tiscalinet.it: Facciamo un esperimento su un paese completamente mappato? Nel caso io mi offro, oppure meglio discutere la cosa in ambito internazionale? La mia proposta era di prendere l'ottimo stradario realizzato per i comuni italiani e modificarne il codice in modo da appoggiarsi dapprima alla nuova chiave sort_name (o sort_key o altro che decidiamo), quindi di mettere mano ad un paese già mappato e piccolo (es. Storo) per vedere se l'approccio funziona o emergono bug imprevisti. Idealmente l'algoritmo dello stradario andrebbe comunque reso più intelligente in modo da indovinare, per le vie a cui manca la nuova chiave, un probabile ordinamento. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ancora su ordinamento alfabetico
2009/10/12 Diego Guidotti - Aedit s.r.l. guido...@aedit.it: Anche io pensavo ad un test come quello proposto da Federico. Penso sia possibile inserire su Storo i tag sort_name (dove necessari) poi nell'applicativo dello stradario potrei importare questi valori nel db e, dove presenti, usarli per l'ordinamento. Dopo averla testata potremmo proporre la key in maniera ufficiale. Anch'io sono d'accordo con me :-) Propongo questo approccio a la Karlsruhe Schema, cioè facciamo qualcosa di unilaterale e poi, quando / se funziona, lo proponiamo in lista. E' vero che aggiriamo il processo decisionale di OSM, ma in questo caso rischieremmo di rimanere bloccati con problemi internazionali (concetto di ordinamento in lingue non occidentali, Unicode e compagnia...). Penserei inoltre di creare, in fase di import, una tabelle unica di codifica tra name e sort_name da cui andare a pescare i sort_name nei casi in cui questo manca. Ad esempio se a Storo ho Via Giuseppe Mazzini - Mazzini Giuseppe, Via ed a Pisa ho Via Giuseppe Mazzini senza sort_name potrei forzare lo stradario ad usare Mazzini Giuseppe, Via anche a Pisa. Controindicazioni? Idea eccellente, che unisce l'approccio dati nel database con l'approccio ordinamento in una tabella esterna proposto da Luca Delucchi e altri. In questo modo metto la sort_key vicino ai dati a cui si riferisce (vantaggio dell'approccio nel database) ma torna utile anche per altre vie (vantaggio dell'approccio con tabella esterna) e inoltre si può fare l'override di eventuali omonimie dell'approccio con tabella esterna (ad es. vie con lo stesso nome in comuni diversi che devono essere ordinate diversamente). Purtroppo non ho tanto tempo da dedicare allo stradario, pensavo, appena ho tempo, di mettere tutto su un svn per poterci lavorare in gruppo. Grazie, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ancora su ordinamento alfabetico
Concordo, definiamo come fare la prova così cominciamo. Come tag non sarebbe meglio name:sort=Mazzini Giuseppe, Via Per le eccezioni bisognerà discuterne man mano che si presentano e crearne una lista (ad esempio Dante Alighieri lo indicizzereste sotto la D oppure la A?). In questo caso il database delle vie risolverebbe la questione. Luigi - Original Message - From: Diego Guidotti - Aedit s.r.l. To: openstreetmap list - italiano Sent: Monday, October 12, 2009 5:50 PM Subject: Re: [Talk-it] Ancora su ordinamento alfabetico Anche io pensavo ad un test come quello proposto da Federico. Penso sia possibile inserire su Storo i tag sort_name (dove necessari) poi nell'applicativo dello stradario potrei importare questi valori nel db e, dove presenti, usarli per l'ordinamento. Dopo averla testata potremmo proporre la key in maniera ufficiale. Penserei inoltre di creare, in fase di import, una tabelle unica di codifica tra name e sort_name da cui andare a pescare i sort_name nei casi in cui questo manca. Ad esempio se a Storo ho Via Giuseppe Mazzini - Mazzini Giuseppe, Via ed a Pisa ho Via Giuseppe Mazzini senza sort_name potrei forzare lo stradario ad usare Mazzini Giuseppe, Via anche a Pisa. Controindicazioni? Purtroppo non ho tanto tempo da dedicare allo stradario, pensavo, appena ho tempo, di mettere tutto su un svn per poterci lavorare in gruppo. Ciao, Diego ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ancora su ordinamento alfabetico
Vedo con piacere che il comune si Storo viene indicato come cavia per l'ordinamento alfabetico dei nomi delle vie e mi sta bene. Un dettaglio. Ho mappato anche parecchie strade di montagna e ubbidendo al blocco di JOSM che invita a mettere il nome a tutte le strade ho scelto di chiamare strada le strade forestali di montagna cui segue di solito il nome della località (a volte preceduto da preposizioni del tipo «strada per val Lorina») o il nome di due località collegate dalla strada (strada malga Spina Marigole), per distinguerle dalle via dello stradario ufficiale. Lo stradario ufficiale ha le sue complicazioni: con un'apposita delibera (la numero 25 del 2008: http://www.comune.storo.tn.it/delibere2008/g08_025.htm) la giunta comunale è riuscita a togliere le virgolette nelle denominazioni ufficiali spiegando alla commissione provinciale che i caratteri speciali possono portare complicazioni alla gestione informatica, ma non è stato possibile togliere apostrofi e lettere accentate interne alle parole. Giovanni Berti - Original Message - From: Diego Guidotti - Aedit s.r.l. To: openstreetmap list - italiano Sent: Monday, October 12, 2009 5:50 PM Subject: Re: [Talk-it] Ancora su ordinamento alfabetico Anche io pensavo ad un test come quello proposto da Federico. Penso sia possibile inserire su Storo i tag sort_name (dove necessari) poi nell'applicativo dello stradario potrei importare questi valori nel db e, dove presenti, usarli per l'ordinamento. Dopo averla testata potremmo proporre la key in maniera ufficiale. Penserei inoltre di creare, in fase di import, una tabelle unica di codifica tra name e sort_name da cui andare a pescare i sort_name nei casi in cui questo manca. Ad esempio se a Storo ho Via Giuseppe Mazzini - Mazzini Giuseppe, Via ed a Pisa ho Via Giuseppe Mazzini senza sort_name potrei forzare lo stradario ad usare Mazzini Giuseppe, Via anche a Pisa. Controindicazioni? Purtroppo non ho tanto tempo da dedicare allo stradario, pensavo, appena ho tempo, di mettere tutto su un svn per poterci lavorare in gruppo. Ciao, Diego 2009/10/12 Federico Cozzi f.co...@gmail.com 2009/10/12 Luigi Chiesa lchi...@tiscalinet.it: Facciamo un esperimento su un paese completamente mappato? Nel caso io mi offro, oppure meglio discutere la cosa in ambito internazionale? La mia proposta era di prendere l'ottimo stradario realizzato per i comuni italiani e modificarne il codice in modo da appoggiarsi dapprima alla nuova chiave sort_name (o sort_key o altro che decidiamo), quindi di mettere mano ad un paese già mappato e piccolo (es. Storo) per vedere se l'approccio funziona o emergono bug imprevisti. Idealmente l'algoritmo dello stradario andrebbe comunque reso più intelligente in modo da indovinare, per le vie a cui manca la nuova chiave, un probabile ordinamento. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ancora su ordinamento alfabetico
2009/10/12 Giovani Berti com...@comune.storo.tn.it: Un dettaglio. Ho mappato anche parecchie strade di montagna e ubbidendo al blocco di JOSM che invita a mettere il nome a tutte le strade ho scelto di chiamare strada le strade forestali di montagna cui segue di solito il nome della località (a volte preceduto da preposizioni del tipo «strada per val Lorina») o il nome di due località collegate dalla strada (strada malga Spina Marigole), per distinguerle dalle via dello stradario ufficiale. Questo è un problema che si ri-collega all'altro, già noto, che nello stradario non dovrebbero essere inserite le autostrade. Nello specifico, vi sembra ragionevole che le strade di montagna appaiano nello stradario oppure no? (a me non sembra sbagliata né l'una né l'altra) Se decidiamo che le strade di montagna debbano apparire nello stradario, appariranno già, si spera ordinate correttamente. Se decidiamo che non devono apparire, potremmo inventare una soluzione che risolva il problema sia delle strade di montagna che delle autostrade. possono portare complicazioni alla gestione informatica, ma non è stato possibile togliere apostrofi e lettere accentate interne alle parole. Se facciamo le cose per bene dovremmo gestirle correttamente :-) Non mi ricordo che database abbia usato Diego, ma ad esempio PostgreSQL supporta COLLATE (http://www.postgresql.org/docs/8.1/interactive/charset.html) che dovrebbe essere in grado di ordinare la a accentata insieme alla a e prima della b. Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] mapping party di palmanova, com'e' andata?
qualcuno che ci racconti com'e' andata? Edo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Ferrovie
ho parlato con Ferrovie , segnalando l'esistenza di OSM, e che vogliamo i loro dati ovviamente la cosa li interessa molto e vogliono dettagli per iscritto. Cosa ci serve ci diano? Riusciamo a specificare, in maniera vendibile dentro Ferrovie, qualcosa di esaustivo e completo? Il direttore della tecnologia aspetta da noi un email in merito. cut Grazie Stefano Per caso ci sono novità da FS? Alessandro Pozzato ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Fwd: [OSM-talk] Visual map for the blind]
grazie Edo - a. 2009/10/9 Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it Questo è molto interessante ed è un primo passo per la mappa per disabili che avevamo immaginato un po' di tempo fa... Edo Messaggio Originale Oggetto:[OSM-talk] Visual map for the blind Data: Fri, 09 Oct 2009 00:28:20 +0200 Da: Lulu-Ann lulu-...@gmx.de A: accessibil...@openstreetmap.org, t...@openstreetmap.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mapping party di palmanova, com'e' andata?
On Mon, Oct 12, 2009 at 8:06 PM, Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it wrote: qualcuno che ci racconti com'e' andata? Direi bene. Ci siamo trovati in cinque, muniti di piantine ricavate da mapnik (perché le walking papers non sono aggiornate) ed abbiamo deciso di dividercela in tre spicchi: Stefano si è preso Borgo Udine, io e Andrea Borgo Cividale, Marcello e fidanzata (sorry, mi sono scordato il nome) Borgo Aquileia Dopo un buon caffè (direi obbligatorio) abbiamo percorso le varie strade per verificare la correttezza dei nomi (avevo precaricato in osm quelli tratti dalla ctr fvg), aggiungere quelli mancanti e raccogliere un po' di POI. A seguire pizza (un ora e mezza di passeggiata mette fame). Non sarebbe stato male loggare i percorsi ciclo-pedonali lungo le mura esterne ma la voglia era poca (parlo a titolo personale, ovviamente) anche perché il diluvio della notte precedente aveva reso il tutto piuttosto fangoso. Adesso speriamo di non perdersi in una edit war sulla classificazione delle strade. :P iiizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mapping party di palmanova, com'e' andata?
2009/10/13 iiizio iiizio iiizio.iii...@gmail.com: Ci siamo trovati in cinque, muniti di piantine ricavate da mapnik (perché le walking papers non sono aggiornate) ed abbiamo deciso di dividercela in tre spicchi: Stefano si è preso Borgo Udine, io e Andrea Borgo Cividale, Marcello e fidanzata (sorry, mi sono scordato il nome) Borgo Aquileia qualche foto e un resoconto da pubblicare sul blog? ...dai... -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] fotos aereas algunas partes armenia quindio
http://wiki.openstreetmap.org/wiki/Image:Coquindioarmenia.jpg un intento por rectificar esta foto pero no fue perfecto y no tenia muchos puntos de referencia en ese tiempo hace 1 año +- http://www.openstreetmap.org/?lat=4.54525lon=-75.66128zoom=16layers=B000FTF http://wiki.openstreetmap.org/wiki/Image:Coquindioarmeniafundadores.JPG barrio fundadores y carretera http://www.openstreetmap.org/?lat=4.54525lon=-75.66128zoom=16layers=B000FTF http://wiki.openstreetmap.org/wiki/Image:Coquindioarmeniacentro.jpg algo del centro de armenia Eso creo debe ser por aqui http://www.openstreetmap.org/?lat=4.53147lon=-75.68785zoom=15layers=B000FTF _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Descargar trazas de Garmin Geko 201 Debian Lenny
Hola, ouɐɯnH 2009/10/10 Igor Támara i...@tamarapatino.org: ouɐɯnH Hola, no puedo descargar trazas de un garmin geko 201, alguna ouɐɯnH idea? Gracias de antemano :) ouɐɯnH ouɐɯnH con un cable Usb serial en ouɐɯnH 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux ouɐɯnH y gpsbabel 1.3.6-3 ouɐɯnH ouɐɯnH yo lo hago con el programa qlandkartegt o qlandkarte mhh, en 64 bits sale core dump a la entrada del programa, no veo siquiere el spalash, en uno de 32 bits en la lista de dispositivos no aparece el modelo Geko201, tienes una pista de cómo descargar de este? O se puede incluso desde Ms Windows hacerlo? Si es así, cuál sería el software recomendado para hacerlo? de dónde lo puedo descargar? ouɐɯnH [..] ouɐɯnH ouɐɯnH debes ir por la interface del dispositivo, en configuracion y cambiar ouɐɯnH los valores de conectividad a garmin o probar otras, esto es como el ouɐɯnH protocolo de transmisión. -- Recomiendo la wikipedia, una enciclopedia que evoluciona día a día http://es.wikipedia.org signature.asc Description: Digital signature ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Descargar trazas de Garmin Geko 201 Debian Lenny
Ensayaste el software de garmin? http://www8.garmin.com/support/download_details.jsp?id=209c http://www8.garmin.com/software/MapSource_6157.exe este debe traer todos los drivers para todos los dispositivos(deberia) Igor Tmara escribi: Hola, ounH 2009/10/10 Igor Tmara i...@tamarapatino.org: ounH Hola, no puedo descargar trazas de un garmin geko 201, alguna ounH idea? Gracias de antemano :) ounH ounH con un cable Usb serial en ounH 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux ounH y gpsbabel 1.3.6-3 ounH ounH yo lo hago con el programa qlandkartegt o qlandkarte mhh, en 64 bits sale core dump a la entrada del programa, no veo siquiere el spalash, en uno de 32 bits en la lista de dispositivos no aparece el modelo Geko201, tienes una pista de cmo descargar de este? O se puede incluso desde Ms Windows hacerlo? Si es as, cul sera el software recomendado para hacerlo? de dnde lo puedo descargar? ounH [..] ounH ounH debes ir por la interface del dispositivo, en configuracion y cambiar ounH los valores de conectividad a garmin o probar otras, esto es como el ounH protocolo de transmisin. ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-es] Presentación / Photomapping con Androi d
Hola Me llamo Luistxo Fernandez, soy nuevo aquí, y soy colega en el trabajo (y natural del mismo pueblo) que un par de amigos de esta lista, Gari Araolaza y Mikel Lizarralde pese a ser un antiguo aficionado a los mapas, y hasta editar un blog dedicado al tema ( www.mapamovil.net ahora abandonado), confieso pelín avergonzado que no he empezado a mapear en OSM hasta la semana pasada. me animó a sumarme un pequeño mapping party de hace unos días en Andoain, Gipuzkoa. Ha sido decisivo ver como usaba Mikel Lizarralde el JOSM y también Iván Sánchez haciendo photomapping con cámara, GPS y JOSM. Como compensación por mi tardía incorporación a la comunidad, me he permitido añadir un poco de documentación al wiki general, en lo referido al photomapping. El caso es que el método que nos enseñó Iván se basa en el ingenioso truco de sacarle una foto al GPS mostrando la hora exacta, para poder hacer luego sync entre las fotos de la cámara y el tracklog del GPS, una opción del JOSM. El caso es que me preguntaba... ¿y si usas un smartphone o algún trasto 2-en-1 que saca fotos y lo mismo graba rutas GPX? la máquina no se puede sacar una foto a si misma..., pero tampoco haría falta porque se supone que las fotos deben estar sincronizadas en origen... Pruebas este fin de semana con un teléfono Android (en concreto un HTC G1 cogido prestado del trabajo) me han sacado de dudas: puedes grabar rutas con su GPS (uso la aplicación nativa MyTracks, de Google), y sacar fotos también, claro. Entonces, para hacer photomapping 1. Descarga la ruta GPX concreta y las fotos sacadas en el intervalo a tu PC. Pon las fotos en una carpeta específica. 2. Arranca JOSM y abre el GPX 3. selecciona el GPX en el panel de Layers, y con click derecho marca Import Images, para seleccionar las fotos, lo mejor es seleccionar la carpeta concreta. 4. Ummm... verás que las fotos no están bien puestas sobre la ruta... aparecen todas amontonadas en un sólo punto. Tranquilos, tiene solución. 5. selecciona el layer Geolocated images, y haz clic derecho para Sync Time. 6. Escoge cualquier imagen, y dale +0 como valor de sincronización. Dale OK, y verás que todas las fotos se ponen sobre su sitio correcto. He actualizado el wiki general con este ejemplo de Android, ya que no antes no decía nada de smartphones 2-en-1... http://wiki.openstreetmap.org/wiki/Photo_mapping Supongo que con iPhones con GPS y otros trastos será parecido... Luistxo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] trazas por la comunidad valenciana y Murcia
Hola Una de las pocas personas a las que he conseguido convencer para que colaboren con OSM de momento se limita a enviarme trazas de todos los trayectos que hace, principalmente por la Comunidad Valenciana y Murcia. Estoy subiendo ahora mismo todas las trazas, pero puesto que yo no conozco muy bien la zona, agradecería que alguien de la zona las editara por mí. Las podéis encontrar todas en: http://www.openstreetmap.org/traces/tag/valencia http://www.openstreetmap.org/traces/tag/murcia no todas son mías, pero no he encontrado ninguna forma de sólo mostrar las mías (aparte de http://www.openstreetmap.org/traces/mine/tag/valencia), ¿sabéis alguna? saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ca] [OpenStreetMap] andrewpmk sent you a new message
On Mon, Oct 12, 2009 at 2:15 PM, webmas...@openstreetmap.org wrote: Hi acrosscanadatrails, andrewpmk has sent you a message through OpenStreetMap with the subject CanVec importing: == OK, I have taken the plunge and imported CanVec tiles 031C01 and 031C08, which comprise the east side of Kingston, Ontario and some of the neighbouring area. I still have to do 031C02 and 031C07, which comprise the west side of Kingston. I used the data files that you uploaded a few days ago. Not surprisingly, there is a LOT that needs to be cleaned up after finishing the import. Is there any way of speeding up this process? Using JOSM, it takes absolutely forever, and you have to manually import each layer individually - there are about 100 of them. I noticed that you put the named feature in the extra folder, which suggests that it shouldn't be imported. Why is this? This contains names of islands, bays, points and various other natural features which seem to be useful, so I have imported them. -Andrewpmk Hi Andrew, I'm cc'ing the talk-ca list, so everyone knows whats up :) I updated the chart for you with the status of 'planning' for those other tiles that you mentioned :) re: speeding up the process.. If you see that the .osm files will cause 'no interference' you can simply (or if there is some) you can simply open up that .osm file and remove those features that you dont want to upload (by hand). then saveAS that .osm file, and use another tool, which is designed for this process (i haven't used it, but i hear form afar) that bulk_upload.pl works, were you set the target file as your SavedAS file, then the destination is the API directly. ... Would it be handy if i create a separate .osm file which is larger than the 2000 max? (change the max to unlimited) and make that file also available? ... If the area is rather 'empty' then i don't see a problem with that, ... but i would check with the osm admins.. 'cause it would slow down the server :-) (as then you can upload a series of .osm files) and so, asking the API to only accept the files at off-peak hours? (i cc'd the imports@ list) Perhaps i would recommend just focusing on 1 small area for the time being? and check for errors. As i think your gonna be the one who will upload most of that tile :-) ... although the process of changing tags after it's been copied in isn't that hard, it better to wait a little. Right now, there are 2 others (Michael Barbanov Adam Dunn) who are also looking at the files ... seeking out errors. What would you rate the error level at now? re: the named features file Because certain features, like 'river names' are listed, as well as the area names have the 'state' tag, when they shouldn't (see http://www.openstreetmap.org/?lat=48.82lon=-122.78zoom=7layers=B000FTF ) ... it lists Bear Lake as a 'State'. (i haven't removed that, because its the example) :-) it's an error with the script... it's possible to fix, but since so many features are there it would require a separate rules.txt for each. (also, park names maybe available in the Ontario data set) and lake names are already available in the GeoBaseNHN data set.. as well as some unknown others. I'll put it on the things to do list, if you think it's urgent (I'll get it done faster) otherwise, it'll wait until i got more geobaseNHN tiles available. :) re: latest greatest Right now, I'm working on creating the GeoBaseNHN tiles, starting with to 08H (which is the Vancouver Island area) and making them available. (it will be available today or tomorrow) Since you showed interest, I'll convert the 3 around, maybe not the big lake Ontario one, next. http://www.geobase.ca/geobase/en/browse.do?produit=nhndecoupage=unitsmap=031C Great work! Cheers, Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-cz] značení čajoven
Ahoj. Protože rozsáhlá síť čajoven je českým specifikem, myslím si, že by diskuse nad jejich značením měla začít tady. Dnes situace vypadá tak, že většina z nich je značena jako amenity=cafe, někdy s dodatkem cuisine=tea, a poté většinou uvedeno slovo Čajovna v názvu. Nemyslím si, že je to ideální. Možná by stálo zavést amenity=tea_room nebo něco podobného. Značkou by mohla být konvička nebo široký šálek. Tag cuisine by pak mohl volitelně označovat styl čajovny (např. chinese, japanese, indian, arabic, lebanese, turkish, european, rasta, modern apod.). Co si o tom myslíte? -- Stanislav Brabec http://www.penguin.cz/~utx ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] WFS was Import polygones CLC manquan ts - Retour d'expérience.
Bonjour, a propos de Qgis, je ne parlais pas tant de l'utiliser comme un éditeur OSM, mais plutôt pour ce qu'il fait très bien : être un front-end, une interface à Postgis et autres sources de données (wms, wps, sqlite, shape). On peut ainsi utiliser des couches de sources différentes, et surtout utiliser les fonctionnalités SIG classiques d'analse de données spatiales, et avoir un résultat visuel immédiat (buffer, intersections, etc.). En vectoriel, Qgis commence, grâce aux plugins python, à proposer des fonctionnalités très intéressantes. La mention du plugin qgis était dans mon discours pour montrer qu'on pouvait l'utiliser aussi pour OSM, mais surout pour montrer le potentiel. Lors d'un projet précédent, j'avais utilisé qgis pour gérer les données spatiales de traçabilité sur des parcelles (capteurs gps sur tracteurs), et j'avais été très charmé par la facilité avec laquelle on pouvait utiliser l'api pour développer ses propres plugins (en C ou en python). Enfin, je digresse un peu, là :) Bon début de semaine Le 11 octobre 2009 19:04, Denis dhel...@free.fr a écrit : Emilie Laffray a écrit : kimaidou wrote: Bonjour Je n'ai pas essayé, mais en passant, rapidement, je voulais savoir si vous aviez essayé le nouveau qgis, avec son plugin OSM. Ce plugin en est à ses début, mais qgis lui est un vrai logiciel SIG (et pas en java) qui gère bien les géométries complexes et lourdes. Peut-être que la grosse forêt des landes pourrait être regardée à la loupe dans qgis ? Le plus a mon avis c'est de travailler a partir de la base de données et d'outils comme QGis. Selon la mémoire nécessaire, j'utiliserais OpenJump (utilisable en 64 Bits). J'ai la base de donnée qui permet de voir les polygones qui touchent le polygone si besoin est. Dans les cas les plus complexes comme ceux ci, on a plus a y gagner a les importer en faisant les modifications a partir de la base de donnée initialement, de faire les modifications et ensuite de générer le fichier OSM pour import. Je pense que QGis pourrait être utile pour ça. Mes premières expériences avec QGis 1.2 et 1.3, notamment son plugin OSM ne m'ont pas franchement ébloui. Certes, ce n'est qu'un début et nul doute que des progrès rapides seront faits. En attendant je crois l'approche la plus réaliste est celle d'Émilie, mais combien vont avoir le luxe d'avoir un PostGIS à la maison avec une base à jour ? Une idée que je lance comme cela en l'air (pour voir où elle va retomber ) : un généreux geek offre un web service WFS (Web Feature Service) à partir d'une base OSM-postgisée. Du coup, le contributeur n'a pas à entretenir sa propre base en local. Deuxième effet kiss-kool, on peut organiser les données OSM en lots (une couche avec les limites admin), une avec le réseau hydro, un réseau routier, les POI, etc. Bref on peut découper la base en plein de tranches suivant l'intérêt. Dans certaines zones densément cartographiées, cela pourrait être utile. Bon, reste la cohérence des objets partageant les mêmes noeuds, entre autres. C'est juste une snaps-idée. Je crois beaucoup à l'émergence de ce nouveau mode de travail : web-services consommés par des web-applis ou de bureau. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
Pieren a écrit : 2009/10/12 rldhont rldh...@gmail.com: Mais il est aussi possible de décrire une ligne de bus qui dans le jargon des spécialistes est le parcours d'un treminus à un autre. Dans ce cas il est nécessaire d'associer dans une relation uniquement les sections de voies empreintées par la bus, donc seulement un bout de rond point. Si une application se développe pour construire ce type d'itinéraire, elle devrait être capable de réduire le rond-point à la section nécessaire. Encore une fois, vous adaptez le schéma d'OSM aux possibles usages qu'on en ferait dans un logiciel alors que c'est le logiciel qui doit s'adapter. Le schéma d'OSM doit représenter les objets du monde réel tels qu'ils sont. Et un carrefour giratoire n'est pas une succession de morceaux d'itinéraires. Si on continue dans cette direction (arf), il faudra à terme sectionner toutes les routes et rues à chaque intersection car chaque intersection est synonyme de changement d'itinéraire pour quelqu'un. Donc il faudrait interdire la possibilité de décrire les routes empruntés par les bus car en dehors des ronds points, pour décrire se genre de parcours, il est nécessaire de découper aussi les rues! Donc si on ne doit représenter que la réalité on ne devrait pas non plus découper les rues. Personnelement, je n'adapte pas le schéma d'OSM, j'utilise ce qui est décrit par des contributeurs et exploite ce que propose OSM. Si OSM propose de créer des relations et que celles-ci permettent de décrire un trajet, il me semble évident que je peux découper la rue en segment pour indiquer qu'un bout seulement de cette rue est emprunté par un bus. Donc doit on pouvoir indiqué qu'un bout de rue seulement est emprunté par un bus ? Enfin pour ma part un rond point n'est qu'une rue en sens unique avec des croisements. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import polygones CLC manquants - Ret our d'expérience.
Le retour des polygones géants de la mort. Vous vous demandiez où sont passés les quelques 343.000 ha pour 3.242 exploitations [agricoles] qui couvrent 60% de la Seine et Marne? -- http://osmose.openstreetmap.fr/clc/cgi-bin/get-osm.sh%3FFR-6749 [16.1mo] J'ai tenté une ouverture dans JOSM mais mon CPU qui est un vieux coucou, a tenté de se jeter par le fenêtre :q Mais a vu de nez c'est un très très beau et aussi très complexe polygone à importer. -- http://img128.imageshack.us/img128/7974/captureq.png J'avoue qu'uploader un pareil monstre me fait peur, si vous avez des conseils je suis preneur... 2009/10/12 Lionel Maraval lionel.mara...@gmail.com Le 11 octobre 2009 15:13, Vincent Pottier vpott...@gmail.com a écrit : Je n'ai pas trouvé comment le lancer (sur mac : sans ligne de commande) avec un paquet de RAM. -- Vincent alias FrViPofm Je me sers du Mac OSX JOSM package pris sur le site de JOSM. En affichant le contenu du paquet dans le Finder on peut accéder au fichier info.plist qui contient une ligne indiquant la quantité de mémoire à utiliser, comme en ligne de commande : keyVMOptions/key string-Xmx1200m/string -- Lionel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
C'est bizarre ce débat, un rond-point c'est une voie circulaire d'un seul tenant, en la découpant on falsifie un peut la représentation que l'on fait de la réalité vous trouvez pas? 2009/10/12 René-Luc rldh...@gmail.com Pieren a écrit : 2009/10/12 René-Luc rldh...@gmail.com: Donc il faudrait interdire la possibilité de décrire les routes empruntés par les bus car en dehors des ronds points, pour décrire se genre de parcours, il est nécessaire de découper aussi les rues! Donc si on ne doit représenter que la réalité on ne devrait pas non plus découper les rues. Oui, je trouve dommage de découper des rues pour des itinéraires, que ce soit pour des bus ou autre chose. Il aurait été plus intelligent de référencer la succession d'intersections. Ce serait une idée... Mais c'est totalement différent de ce que le monde entier fait dans le domaine... Enfin pour ma part un rond point n'est qu'une rue en sens unique avec des croisements. Non, un carrefour giratoire est un.. carrefour. Sauf qu'au lieu d'être un point, c'est un cercle. C'est pourquoi la plupart n'ont pas de noms, sauf certains qui ont le leur mais en aucun cas le nom d'une des rues y aboutissant. Ni de reference. C'est un carrefour représenté à l'aide d'une route et non d'un point, donc est-ce seulement une carrefour ou une voie ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
Une rue doit-elle, elle aussi être d'un seul tenant ? Le débat porte en fait sur la possibilité de découper des ways afin de les utiliser aussi de relations. tenshu a écrit : C'est bizarre ce débat, un rond-point c'est une voie circulaire d'un seul tenant, en la découpant on falsifie un peut la représentation que l'on fait de la réalité vous trouvez pas? 2009/10/12 René-Luc rldh...@gmail.com mailto:rldh...@gmail.com Pieren a écrit : 2009/10/12 René-Luc rldh...@gmail.com mailto:rldh...@gmail.com: Donc il faudrait interdire la possibilité de décrire les routes empruntés par les bus car en dehors des ronds points, pour décrire se genre de parcours, il est nécessaire de découper aussi les rues! Donc si on ne doit représenter que la réalité on ne devrait pas non plus découper les rues. Oui, je trouve dommage de découper des rues pour des itinéraires, que ce soit pour des bus ou autre chose. Il aurait été plus intelligent de référencer la succession d'intersections. Ce serait une idée... Mais c'est totalement différent de ce que le monde entier fait dans le domaine... Enfin pour ma part un rond point n'est qu'une rue en sens unique avec des croisements. Non, un carrefour giratoire est un.. carrefour. Sauf qu'au lieu d'être un point, c'est un cercle. C'est pourquoi la plupart n'ont pas de noms, sauf certains qui ont le leur mais en aucun cas le nom d'une des rues y aboutissant. Ni de reference. C'est un carrefour représenté à l'aide d'une route et non d'un point, donc est-ce seulement une carrefour ou une voie ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import polygones CLC manquants - Ret our d'expérience.
2009/10/12 tenshu ten...@gmail.com J'ai réussi à l'ouvrir et à naviguer un peut avec Merkaator, il est vraiment très grand ! Il traverse quasiment tout le 77 et plus loin à l'Est et au Sud en faisant une petite incursion jusque dans l'Essonne à l'ouest. Ce soir, je le regarderais, je ferais les decoupages necessaires pour une inclusion dans OSM a partir de ma base de donnee. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
On lundi 12 octobre 2009, Fabien Marchewka wrote: Oui, je trouve dommage de découper des rues pour des itinéraires, que ce soit pour des bus ou autre chose. Il aurait été plus intelligent de référencer la succession d'intersections. +100 ;) C'est à mon avis beaucoup plus intelligent. Ca évite la segmentation des rues en plus. A noter que cette idée avait été abordée sur le wiki. La proposition donnait les numéros de noeud entre lequels il se passait quelque chose (au début, le but était de noter les ponts et leur donner un nom sans toucher à la rue qui passe dessus) Le truc a fait flop car aucun éditeur ne l'utilise pour le faire facilement, et tout mouvement/suppression des noeuds clef perturbait le système. Et autant dire que le repérage manuel des numéro de noeud à 9 chiffres, c'est pas gagné. Donc, l'état actuel des choses fait qu'on a tendance à saucissonner les rues dès qu'il se passe un truc différent. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [clc-import-manuel] quelques changements sur le serveur
Bonjour, Les serveur ayant un peu de mal à servir tous les marqueurs, j'ai rajouté une limite : on affiche rien quand le zoom est inférieur à 10 (sauf dans le cas où on ne demande qu'un type de marqueur, dans ce cas on a pas de restriction). De toutes façon, ça ne sert pas à grand chose et ça charge à donf le serveur ; faudrait que je modifie la requête mais j'ai pas encore réfléchi. J'ai indexé certains champs ce qui lui fait gagner un peu, mais c'est pas encore optimal. De plus j'ai affiché des compteurs en plus (nombre de bulles par état), ce qui montre qu'il y a des fourmis qui travaillent !!! -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
On lundi 12 octobre 2009, Pieren wrote: Encore une fois, vous adaptez le schéma d'OSM aux possibles usages qu'on en ferait dans un logiciel alors que c'est le logiciel qui doit s'adapter. Ça par contre, je n'en suis pas convaincu. Il faut bien à un moment que l'information existe dans la base, sans quoi il est impossible de l'inventer. La question reste, quelle information ne peut être déduite (donc devrait figurer), quelle information peut être calculée. (donc a priori pas nécessaire de faire figurer) terme sectionner toutes les routes et rues à chaque intersection car chaque intersection est synonyme de changement d'itinéraire pour quelqu'un. J'éssaye de trouver le cas ambiguë où on a pas le choix que d'ajouter l'info à la base, et je repense au cas des itinéraires GR. supposons une chemin de rando qui longe une départementale et sur 200m il est confondu avec la départementale (en gros, il n'existe pas de chemin, l'itinéraire route est donc proposé sur la départemental) et supposons qu'ultérieurement le chemin ré-apparaisse et recroise la départementale, ajouter dans la route GR le chemin d'un seul tenant et la départemental d'un seul tenant empéche de savoir par où passe l'itinéraire. Genre : ---a-- /-d- chemin \ / =1===2b3===4=D27 \___c/ le GR est proposé comme composé de a,2b,c,d si, je l'indique comme étant somme de chemin+D27, il y a alors plusieurs combinaisons indistinguables (a,2b,c,d ou a,2b,3,d) a moins de faire entrer des devinettes par préférence (genre un marcheur n'aime pas marcher sur la route) Bref, dans ces cas là, je ne vois pas d'autre solution que de faire du saucissonnage de way. Et à terme, en effet, entre route de bus, itinéraire rando, itinéraire BIS, itinéraire d'intérêt culturel et d'autre auquel je ne pense pas. Je crains que ça ne se finisse avec un fort découpage... -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
Le 12 octobre 2009 12:43, sly (sylvain letuffe) sylv...@letuffe.org a écrit : On lundi 12 octobre 2009, Pieren wrote: Encore une fois, vous adaptez le schéma d'OSM aux possibles usages qu'on en ferait dans un logiciel alors que c'est le logiciel qui doit s'adapter. Ça par contre, je n'en suis pas convaincu. Il faut bien à un moment que l'information existe dans la base, sans quoi il est impossible de l'inventer. La question reste, quelle information ne peut être déduite (donc devrait figurer), quelle information peut être calculée. (donc a priori pas nécessaire de faire figurer) terme sectionner toutes les routes et rues à chaque intersection car chaque intersection est synonyme de changement d'itinéraire pour quelqu'un. J'éssaye de trouver le cas ambiguë où on a pas le choix que d'ajouter l'info à la base, et je repense au cas des itinéraires GR. supposons une chemin de rando qui longe une départementale et sur 200m il est confondu avec la départementale (en gros, il n'existe pas de chemin, l'itinéraire route est donc proposé sur la départemental) et supposons qu'ultérieurement le chemin ré-apparaisse et recroise la départementale, ajouter dans la route GR le chemin d'un seul tenant et la départemental d'un seul tenant empéche de savoir par où passe l'itinéraire. Genre : ---a-- /-d- chemin \ / =1===2b3===4=D27 \___c/ le GR est proposé comme composé de a,2b,c,d si, je l'indique comme étant somme de chemin+D27, il y a alors plusieurs combinaisons indistinguables (a,2b,c,d ou a,2b,3,d) a moins de faire entrer des devinettes par préférence (genre un marcheur n'aime pas marcher sur la route) Bref, dans ces cas là, je ne vois pas d'autre solution que de faire du saucissonnage de way. Et à terme, en effet, entre route de bus, itinéraire rando, itinéraire BIS, itinéraire d'intérêt culturel et d'autre auquel je ne pense pas. Je crains que ça ne se finisse avec un fort découpage... L'idée de faire qu'une rue soit une relation de ways prendrait alors sont sens. un way est un bout de quelque chose, je ne vois pas vraiment pourquoi ce serait une rue ou autre chose. Les ways ne devraient pas avoir de signification particulière mais les relations de ces ways serait des éléments tel que les rues, les GR, le trajets de bus Ce serait plus simple aussi pour renommer une rue que de sélectionner tous les ways. Mais bon il me semble que cela avait déjà été débattu. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Fabien Marchewka ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] natural=rock bug / osmose / corine
salut, Juste pour dire que les polygones non importés de type roche nues sur http://osmose.openstreetmap.fr/clc/ ne contiennent pas l'attribu natural=rock et qu'il faut bien penser à l'ajouter à la main. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartes ou les copyrights ne sont plus valides
Emilie Laffray a écrit : Bonjour, J'aimerais si certains d'entre vous savent ou trouver des cartes ou les copyrights ont expirés. Nos amis anglais ont récemment récupérés de très vielles cartes qui ont été mises sur un serveur WMS afin d'importer les limites administratives et d'autres éléments. Si l'on pouvait trouver de telles cartes en France, cela nous permettrait d'avoir accès aux rivières. Par exemple, la Loire est vide a certains endroits la ou les images Yahoo manquent. Maintenant avec Corine, on devine la forme exacte comme du cote de Gien mais avoir une carte serait bien sur mieux. Donc si on avait un passionne de cartes, et un expert en droit ça serait parfait. Je ne connais pas du tout la durée des droits d'auteurs sur les cartes de l'IGN ou Michelin. Emilie Laffray Bonjour, Copié-collé d'un message paru sur une liste de généalogie si cela peut vous aider. copie ON Atlas National illustré des départements et possessions de la France publié par A. Combette - Paris 1852 J'espère que celles et ceux qui connaissaient y retrouveront du plaisir, et que les personnes qui ne connaissaient pas apprécieront. Voici le lien : http://perso.modulonet.fr/~hmaingot22/index.htm#TOC Bien cordialement. Hervé MAINGOT copie OFF Amitiés -- Si on n'avait toujours voulu que la meilleure des solutions, ce serait vide. Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
On lundi 12 octobre 2009, Fabien Marchewka wrote: L'idée de faire qu'une rue soit une relation de ways prendrait alors sont sens. (...) Mais bon il me semble que cela avait déjà été débattu. L'état actuel des editeurs fait que c'est ingérable, mais je pense que c'est vers cette solution plus logique que nous tendrons. Le jour ou josm permettra la manipulation de l'objet relation sans s'en rendre compte, ça pourra être re-réfléchi -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
