Re: [OSM-dev] Problem running osmosis (PluginLifecycleException)
Christoph Eckert wrote: Hi, I try to extract some data from an osm file using osmosis. I invoke it like this: java -mx1024m -jar ./osmosis-0.31/osmosis.jar --read-xml file=someosm.bz --node-key-value place.city,place.town --way-key-value highway.motorway,highway.trunk,highway.primary,highway.secondary --write-xml file=evenless.osm However I get some error: org.openstreetmap.osmosis.core.Osmosis main SCHWERWIEGEND: Execution aborted. java.lang.NoClassDefFoundError: org/java/plugin/PluginLifecycleException at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:73) at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30) You need to have all of the jar files in the osmosis/lib/default directory available on the classpath. This includes jpf-1.5.jar which contains the missing class org/java/plugin/PluginLifecycleException listed above. If osmosis.bat batch file or osmosis shell script files in the bin directory should do this for you. Is there a reason you can't use the launch scripts provided? The java version is: java -version java version 1.6.0_03 Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) I searched the web and the archives of this list and found some advice. Due to my complete ignorance of Java I didn't manage to put the puzzle together, though. Do I need to set some environment variable to point java to some plugin or library locations? Do I need to install a later Java version (I already tried to install a recent version from java.com in a local sandbox directory, but to no avail)? Any other hint? The java version you are using is fine. You're just missing the additional jars required to make osmosis run. osmosis.jar itself only contains osmosis classes, it doesn't include all of the external dependencies required. Brett ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis and Postgresql
Graham Jones wrote: Hi Folks, I have spent a couple of evenings trying to persuade osmosis to import a planet dump into postgresql. It was quite a lot harder than I expected because of the need to set up the database schema, postgis etc. first (I am not used to postgresql, which was a lot of the problem). I have had a go at drafting a procedure for setting this up for the first time at: http://wiki.openstreetmap.org/wiki/Talk:Osmosis#Procedure_to_import_data_into_PostGreSQL Would someone that know more about this than me mind having a look and pointing out my mistakes please? Once it is right I'll add it as a separate wiki page rather than hiding it in the 'talk' bit. Hi Graham, Thanks for taking the effort to document this. The Osmosis documentation is lacking in a number of areas, this is one of them :-) I see you've already added a link from the Osmosis detailed usage page which is great. If you get a chance, check out the --write-pgsql-dump task which is a much faster (but less convenient) way of importing very large data sets. If you or somebody else has some time to document that procedure it would be very helpful. Cheers, Brett ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problems with own Mapnik installation
On 2009-06-20 at 20:28 +0100, Jon Burgess wrote: The problem is, that in different scales (bbox to image size) colours of the ways changes and finally some ways vanish. Those vanishing are as far as I can see highways except tracks and bridges for all kinds of highways. I think that can happen if you have a mismatch between the osm.xml and the columns in the DB. These columns are defined by the contents of the default.style file used osm2pgsql. You're absolutely right, that was the issue. Updating default.style and reimporting did it. I just wonder why it worked with a quite wrong scheme at all. And is this problem - or rather that you should make sure to have matching schemes - mentioned anywhere? I reread the Mapnik and Osm2pgsql wiki pages and couldn't find it. If it's not in anywhere else I'd try to add it in on [[Mapnik]]. Thanks, Nils ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problems with own Mapnik installation
Nils Bermann wrote: You're absolutely right, that was the issue. Updating default.style and reimporting did it. I just wonder why it worked with a quite wrong scheme at all. That's because the layers you still saw at those zoom levels didn't reference those missing columns. The weirdly coloured roads you saw, for instance, were only drawn in their casing, and couldn't be filled with the core colour because that style actually referenced a missing column. And is this problem - or rather that you should make sure to have matching schemes - mentioned anywhere? I reread the Mapnik and Osm2pgsql wiki pages and couldn't find it. If it's not in anywhere else I'd try to add it in on [[Mapnik]]. It's always a good idea to keep osm.xml, default.style and osm2pgsql synched to each other. If one of them falls too much behind the others in features, you can get those strange effects or other undefined behaviour. So you're welcome to add such a note to the respective documentation, where missing. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problem running osmosis (PluginLifecycleException)
Hi, thanks for the help: You need to have all of the jar files in the osmosis/lib/default directory available on the classpath. This includes jpf-1.5.jar which contains the missing class org/java/plugin/PluginLifecycleException listed above. OK, that's the case. If osmosis.bat batch file or osmosis shell script files in the bin directory should do this for you. Is there a reason you can't use the launch scripts provided? No. I just did it the other way as it worked with osmosis 0.24 :) . [...] The java version you are using is fine. You're just missing the additional jars required to make osmosis run. osmosis.jar itself only contains osmosis classes, it doesn't include all of the external dependencies required. I had a closer look at the osmosis shell script. So I do: ./osmosis-0.31/bin/osmosis --read-xml file=someosm.bz2 --node-key-value place.city,place.town --way-key-value highway.motorway,highway.trunk,highway.primary,highway.secondary --write-xml file=basemap.osm Now I get some class version error (see below). Is my java installation messed? Thanks a bunch, ce --- 8 --- Exception in thread main java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
Frederik Ramm wrote: However, we'll have more and more imports like boundaries, seamarks and so on, which I like to consider mutable for people who know exactly what they're doing. Is this actually a real-world problem right now, or something we think might possibly one day become one? cheers Richard -- View this message in context: http://www.nabble.com/A-new-take-on-the-%22mutable%22-idea-tp24119922p24133350.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
Hi, Matt Amos wrote: on the other hand, what's a good reason? aren't the vast majority of edits made for a good reason, i.e: to improve the data? Improve according to what the person editing it thinks - yes. For example, and sorry for being pessimistic, I believe that a lot of OSM contributors would be perfectly capable to insert a few nodes into an administrative border and move them around just to make the line look less jagged on the map - improve it, as they wold say. If their editor would inform them that they are editing the administrative border as copied from some official publication, then they still *could* edit the border if they e.g. had information about said official publication being wrong or outdated, but they would likely refrain from editing it otherwise. Which I'd find desirable. Of course it would make sense (and not render the system useless!) to implement the scheme in editors and have the editor display a pop-up note saying something like the previous editor of this item has specially flagged this item list source tag list changeset comment , do you want to upload your change anyway?. i think it would make even more sense if said editor could sign up on some server, flag his or her special elements there and get emails or an RSS feed of the changes. That's not the same - such a feed would only allow you to do ex-post issue resolution (dear user XY, you have edited an administrative border that I copied from official documentation, are you sure you knew what you were doing, because otherwise I might be tempted to revert...). is it better to try and prevent people editing, or give editors the tools to monitor areas they care about? I think we are, and should be, moving slowly towards better conservation of value. We're still pretty anarchistic with every edit being given the same status, whether made by a newbie or an old mapper, by someone with a 4-year-old e-trex or someone with a state-of-the-art high-accuracy GPS, and so on. I firmly believe that everyone should have the *right* to edit everything if they so wish, but I also want everyone to have the best possible information about the existing data when he edits it; that would (ideally) also include warnings about overwriting potentially reliable/high-precision data with something that is likely to be of lesser quality. Warnings only, because it might not be, but at least let people know if they want to. So, in the long run we have to (a) let the mapper know exactly what he is doing, and (b) give the users a chance to determine themselves whom they want to trust. My idea was a step in that direction. I don't mind if we decide to ignore this for another year or two, but it is absolutely clear to me that these things will come, in one way or the other, and a good monitoring/notification system solves only a small part of this. (And layers may be an interesting concept but they don't either.) 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] A new take on the mutable idea
Frederik Ramm wrote: Improve according to what the person editing it thinks - yes. For example, and sorry for being pessimistic, I believe that a lot of OSM contributors would be perfectly capable to insert a few nodes into an administrative border and move them around just to make the line look less jagged on the map - improve it, as they wold say. If their editor would inform them that they are editing the administrative border as copied from some official publication, then they still *could* edit the border if they e.g. had information about said official publication being wrong or outdated, but they would likely refrain from editing it otherwise. Which I'd find desirable. Relating mutability to the source of the data makes much more sense than some kind of this is read-only because I, osm user 123, say it should be and if you change it I'll revert your change approach. I wouldn't think twice about improving an obviously coarse way whose source was Landsat/NPE, adjusting it to match a better-looking GPS trace. I would think twice about improving a way which probably originated from a GPS, although I'd do it if I had a probably-better GPS trace (e.g., captured both sides of a road so could see the old trace was off to one side). I would definitely think twice about improving something which carried a we got this data from official source, are you sure your source is better? warning. If I had a better official source then replacing the existing way might make sense, but at least I won't degrade a bad looking boundary with something that looks better but is actually less correct. -dair ___ d...@refnum.com http://www.refnum.com/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
On Sun, Jun 21, 2009 at 12:43 PM, Frederik Rammfrede...@remote.org wrote: If their editor would inform them that they are editing the administrative border as copied from some official publication, then they still *could* edit the border if they e.g. had information about said official publication being wrong or outdated, but they would likely refrain from editing it otherwise. Which I'd find desirable. isn't this what the source tag is for? cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
Le dimanche 21 juin 2009 12:49, Richard Fairhurst a écrit : Frederik Ramm wrote: However, we'll have more and more imports like boundaries, seamarks and so on, which I like to consider mutable for people who know exactly what they're doing. Is this actually a real-world problem right now, or something we think might possibly one day become one? It is, In france we are actually importing admin_level=8 boundaries from an official source and we have some fears about users modifying it without really understanding why it is so. Our source is however not perfect (projection problems, semi-manual imports,...) and users are encouraged to modify it when they have good reasons to do so. But nothing forbids anyone to do a mistake and cut/move/change nodes/ways incorectly. For now, we are just using some tools to monitor the data and try to spot such erroneous modifications + adding wiki page to explain the import. But we put an important trust on the user. A solution such as the one proposed by Frederik could help, but I do personnaly fear a bit that the editor will one day drop dozen pop-ups repeating are you sure ? because XXX ending with a windows-minded user just to repeatidly hit Yes I am JOSM dialog box : - You are editing a node out of your bbox, are you sure ? - You are modifying an official imported source, are you sure ? - The source tag is XXX are you sure yours is better ? - The quality of this node is GPS retrieved with a Garmin X, is your GPS at least a Magelan Y ? - You are modifying an extended-multipolygon relation element, are you aware of this wiki page ? - Your changeset need a comment, an empty one might leads to a revert, are you sure ? I know I'm going too far, and I also know that as data amount increase we'll probably need some quality insurrance monitoring tools, but I'am considering the defaults being warn and trust instead of guilty and revert PS: Rigth now, I'm using the note tag when I feel the need to give an estimation of the quality of my contribution in the hope that a new user will consider it before making some approximative changes -- sly sylvain letuffe ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
On Jun 21, 2009, at 6:49 AM, Richard Fairhurst wrote: Frederik Ramm wrote: However, we'll have more and more imports like boundaries, seamarks and so on, which I like to consider mutable for people who know exactly what they're doing. Is this actually a real-world problem right now, or something we think might possibly one day become one? Legal boundaries *aren't* a real-world problem right now? We need to have them in OSM otherwise people will start adding them. And yet, if the data came from an import from the governmental body responsible for maintaining the legal description, what justification could anybody have for changing them (pace anarchists, but even anarchists will recognize land registries as long as they're voluntary). -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
On Sun, Jun 21, 2009 at 2:08 PM, Russ Nelsonr...@cloudmade.com wrote: On Jun 21, 2009, at 6:49 AM, Richard Fairhurst wrote: Frederik Ramm wrote: However, we'll have more and more imports like boundaries, seamarks and so on, which I like to consider mutable for people who know exactly what they're doing. Is this actually a real-world problem right now, or something we think might possibly one day become one? Legal boundaries *aren't* a real-world problem right now? We need to have them in OSM otherwise people will start adding them. And yet, if the data came from an import from the governmental body responsible for maintaining the legal description, what justification could anybody have for changing them (pace anarchists, but even anarchists will recognize land registries as long as they're voluntary). we went over this before: if it isn't editable, it shouldn't be in OSM. there's nothing to stop people adding 3rd party datasets into renderings based on OSM or using these boundaries to perform analysis on OSM data. i can't see a good reason why OSM has to import *everything* - we're not the ultimate data repository, we're the free *wiki* world map. also, we should all be trying to follow the on the ground rule [1] and verifiability rule [2] - so if something isn't surveyable on the ground, it probably shouldn't be in OSM. there's yet another problem with legal boundaries; usually they're defined as following existing features, such as rivers, coasts, mountain ranges and even roads. so what happens when we improve the positional accuracy of that feature - shouldn't the boundary be updated too? cheers, matt [1] http://wiki.openstreetmap.org/wiki/Disputes#On_the_Ground_Rule [2] http://wiki.openstreetmap.org/wiki/Verifiability ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
On Jun 21, 2009, at 10:15 AM, Matt Amos wrote: we went over this before: if it isn't editable, it shouldn't be in OSM. And yet state and county borders are already in OSM. You seem to not be paying attention to my point: that if we DON'T have these important legal boundaries in OSM, people will add them. Don't believe me? Try deleting the New York State border with Pennsylvania, and see how long it takes for somebody to revert your edit, or worse, add it back in as a new set of nodes and ways. Yes, I acknowledge your point about people being able to edit things, and being able to verify things on the ground. If (as I assert) it's not possible to keep these things out of the map, shouldn't we take steps to ensure that when they're in the map, they're as correct as they can be? -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A new take on the mutable idea
Hi, Matt Amos wrote: absolutely. if you're interested in monitoring the state borders then you'll be interested in a service to get emails or an RSS feed of that area. that way you can watch over that area and ensure it's correct. I'm all for cool monitoring features but I'd really love people to have a chance to behave well *before* they get 100 e-mails by all those people monitoring something. I really think that having an advance warning would contribute to overall mapper happiness. A personal, individual message from mapper A to mapper B about A's supposedly bad edit is much worse karma than some note on an object saying if you modify this, you'd better know what you're doing. Maybe a super-cool editor could tap into the monitoring system and tell people the feature you are editing is being monitored by 1,234 people ;-) 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] A new take on the mutable idea
On Sun, Jun 21, 2009 at 8:03 PM, Frederik Rammfrede...@remote.org wrote: Matt Amos wrote: It is very easy to edit objects without ever looking at the source tag. If that were made impossible, yes, then you are right; but I think it is impractical. more impractical than inventing a new tag and trying to ensure that all editors support it? You have to change all editors either way, don't you? that's true, but at least source is an existing tag. there's another problem for my source idea: it's actually perfectly possible for two different editors to have derived different data from the same source. e.g: the first editor does a coarse pass over Y! and another follows up with a more accurate tracing. there's no reason for source to change, so we really do need something else (e.g: putting source on the changeset instead). i think we have a philosophical difference here - i don't think we should be presenting users with warnings, especially if these special tags would be present on most imported data (e.g: CanVec, etc...). Maybe warnings is too strong a concept. I just want every person editing the data to have the best possible knowledge about the provenance and accuracy of the data they are about to edit, and have a clear picture of the accuracy of their own measurements in comparison. And I want to work towards a culture where people actually take this seriously. i couldn't possibly disagree - clearly every user should have access to as much information as possible. would a possible solution be for the editor to maintain some information on the user's data collection method (i.e: the user has selected the model of GPS or something) and, where the original data is more authoritative (fsvo), puts an entry in the data validation layer (or the editor's equivalent of)? i don't see how your original suggestion provides any information about diligence, other than that the user is a member of a privileged few who know the secret rule or use a particular editor which handles it for them. Well it wouldn't have been a secret rule, it would of course be available on the Wiki etc.; if someone had gone through the effort of looking it up, or at least through the effort of specifically instructing his editor to make that change (rather than accidentally moving a whole street from Vienna to the US), then I could assume a certain diligence at work. or they're using an editor which has those rules already built-in ;-) cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
