Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
Steve Bennett-3 wrote: Anyway think the element names could be refined slightly. Are there any other tags that work this way, apart from the lifecycle ones? Do different tags have different lifecycles (I seem to recall that railways have more states). Should I just hard-code it all? I like the basic mechanism, supports the current handling of construction nicely. I believe a tagging scheme like this was discussed for the very unspecific historic=ruins, but I dont't think there was anything definite. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch-dev-Suggestion-for-lifecycle-tag-comments-tp6029585p6030992.html Sent from the Potlatch mailing list archive at Nabble.com. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
On Wed, Feb 16, 2011 at 2:16 AM, Steve Bennett stevag...@gmail.com wrote: On Wed, Feb 16, 2011 at 9:41 AM, Andy Allan gravityst...@gmail.com wrote: My first thought is to just have another couple of highway types ( a proposed highway and a highway under construction ) with a list of classifications in a choice input, and maybe some date inputs for when they are opening and so on. My feeling is that proposed is really not a type of highway, and that eventually this tagging scheme will be replaced by something a little less idiosyncratic: highway=tertiary lifecycle=proposed No, it won't, for reasons already explained by Nop. Moreover the current system has the distinct advantage that it can be used to describe what's on the ground - a stroke of a pen on a planner's chart isn't a slight variant of a secondary road, it's something else entirely ( a proposal ) and hence is a separate high-level concept. Similarly, if you stumble across a strip of gravel surrounded by men with shovels you can be pretty sure it's a road under construction, but you would need further investigation to tell what kind of road it might at some point become in the future. I think the tagging scheme isn't idiosyncratic but is actually well thought through, but even without giving a fig about tagging I don't want to see proposed/construction/actually-exists as a property on all the roads within p2. Ok, first, I don't think the UI would be different either way. All the code would be happening behind the scenes, to make a simple UI: simply an extra dropdown on a misc tab or something. Which is actually a different thing. What I'm suggesting is that proposed and construction would be two more icons on the grid of road types, whereas you are suggesting the lifecycle should be a dropdown on every single one of the hundreds of thousands of normal roads. Not to mention you'd need to duplicate all the road types for every life cycle stage. You'd also need to add proposed railway, proposed cycleway, proposed foothpath, proposed track, proposed bridleway, proposed building, etc etc (and repeat for construction etc). Pretty messy, no? Pretty unnecessary, imo. I think you're misunderstanding the current purpose of the simple tab - providing a simple UI for the majority of the mapping. Proposed buildings is pretty niche, and should be incorporated in a way becoming of its niche-ness. Adding dropdowns over every object for such a rare occurrence is the messy way. Cheers, Andy ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
Andy Allan wrote: Pretty unnecessary, imo. I think you're misunderstanding the current purpose of the simple tab - providing a simple UI for the majority of the mapping. Proposed buildings is pretty niche, and should be incorporated in a way becoming of its niche-ness. +1. (Are we allowed to say aolme too/aol these days in view of our generous sponsors...?) Potlatch, 1 or 2, has always been a 90-10 editor. Make the 90% of mapping easy, and the 10% possible. And of course the 'advanced' view makes anything possible. We have the luxury that JOSM exists for those who want to do the hardcore 10%, 5%, often even 0.1%. But we also have the responsibility that, as the default and OSM-hosted editor, Potlatch needs to be approachable and understandable. I'm also a little aware (having optimised the CategorySelector stuff yesterday) that the tagging code is way complicated as it is and probably doesn't need any more edge cases lest my head explode. ;) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch-dev-Suggestion-for-lifecycle-tag-comments-tp6029585p6031319.html Sent from the Potlatch mailing list archive at Nabble.com. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
Actually, what I forgot to say was... Potlatch, 1 or 2, has always been a 90-10 editor. Make the 90% of mapping easy, and the 10% possible. ...and with P2, we can now make it both a 90-10 editor and a 99-1 editor. That's why we have user-selectable stylesheets, and in particular the 'Enhanced' one. That's why I did a bunch of work on enabling XML and CSS files to have nested includes, so that we can do this without repeating ourselves. And so on. User-selectable map_features.xml will be the next step. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch-dev-Suggestion-for-lifecycle-tag-comments-tp6029585p6031355.html Sent from the Potlatch mailing list archive at Nabble.com. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
No, it won't, for reasons already explained by Nop. Moreover the current system has the distinct advantage that it can be used to describe what's on the ground - a stroke of a pen on a planner's chart I disagree, but as this is a distraction from the actual discussion at hand, I'll leave it. Which is actually a different thing. What I'm suggesting is that proposed and construction would be two more icons on the grid of road types, whereas you are suggesting the lifecycle should be a dropdown on every single one of the hundreds of thousands of normal roads. It's quite unfair to compare two icons against hundreds of thousands of normal roads. The fair comparison would be a minimum of 3 icons (road, rail, footpath/cycleway) against one dropdown box. Pretty unnecessary, imo. I think you're misunderstanding the current purpose of the simple tab - providing a simple UI for the majority of the mapping. Proposed buildings is pretty niche, and should be incorporated in a way becoming of its niche-ness. Adding dropdowns over every object for such a rare occurrence is the messy way. Ok, proposed buildings are niche. Roads under construction aren't. Maybe this is some philosophical difference we're going to need to debate out, but I see covering these tags properly as comprehensive, complete and thorough - not messy. Yes, the UI needs to be designed in a way to maximise access to common tagging tasks - I've even created tickets to that effect. But the trade-off you're suggesting between simplicity and completeness is artificial, imho. So here are three potential solutions: 1 put tags like this on a tab called advanced, which simple users don't have to use. 2 hide tags like this unless some user option called advanced is enabled. 3 put tags like this only in an enhanced map_features.xml. the tagging code is way complicated In CategorySelector? I'll have to have a look. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
On Wed, Feb 16, 2011 at 10:24 PM, Richard Fairhurst rich...@systemed.net wrote: I'm also a little aware (having optimised the CategorySelector stuff yesterday) Btw - awesome. :) Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[osmosis-dev] Unable to load current way nodes, when extracting and importing data from a osm file to a API BD
- Downloaded planet file planet-110202.osm.bz2 - Extracted a osm for the zone 43.5N -3.5W | 42N -1W with osmosis : bzcat planet-101027.osm.bz2 | osmosis --read-xml file=/dev/stdin enableDateParsing=no --bounding-box top=43.5 left=-3.5 bottom=42 right=-1 --write-xml file=- | bzip2 extracted.osm.bz2 It takes 2 hours to complete but it finishes with no errors. - Clear the API DB : dropdb openstreetmap createdb -E UTF8 -O openstreetmap openstreetmap dropdb osm_test createdb -E UTF8 -O openstreetmap osm_test dropdb osm createdb -E UTF8 -O openstreetmap osm psql -d openstreetmap /usr/share/postgresql/8.4/contrib/btreet_gist.sql rake db:migrate rake test - Import extracted osm file to the API DB with osmosis : bzcat extracted.osm.bz2 | osmosis --read-xml-0.6 file=- --write-apidb-0.6 populateCurrentTables=yes host=localhost database=openstreetmap user=openstreetmap password=xxx validateSchemaVersion=no Ends with error : org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to load current way nodes. ... Caused by: org.postgresql.util.PSQLException: ERROR: insert or update on table current_way_nodes violates foreign key constraint current_way_nodes_node_id_fkey Detail: Key (node_id)=(490767853) is not present in table current_nodes ... The 'weird' thing is that 490767853 node is out of the bounding box http://www.openstreetmap.org/browse/node/490767853 : 42.3951781, -3.5017794http://www.openstreetmap.org/?lat=42.3951781lon=-3.5017794zoom=18 Am I doing the process to extract+import correctly ? Is there a way to avoid this error ? ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] OSMembrane - GUI front-end for Osmosis
I couldn't find the source code. Like I already posted on the website it's available at http://osmembrane.de/svn/sources/ Also, this statement on the website is a bit odd: With the download you agree to the GNU GENERAL PUBLIC LICENSE (Version 3, 29 June 2007). This declaration grants GPLv3 licensing terms to older revisions which files might be labeled as “Creative Commons License” as well. The problem is these files are located in old SVN revisions and therefore can't be edited anymore. These files contain a copyright hint saying Project licensed under Creative Commons License. We'd just like to point out that these are invalid and the GPL applies to these *old revisions* as well. All files in current revisions are correctly labeled with GPL. ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] OSMembrane - GUI front-end for Osmosis
Since now there is a new build available it should fix the problems with Windows XP. Also now is an update checker included, which will inform you if a new version is available. You should be able to disable the update check in the next build, but currently that isn't possible. Greetings 2011/2/16 Tobias Kuhn tob...@osmembrane.de: Sorry for my previous post going in the wrong place here, got some mail delivery problems. :) Am 16.02.2011 14:46, schrieb André Joost: I try to test it under Windows XP, but the configuration file .osmembrane.settings seems not a valid filename under Windows. I can assure it works on windows 7, and I was thinking this should be also working with XP when you're not editing them by hand. Well, I've just created an issue in the redmine for that. (http://redmine.osmembrane.de/issues/235) Does this prohibit you from using the program altogether or is it just a problem with changing the settings? Greetings ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
[OSM-dev] osm2pgsql: going over pending relations number larger than relations?
Hi I have imported the full planet last November and now keep the db up-to-date weekly (based on daily diffs I fetch every week with osmosis). It worked nicely so far, but in the current import I see something strange: Reading in file: /Users/map/import/data/changes.osc.gz Processing: Node(21177k) Way(2326k) Relation(34k) parse time: 283207s Node stats: total(21177902), max(1145198079) Way stats: total(2326039), max(98985030) Relation stats: total(34113), max(1418290) Going over pending ways processing way (1544k) Going over pending relations processing relation (40k) So from my understanding, the diff contained 34K relations, but currently it processes relation 40K in the Going over pending relations step. Is this possible/normal? I guess if I now stop the import I have to start over with a full planet? kind regards Michael PS: I use PostgreSQL 8.4 and osm2pgsql from SVN-revision 24244 (Nov 7, 2010) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: going over pending relations number larger than relations?
Hi, On 02/16/2011 11:00 AM, Michael Kussmaul wrote: So from my understanding, the diff contained 34K relations, but currently it processes relation 40K in the Going over pending relations step. Is this possible/normal? Yes. pending relations are pre-existing relations that have been potentially been affected by an update to one of their members. So in theory you could have a diff with zero relations and still have thousands of pending relations. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSMembrane - GUI front-end for Osmosis
Hello OSM community, we're three students which had to develop a *Graphical Interface for Osmosis* during a practical task. This task now is finished and we'd like to release our product to the real world and see whether the world needs it or not. The program is written in Java with Swing and named OSMembrane, the name is a pun on Osmosis and semipermeable membranes. It is available at *http://www.osmembrane.de/* (the site is in English) http://osmembrane.de/There you can obtain the latest executable release as well as the source code and project managment. It's licensed under the GPL to be compatible with software already present in OSM. The Osmosis tasks are included via an XML file so it is extendible. Currently supported locales are English and German. We're primarily interested in feedback for OSMembrane: Do you like it? Do you need it? Will you use it in the future? What's good and what's bad? So please don't hesitate to post your thoughts, a lousy answer is better than none. :) And additionally, since we won't be able to spend too much additional time on this project we'd also like to offer the possibility to maintain the project and continue the development, if anyone likes to. Greetings ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSMembrane - GUI front-end for Osmosis
Great, yesterday I thought about it while frustrated by my chaotic pipe setup. I will take a view, of course :) Would be great if you could add yours at http://wiki.openstreetmap.org/wiki/Research regards Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [dev] OSMembrane - GUI front-end for Osmosis
Hi Tobias, hi everybody, we're three students which had to develop a *Graphical Interface for Osmosis* during a practical task. This task now is finished and we'd like to release our product to the real world and see whether the world needs it or not. well, for what it's worth, I am interested, and my employer is too, indirectly :) This shouldn't be much of a surprise at least for the three OSMembrane authors, as I'm the one who created this university assignment in the first place - and the OSMembrane folks did a very good job while solving it, IMHO. Now that we're done with the formal university assignment part: like I said, we use Osmosis at work, and we're very much in the real world ;) And additionally, since we won't be able to spend too much additional time on this project we'd also like to offer the possibility to maintain the project and continue the development, if anyone likes to. I am definitely interested in helping with that, too - it'd really be a pity if the project vanished into oblivion. Best regards Igor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2spatialite!
On 2011-01-14 13:33, Daniel Sabo wrote: I have a beta version of an osm2spatialite script written in python. [...] Neither the GOES C api and SpatialLite have a version of BuildArea so most of the code is devoted to assembling multipolygons, so that's the area it's most likely to produce different results than osm2pgsql. SpatiaLite has BuildArea() support since 2010-04-01 (svn) / 2010-08-15 (2.4.0 RC3) [1,2]. also, spatialite-tools include the spatialite_osm_* tools, among them spatialite_osm_raw, which simply acquir[es] OSM XML into DB tables (fully preserving the XML layout) [3]. the schema generated by spatialite_osm_raw is different from the osm2pgsql schema, but all the important ingredients (raw data for nodes, ways, relations; tags; join tables for ways and relations; geometry for nodes) are there. it wouldn't require too much effort to transform this into the osm2pgsql schema, either by postprocessing it with sql, or (probably the better idea) by adapting spatialite_osm_raw.c. we might even suggest a spatialite_osm_pgsql tool to Alessandro Sandro Furieri, the developer of SpatiaLite - he is known for magically producing code for many feature requests. Ram is an issue so I'm not sure python is the best choice in the long term. Right now a 450MB xml file takes ~900MB to process. It is fairly speedily though as long as you don't run out of memory. running spatialite_osm_raw on a 368MB osm file takes 76 secs and less than 30MB RAM (on a virtual debian server with 1GB RAM). this will take more if we want to have osm2pgsql's geometry tables for lines, roads, and polygons also. i still find this quite impressing, and i'm sure it is way more efficient than doing the processing in python. ax [1] http://groups.google.com/group/spatialite-users/browse_thread/thread/78b880074f1d84a0 [2] http://www.gaia-gis.it/spatialite-2.4.0-4/spatialite-sql-2.4-4.html#p0 [3] http://www.gaia-gis.it/spatialite-2.4.0-4/road_map.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] generate_tiles.py with upload?
Hi Folks, I was just about to modify generate_tiles.py to upload the tiles to a remote server as it generates them.Then I thought that loads of people have probably done this before. Does anyone have a version of generate_tiles.py that will ftp the output to a remote server and deal with specifying the remote root directory, creating directories where necessary etc? If so, can I have a copy please? Just being lazy! Regards Graham. -- Graham Jones Hartlepool, UK. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] segfault in osm2pgsql
Hi, M?rtin Koppenhoefer wrote: Today I updated osm2pgsql to Version osm2pgsql SVN version 0.70.5 now I get this on startup: 11924 Segmentation fault Last commited changes are mine - try svn checkout -r25078 and see if that works. If yes, it's my fault, and I'd like to know your command line. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] segfault in osm2pgsql
On 16.02.2011 22:59, M∡rtin Koppenhoefer wrote: Today I updated osm2pgsql to Version osm2pgsql SVN version 0.70.5 now I get this on startup: 11924 Segmentation fault core file available? Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2spatialite!
There has actually been a python script to generate a simple sqlite database form osm xml for years, but transforming the data into lines and polygons really is the hard part. I did find a version of spatialite that supported build area after I had written the multipolygon code, but I've decided to keep the code in osm2spatialite because it does a much better job of generating valid multipolygons that BuildArea can (because BuildArea doesn't have a concept of the inner and outer roles). In the future there's room for osm2spatialite to also fix self intersecting polygons but since they don't upset mapnik I haven't gotten around to it. The memory usage is because generating the osm2pgsql style database requires keeping all the geometry data in ram to generate the lines and polygons. I do have code that caches it and keeps memory useage 100M but it's significantly slower for data that fits in ram. If osm2pgsql is any indication it's probably faster to just fill up swap space but I haven't had the time to let it run against any multi GB files. The other reason I expect to stick with python for this is that it makes it much easier to prototype preprocessing code, and at some point I'd like to support things like the label admin_center roles on boundary multipolygons. - Daniel On Feb 16, 2011, at 5:37 AM, Axel Kollmorgen wrote: On 2011-01-14 13:33, Daniel Sabo wrote: I have a beta version of an osm2spatialite script written in python. [...] Neither the GOES C api and SpatialLite have a version of BuildArea so most of the code is devoted to assembling multipolygons, so that's the area it's most likely to produce different results than osm2pgsql. SpatiaLite has BuildArea() support since 2010-04-01 (svn) / 2010-08-15 (2.4.0 RC3) [1,2]. also, spatialite-tools include the spatialite_osm_* tools, among them spatialite_osm_raw, which simply acquir[es] OSM XML into DB tables (fully preserving the XML layout) [3]. the schema generated by spatialite_osm_raw is different from the osm2pgsql schema, but all the important ingredients (raw data for nodes, ways, relations; tags; join tables for ways and relations; geometry for nodes) are there. it wouldn't require too much effort to transform this into the osm2pgsql schema, either by postprocessing it with sql, or (probably the better idea) by adapting spatialite_osm_raw.c. we might even suggest a spatialite_osm_pgsql tool to Alessandro Sandro Furieri, the developer of SpatiaLite - he is known for magically producing code for many feature requests. Ram is an issue so I'm not sure python is the best choice in the long term. Right now a 450MB xml file takes ~900MB to process. It is fairly speedily though as long as you don't run out of memory. running spatialite_osm_raw on a 368MB osm file takes 76 secs and less than 30MB RAM (on a virtual debian server with 1GB RAM). this will take more if we want to have osm2pgsql's geometry tables for lines, roads, and polygons also. i still find this quite impressing, and i'm sure it is way more efficient than doing the processing in python. ax [1] http://groups.google.com/group/spatialite-users/browse_thread/thread/78b880074f1d84a0 [2] http://www.gaia-gis.it/spatialite-2.4.0-4/spatialite-sql-2.4-4.html#p0 [3] http://www.gaia-gis.it/spatialite-2.4.0-4/road_map.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2spatialite!
Daniel, On 02/17/11 02:57, Daniel Sabo wrote: I did find a version of spatialite that supported build area after I had written the multipolygon code, but I've decided to keep the code in osm2spatialite because it does a much better job of generating valid multipolygons that BuildArea can (because BuildArea doesn't have a concept of the inner and outer roles). Can you elaborate on how having inner and outer roles helps one in building a valid geometry? Reason I'm asking is that in all the code where *I* generate geometries from multipolygon relations, I explicitly ignore the role because using the role would actually lead to more, not less, invalid multipolygons. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Proj4J - New plugin supporting 3000+ projections
I've gotten my plugin based on the Proj4J in a working state, or at least working for me. Some information is on the OSM wiki [1] and codes/JAR can be obtained from the trac site [2]. Please test this out and report any issues. My main interest was using EPSG:2924 with the pdfimport plugin, so I've also created a patch for that plugin to show the preference panel of any projection, not just Proj4J. You can view the ticket at [3]. Thanks, -Josh [1]: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Proj4J [2]: http://josm.openstreetmap.de/ticket/5935 [3]: http://josm.openstreetmap.de/ticket/5936 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
