Re: [Potlatch-dev] Bug: Selection broken after save
On Sat, Mar 12, 2011 at 11:47 PM, Richard Fairhurst rich...@systemed.net wrote: NopMap wrote: That is the number P2 displays in the help dialog. ...if you're using an old (svn) version. If you go to osm.org and click Edit, right now, it says: Version: 0.5. Build: 0.5-291-g0c68ba6. http://wiki.openstreetmap.org/wiki/Potlatch_2/Developer_Documentation/git will explain how to download the code from git for yourself. http://random.dev.openstreetmap.org/potlatch2/potlatch2.html has not yet been updated, as far as I can tell, to build from git rather than svn. Dave...! Fixed, now uses git master branch. Dave ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Introducing Magic Roundabout tool
On Sat, Feb 26, 2011 at 2:08 AM, Steve Bennett stevag...@gmail.com wrote: On Sat, Feb 26, 2011 at 12:43 AM, Andy Allan gravityst...@gmail.com wrote: This is where I could be wrong, but I think that it's critical to the redo part. When undo'ing an action the action is added to the redo list, so if adding an action has side-effects that'll blow up during redoing the action. Also, if the action works based on side effects that aren't tracked within the action itself, then it won't work properly when being redone. Ok, I obviously wasn't explaining myself well, so I'll let some code do the talking: http://trac.openstreetmap.org/changeset/25431 This solves my problem: actions are carried out immediately, and then added to the MainUndoStack later. It's not that the actions had side effects, I just needed access to the main effect immediately. The main-effect as you call it, is now becoming a side-effect of adding the action to the composite action. What you've done in that changeset is break the encapsulation, and screw up the contract of UndoableAction.doAction(). The way to do what you want is to make your own action and perform the changes in the doAction method. ie: Create action X Add to main undo stack x.doAction: create, push and execute action A create, push and execute action B create, push and execute action C x.undoAction: pop and undo C pop and undo B pop and undo A Dave ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Introducing Magic Roundabout tool
On Sat, Feb 26, 2011 at 2:23 AM, Steve Bennett stevag...@gmail.com wrote:
On Sat, Feb 26, 2011 at 2:52 AM, Dave Stubbs osm.l...@randomjunk.co.uk
wrote:
Yeah, what we have is a nested and OO implementation of a simple stack
with markers. This allows you to do cool stuff like encapsulate
complex actions without bothering the user with extra undo steps or
adding lots of boiler plate code around the RecordAction stage.
Don't get me wrong, I think the implementation is fantastic. The only
thing I'm commenting on is some of the unintuitive naming and
mechanics.
For example, passing a function to an operation, where the function
represents a storage operation for an undoable action...is not very
intuitive. In practice, exactly one of two things gets passed to those
functions: either MainUndoStack.getInstance().push, or some
CompositeUndoableAction.addAction. It would therefore be possible to
replace declarations like this:
public function createWay(tags:Object, nodes:Array,
performCreate:Function):Way {
var way:Way = new Way(nextNegative, 0, tags, true, nodes.concat());
performCreate(new CreateEntityAction(way, setWay));
...
with
public function createWay(tags:Object, nodes:Array, actionStack:
CompositeUndoableAction=null):Way {
var way:Way = new Way(nextNegative, 0, tags, true, nodes.concat());
recordAction(actionStack, new CreateEntityAction(way, setWay));
...
where recordAction is:
protected function recordAction(stack: CompositeUndoAbleAction,
action: Action):void {
if (stack)
stack.push(action)
else
MainUndoStack.getInstance().push(action);
}
Personally, I think passing either a composite action stack, or null,
to an operation is a lot more intuitive than passing a function. And
it would make some simpler:
w = createWay({}, nodes);
Now, the fact that it's creating an action which is being placed on
the main undo stack is totally invisible. Magic behind the scenes, and
all that.
Whether passing functions or objects is more intuitive kind of depends
where you're coming from :-)
The main difference is the null passing -- and you can do that with
the function.
Personally I prefer the explicit decision of the caller as to where to
put it, but there's not a lot in it.
Dave
___
Potlatch-dev mailing list
Potlatch-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Introducing Magic Roundabout tool
On Fri, Feb 25, 2011 at 1:43 PM, Andy Allan gravityst...@gmail.com wrote: On Fri, Feb 25, 2011 at 1:17 PM, Steve Bennett stevag...@gmail.com wrote: Does this absolutely have to be the case? I can't quite understand, from a theoretical point of view, why this principle is necessary. Why not add the action to a stack, and also carry it out now? What's the benefit of maintaining the current state as long as possible, then doing all the actions in one flurry? This is where I could be wrong, but I think that it's critical to the redo part. When undo'ing an action the action is added to the redo list, so if adding an action has side-effects that'll blow up during redoing the action. Also, if the action works based on side effects that aren't tracked within the action itself, then it won't work properly when being redone. Hence everything needs to be done by adding things to an action, and it needs to be completely self-contained so it can be moved back and forward between the different stacks. But I might be wrong. You're not. That's exactly why you need to do it that way -- if you're doing a simple composite undoable action anyway. It may get a little confusing, but you can of course create your own UndoableAction class. In that case during the doAction method you're free to make any direct changes you like, calling other action's doAction methods to do so. The only catch is that you have to be able to put things back again how you found them (probably by calling undoAction in the right order). And then properly handle a redo. The easiest method of doing that is override CompositeUndoableAction, pushing actions as you do them, allowing the undo be handled normally, except that it'd have to clear the action list when done. It generally cleaner and safer to use the existing actions and compose. If you don't understand what I just said then I suggest sticking to the existing actions as there's less scope for breaking things! And just to add a bit more incoherent rambling, would a simpler model be, instead of passing around these stacks everywhere, to have just a main undo stack with two functions: 1) RecordAction which adds an action to the undo stack, and carries it out. 2) FinishUndoBlock, which groups all actions since the last time it was called, into one block, which will all be undone with a single keystroke. Sort of the equivalent of closing a changeset. That's just an unclear representation of a composite action! The RecordAction is undo.push, the FinishUndoBlock is MainUndoStackaddAction(), and the carrying-out-before-we're-finished is the bad idea that we need to avoid. Yeah, what we have is a nested and OO implementation of a simple stack with markers. This allows you to do cool stuff like encapsulate complex actions without bothering the user with extra undo steps or adding lots of boiler plate code around the RecordAction stage. Dave ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Potlatch history
On Wed, Apr 21, 2010 at 10:20 AM, Maarten Deen md...@xs4all.nl wrote: It seems to me that the history function in Potlatch (shortcut key H) has a bug. Example: way 6313107, which is the southern part of the railway at http://www.openstreetmap.org/edit?lat=50.81lon=5.717638zoom=18. When I view the history in Potlatch, it tells me the previous version is from Seat Ibiza and there are some 16 older versions. When I take the history from http://www.openstreetmap.org/browse/way/6313107/history, OSM tells me there are 5 versions, none of which have been made by Seat Ibiza. I see these inconsistencies on more ways than just this one. Take any way in that editwindow. Or is there some logic behind the Potlatch history that I'm missing? The nodes have been moved -- Potlatch takes this into account where as the API does not. (ie: Potlatch's history is way more useful :-)) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Split osm line with perl
On Sun, Nov 29, 2009 at 11:41 AM, Lennard l...@xs4all.nl wrote: Maarten Deen wrote: I've tried a few things, but I'm not fluent in perl. My problem at the moment is that splitting a line on the space character seems logical, but you run into problems if a value has a space in it. So splitting something like tag k=name v=foo bar/ will split the value foo bar also. You have to be fluent in regexes, not perl as such. The trick is to match the quote, then to match anything that is not a quote, followed by a quote. And then hope that the attributes are in the order you're expecting, and that the XML has used rather than '. And in the example code given below hope that only one space was used. If you know the OSM XML source that's probably not such a massive issue. Don't forget to unescape any XML entities in the key or value as well. The real trick of course is to use an XML parser which handles all of this for you. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] potlatch breaking B38a
On Thu, Nov 19, 2009 at 4:30 AM, Marcus Wolschon marcus.wolsc...@googlemail.com wrote: On Thu, Nov 19, 2009 at 4:01 AM, Richard Fairhurst rich...@systemed.net wrote: Marcus Wolschon wrote: ...no chance that users might actually read some documentation? No, of course not. Silly me. We`ve all been spoiled by WindowsCo just expecting ctrl+c to copy, enter to push a button that has focus, alt to get to the menu, ... Seriously, noone reads documentation that comes with graphical software unless there is a feature the user knows exists but can´t get to work. Where is the sourcecode for potlatch and what is needed to compile it? I may try to add a singe ways merges, press z to undo like the message it displayes after deleting something. http://wiki.openstreetmap.org/wiki/Potlatch/Development_overview Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 3:25 AM, SteveC st...@asklater.com wrote: I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. Closest I got was the osmosis tagtransform plugin [1]. I made that because people keep insisting on tagging things like highway=path;bicycle=yes|designated, which is essentially like a highway=cycleway and we want those rendered on the cycle map. Now for various reasons, mostly due to laziness, version mismatches, and not being entirely sure about what the different path combinations mean, this has never been deployed on the cycle map for real, but anyway. What I was originally thinking was that what would be nice (and therefore almost certain to be never developed) would be a proper tagging app on the OSM website which let people describe their tagging schemes. Part of that would then be how to get from one scheme to another. In thinking how you might do that some of the weird and wonderful ways that schemes differ come to mind and tagtransform was born. Back to the likenesses, saying an autobahn is like a motorway makes sense, is a good start, but very limited. One of the first problems you hit is what like actually means. In the UK a lot of footpaths look a lot like a lot of bridleways. So therefore highway=footway is like highway=bridleway, one allows horses but the other doesn't otherwise they're mostly the same. But a lot of foot paths are like cycle paths, which are a lot like tracks which are a lot like service roads which are a lot like unclassified roads. Anyway it turns out that just about all roads and paths are transitively like each other which is a little confusing and not a very useful result. With the likenesses XML you could sort this out with overlapping likeness groups but it quickly becomes a problem for renderers if they're trying to find things which are like a footpath, and things which are like a cycle path, because lots of things are like both and you don't know why. So the way in which something is alike is actually very important. What may be a better idea is object hierarchies -- ie: is-a links or mediawiki-like categories. This way you end up doing things the other way round... feature tag k=highway v=motorway/ is-aroad/is-a is-amajor-road/is-a is-abiggest-roads-we've-got/is-a is-aroad-with-speedlimit/is-a is-aroad-which-meets-uk-reg-blah15/is-a is-aroad-which-meets-eu-reg-blah01/is-a /feature feature tag k=insert german for road or whatever v=autobahn/ is-aroad/is-a is-amajor-road/is-a is-abiggest-roads-we've-got/is-a is-aroad-which-meets-de-reg-blah97/is-a is-aroad-which-meets-eu-reg-blah01/is-a /feature (that's very flat, there's no reason you couldn't actually structure it a bit by introducing the categories as objects with categories, and those is-a parts could easily be OSM tags specifying actual speedlimits etc with the expectation these represent the defaults) So now the renderer can just go for the biggest-roads-we've-got category, and render anything that matches. And surprise surprise it ends up looking a heck of a lot like an editor presets description file [2]. And that fact is interesting because of the question: why didn't we just tag all the motorways like that in the first place? Screw highway=motorway, just add road=yes;major_road=yes;biggest_road_we_have=yes... I can think of a couple of reasons. - we're all lazy and don't want to type it -- editor presets can negate that one - the german government decides to impose a speedlimit so we immediately get to change the autobahn definition rather than retag all the objects using an evil bot One of the big questions is whether all of this would make life easier or harder for the renderers -- it would definitely raise the tech start bar. Dave [1] http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform [2] See the potlatch 2 map-features.xml http://trac.openstreetmap.org/browser/applications/editors/potlatch2/resources/map_features.xml -- but there you're limited to one category because it's more for menu structure than proper categorisation. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 1:33 PM, John Smith deltafoxtrot...@gmail.com wrote: 2009/10/1 Dave Stubbs osm.l...@randomjunk.co.uk: That argument is bogus. It's much easier to do the translations on a couple of servers rather than make the 100,000's editors more complicated so that they use more laptop battery and make all the mappers have to go home early. Well JOSM is already doing it, so it can't be that bogus... Oh yes, selective quoting is also a classic. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Deeplink for Potlatch Custom Background
replace all the %26 with %2526 and it works. On Sun, Sep 27, 2009 at 9:10 PM, M. Emch nomorebigf...@gmx.ch wrote: Hi Dave Thanks for trying to help. Maybe it's a problem in my english skill or technical. %-|. Can you give me an example that works? Regards Martin Then i got this: http%3A%2F%2Fintegrate.ch%2Fapp%2Ftile.php%3Flayer%3Dams250%26z%3D%21%26x%3D%21%26y%3D%21 When i call this in browser: http://www.openstreetmap.org/edit?lat=31.6026lon=-5.5894zoom=13tileurl=http%3A%2F%2Fintegrate.ch%2Fapp%2Ftile.php%3Flayer%3Dams250%26z%3D!%26x%3D!%26y%3D! Then only this is entered in the Custom Background field: http://integrate.ch/app/tile.php?layer=ams250 There is something wrong with url encode/decode? How to proper encode that? I think it's currently broken. You have to double encode the s for it to work. Dave -- View this message in context: http://www.nabble.com/Deeplink-for-Potlatch-Custom-Background-tp25618987p25637157.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ 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] Deeplink for Potlatch Custom Background
On Sat, Sep 26, 2009 at 7:24 PM, M. Emch nomorebigf...@gmx.ch wrote: Hi Richard Thanks for fast answer! I have still some problems. I encoded this http://integrate.ch/app/tile.php?layer=ams250z=!x=!y=! here: http://www.whatsmyip.org/stringencoder/ Then i got this: http%3A%2F%2Fintegrate.ch%2Fapp%2Ftile.php%3Flayer%3Dams250%26z%3D%21%26x%3D%21%26y%3D%21 When i call this in browser: http://www.openstreetmap.org/edit?lat=31.6026lon=-5.5894zoom=13tileurl=http%3A%2F%2Fintegrate.ch%2Fapp%2Ftile.php%3Flayer%3Dams250%26z%3D!%26x%3D!%26y%3D! Then only this is entered in the Custom Background field: http://integrate.ch/app/tile.php?layer=ams250 There is something wrong with url encode/decode? How to proper encode that? I think it's currently broken. You have to double encode the s for it to work. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Excessive version count
On Thu, Sep 17, 2009 at 2:10 PM, Ian Dees ian.d...@gmail.com wrote: On Thu, Sep 17, 2009 at 5:16 AM, Jonathan Bennett openstreet...@jonno.cix.co.uk wrote: Ian Dees wrote: Perhaps the API should ignore (i.e. not increase rev #'s) changes that don't actually change anything? The idea isn't a bad one, but the implementation would need to be slick as to avoid bogging down the server -- it would double the number of DB queries per upload. It shouldn't have to perform more DB queries. The changeset already has to be in memory (or at least available) at the time of changeset close. Before the changeset is actually applied to the database, some sort of collation could occur which would knock out all node changes if they don't result in any change. Changesets have nothing to do with it, especially changeset closing (when the close happens all the data is already committed). It's at the node/way/relation update level that that would be needed. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] what server next?
On Tue, Sep 8, 2009 at 10:09 PM, Micha Ruhgnub...@gmail.com wrote: Hi 2009/9/8 Frederik Ramm frede...@remote.org Your idea suffers from the fundamental problem that it only counts those having last touched an object. No, it doesn't. I thought of a mechanism to avoid that: Users adding ways/pois get a score of 3 per way/poi added, users adding more tags to existing way/pois get a score-point of 1 for each edit. Import sources get a 0.1 score-point per way/poi. One could also think of more sophisticated factors to calculate score-points. - initial creation: 3 score-point factor - adding name: 2 - adding other tag: 1 - import sources: 0.1 - mass changes: 0.1 / change - bots: 0 What about a limit for score-point gaining per hour/day for a user? * Of course, the score-point factors are subject to fine-tuning! They must be adjusted, when one creates such a solution. And welcome to the real world -- if you put up a metric for people to achieve they'll happily manipulate it to show up on top. On your original you only made it mean I have to make 3 times as many useless edits to own each tile. Adding name, 2 points... excellent, I guess I should first delete the name, then readd it. 1 point for a tag... thank you utf8 character set! 3 points for initial creation... well, why waste time putting stuff in the right place, someone else can move it for 0 points at some future time. How do we find bots? What's the definition of a mass change that's somehow different to a prolific mapper? Does it seem worth the effort? Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A better way to watch nodes and ways?
On Wed, Aug 12, 2009 at 7:06 PM, Ian Deesian.d...@gmail.com wrote: On Wed, Aug 12, 2009 at 1:01 PM, John McKerrell j...@mckerrell.net wrote: Perhaps if you entered your username it could report all the elements that change away from your username? I seem to remember having a discussion ages ago about uses for a realtime feed from the database. This might be one of them... We don't care (too much) if we miss some of the stream, but when it's working we could send out notifications to those that are interested in certain nodes. Also, since it's an XML stream we could use XSLT to quickly match any changes that people are looking for. We already have next to real time information in the form of minute diff files. You don't need a stream to do notifications (in fact it would probably make it harder). And just as a note of warning... XSLT has never been known for quickness... anything with a SAX parser will do for simple notifications of this kind. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Deleting TIGER node tags
On Wed, Jul 22, 2009 at 10:46 AM, John Smith delta_foxt...@yahoo.comwrote: --- On Wed, 22/7/09, Marc Schütz schue...@gmx.net wrote: Should the editors be changed to automatically remove created_by? Or maybe just well-known values like /JOSM.*/, /Potlatch.*/? Right, wrong or indiff I've been removing them on things I edit as I see them as a waste, since it only tells you what created them, not the last editor that edited them and so does nothing to figure out most editing bugs in apps, except perhaps on new nodes/ways/etc. Well that wasn't necessarily true. Potlatch always updated it for instance. But anyway, all the editors should be adding the created_by tag to the changeset now instead, so there's no new ones being created. I remove them if I'm editing something anyway and I can be bothered, but there's not much point in going out of your way. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] problem with changesets and bulk_upload.py
2009/7/6 Mikel Maron mikel_ma...@yahoo.com: Recently uploaded the Arabic names for all countries. Rather than updating the existing nodes as expected, it created new nodes. http://www.openstreetmap.org/browse/changeset/1707270 http://www.openstreetmap.org/browse/changeset/1725949 I used bulk_upload.py, processing an osmChange file, with all the nodes wrapped inside a modify tag. Does this not work as expected??! How should it be done? Don't use bulk_upload.py would be a good start. From looking at the code it doesn't take osm change files at all -- it takes JOSM style osm files, which it assumes contains entirely original content. It then proceeds to do no input validation and arbitrarily tree walks the XML file you give it looking for node way relation elements to upload by creating new objects if they have no action attribute, or it doesn't say modify or delete, and doing modifies and deletes where the action attribute says to. Basically it looks like it was hacked up to do a particular job, by someone who knew how it worked and therefore didn't bother with all of the fun you need when you let something like that loose with the population at large. Once the proper method is sorted out, I'll delete these duplicate nodes. So you have 5 choices: - rewrite your input into the format expected by bulk_upload.py (and test it on a dev server or something first) - rewrite bulk_upload.py to not be so crap - use bulk_upload.php (also doesn't take osmChange files though) - write your own bulk uploader that takes osmChange - wait till someone else does that (I was working on one but got distracted by potlatch2) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Deleting TIGER node tags
2009/6/27 Minh Nguyen m...@zoomtown.com: Ngày 6/26/09 12:59 PM, Andy Allan viết: Hello Devs, source = tiger_import_dch_v0.6_20070813 tiger:county = St. Louis, MO tiger:tlid = 100111260:100111261:10055:10059 tiger:upload_uuid = bulk_upload.pl-6143e1a9-589d-43a0-9248-e95658773ef4 Stuff like this appears on every node in the US, which is a pain. I reckon it's all pointless, since all that info is on the ways in the first place, and it's worth deleting them. Here's some numbers from Matt to consider: Tiger node tags make up 85.43% of all node tags and take up: * 12.97% of the bzipped planet size (805Mb). * 34.68% of the uncompressed planet size. * 42.20% of the lines in the planet. * 31.51% of the parsing time of the planet (based on xmllint --stream). So, can anyone think of a good reason to keep them? Should we just delete tags like these? I'd love to hear if anyone think we should keep them (bearing in mind all the info, including ids, would remain on the ways in any case). http://wiki.openstreetmap.org/wiki/TIGER_fixup/node_tags Cheers, Andy The tiger:county data is actually kinda useful. I've been using it to know where the county lines are according to TIGER, to make the county boundaries more precise in my area. It's also nice to see tiger:county values on nearby streets when mapping power lines in Potlatch, so I know just how carried away I got without having to leave the editor and zoom way out. But that's probably a fringe usage. :) Andy's only talking about the node tags at the moment -- this data will still be on the ways for now so you'll still be able to do these things. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] need help on bulk import of osmchange
2009/5/27 Gleb Smirnoff gleb...@glebius.int.ru: Hello, we are working on fixing things after one automated import that covered a large part of Russia. The import created many nodes, that describe villages and hamlets. It had two problems: 1) Many nodes where imported twice. 2) All names where incorrectly prefixed. I have created a fixed version of database dump, and with help of osmosis created and OsmChange file. I have tried to upload it using python script: http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/ The script reported about several commits (more than a dozen), and returned no errors. However, it appeared that only modify sections of the OsmChange file were processed. All delete section were not. Here is the OsmChange itself: http://glebius.int.ru/tmp/delta.osc Can anyone competent in this area review it and explain where is the problem? The script you link to isn't expecting an osc file. It appears to be expecting a .osm file with extra action=... attributes on each way/node/relation except that it tries to create by default so you probably have more than one copy now. It obviously doesn't have much in the way of input validation or error checking. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] need help on bulk import of osmchange
2009/5/27 Dave Stubbs osm.l...@randomjunk.co.uk: 2009/5/27 Gleb Smirnoff gleb...@glebius.int.ru: Hello, we are working on fixing things after one automated import that covered a large part of Russia. The import created many nodes, that describe villages and hamlets. It had two problems: 1) Many nodes where imported twice. 2) All names where incorrectly prefixed. I have created a fixed version of database dump, and with help of osmosis created and OsmChange file. I have tried to upload it using python script: http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/ The script reported about several commits (more than a dozen), and returned no errors. However, it appeared that only modify sections of the OsmChange file were processed. All delete section were not. Here is the OsmChange itself: http://glebius.int.ru/tmp/delta.osc Can anyone competent in this area review it and explain where is the problem? The script you link to isn't expecting an osc file. It appears to be expecting a .osm file with extra action=... attributes on each way/node/relation except that it tries to create by default so you probably have more than one copy now. It obviously doesn't have much in the way of input validation or error checking. Yes... lots of duplicates... http://api.openstreetmap.org/browse/changeset/1326916 ... http://api.openstreetmap.org/browse/changeset/1327131 Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] hard drive size
2009/5/11 Grant Slater openstreet...@firefishy.com: Iván Sánchez Ortega wrote: El Lunes, 11 de Mayo de 2009, Sam Mor escribió: is a Hard drive of 500 Gig enough for a planet map rendering? It should be. If you check the wiki and munin, you'll see that the mapnik tile server currently uses 75% of a 500 Gb RAID. It depends on the rendering system used. See: http://lists.openstreetmap.org/pipermail/dev/2008-April/009736.html Tile on avg served by tile.openstreetmap.org: ~6.5KB. opencyclemap.org: quoted as being at least 4x bigger. Average served tile for the cycle map is 41KB, so about 6x bigger... but we don't have as many empty tiles which probably explains the difference. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Grumble, grumble
i don't understand what you're trying to say. changesets have bboxes, yes. they're calculated from the data, not exposed in the URI like XAPI does. I start editing Josm/Potlatch/Merkaartor says: for the next 15 minutes bbox lat/long is locked for editing. For properties highway=* etc. The editor pings back after the period to maintain a lock. That sounds wonderfully scalable. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tagtransform
I'll get it working with latest osmosis today and upload it to svn. 2009/5/3 Steven te Brinke s.tebri...@student.utwente.nl: Hello, Is the tagtransform plugin still maintained? Because it looks like the same problem as 3 months ago still exists: it does not work with the latest release of Osmosis. The plugin looks very useful to me, so if noone maintains it, I'll give refactoring it a try, but because I have no experience with coding Osmosis plugins, I would prefer if someone else could do this. Regards, Steven Dave Stubbs schreef: 2009/2/13 marcus.wolsc...@googlemail.com: On Thu, 12 Feb 2009 21:34:21 +0100, Rolf Bode-Meyer rob...@gmail.com wrote: That indeed looks promissing. Unfortunatelly one seems to have be a programmer to use osmosis. Every problem is presented as a Java exception. Some of them contain at least a faint idea of what could be wrong. But something like this leaves me clueless: java.lang.AbstractMethodError at com.bretth.osmosis.core.pipeline.common.TaskManagerFactory.createTaskManager(TaskManagerFactory.java:72) This looks like the plugin was compiled against a different version of osmosis. My guess would be, that it was build against the latest development-version and you are using the last stable release of osmosis. Something like this. It's something Randomjunk the developer of the plugin has to fix. I have not seen any contact-info on his wiki-user-page so I hope he reads this mailing-list. It was built against v0.29 of Osmosis which is the version I'm still using -- it should work with that. I hadn't realised the plugin interface had changed. I'll have to take a look some time. Dave ___ 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] Tagtransform
OK, now updated to work with osmosis 0.30 It has tasks for 0.5 and for 0.6, the default is now 0.6. Source is in SVN here: http://trac.openstreetmap.org/browser/applications/utils/osmosis/plugins/tagtransform 2009/5/4 Dave Stubbs osm.l...@randomjunk.co.uk: I'll get it working with latest osmosis today and upload it to svn. 2009/5/3 Steven te Brinke s.tebri...@student.utwente.nl: Hello, Is the tagtransform plugin still maintained? Because it looks like the same problem as 3 months ago still exists: it does not work with the latest release of Osmosis. The plugin looks very useful to me, so if noone maintains it, I'll give refactoring it a try, but because I have no experience with coding Osmosis plugins, I would prefer if someone else could do this. Regards, Steven Dave Stubbs schreef: 2009/2/13 marcus.wolsc...@googlemail.com: On Thu, 12 Feb 2009 21:34:21 +0100, Rolf Bode-Meyer rob...@gmail.com wrote: That indeed looks promissing. Unfortunatelly one seems to have be a programmer to use osmosis. Every problem is presented as a Java exception. Some of them contain at least a faint idea of what could be wrong. But something like this leaves me clueless: java.lang.AbstractMethodError at com.bretth.osmosis.core.pipeline.common.TaskManagerFactory.createTaskManager(TaskManagerFactory.java:72) This looks like the plugin was compiled against a different version of osmosis. My guess would be, that it was build against the latest development-version and you are using the last stable release of osmosis. Something like this. It's something Randomjunk the developer of the plugin has to fix. I have not seen any contact-info on his wiki-user-page so I hope he reads this mailing-list. It was built against v0.29 of Osmosis which is the version I'm still using -- it should work with that. I hadn't realised the plugin interface had changed. I'll have to take a look some time. Dave ___ 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] User preference for editor
2009/5/1 Frederik Ramm frede...@remote.org: Hi, Thomas Wood wrote: Others have stated before that the mime type option is really the only sane one for this sort of thing, rather than the awful localhost URIs the the JOSM remote control uses presently. Call me biased but I find a certain elegance in the way these awful localhost URIs do not require any configuration. You do not have to register JOSM as an application for a certain MIME type; you do not have to fiddle with your browser configuration to install a helper application; just fire up JOSM and it works. Granted, the localhost URIs fail miserably if you do not have JOSM running already. If it were'nt for the same-origin policy one could at least call them using XMLHttpRequest and present a popup on error... (I'd love to be able to write: You can carry JOSM with you on an USB stick and run it in an Internet cafe with no privileges on the machine, but unfortunately we still lack a --my-home-directory-is-on-the-stick option.) Over eager firewall's permitting of course. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Cloudmade routing for OSM rails_port site.
2009/4/29 Richard Fairhurst rich...@systemed.net: Nick Black wrote: To your point about integrating other people's services, I think its clear. Whatever the best service available is should be used. Best is in the eye of the beholder. Subject to minimum quality standards (no long outages, results not completely bogus) and a common API, we should let the user choose between available services. I could in theory code a routing service that was better than CM's for validating the type of mapping I tend to do (i.e. long cycle routes) but less useful for housing estates. It's exactly the same as with the map layers. I think (awaits flames) that Steve Chilton's Mapnik layer is the best OSM cartography there is at present, and if you apply commonly-accepted cartographic standards than that's probably not just opinion, it's objective truth. Doesn't have contour lines though does it? I know what the best layer _really_ is :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Please advise; I really don't get how this can corrupt so badly
2009/4/6 Stefan de Konink ste...@konink.de: On Mon, 6 Apr 2009, Dave Stubbs wrote: Anyway, Shaun refactored the whole lot for API 0.6. It now atomically checks relation consistency within the rails models when doing an update rather than relying on the caller to do it. So this should be fixed in a couple of weeks a long with everything else :-) So if this is working if you uncomment it; can you uncomment it? I don't know if it is or isn't. I know 0.6 does work. So I'd just wait two weeks. It's not going to cause the world to end in the meantime. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Please advise; I really don't get how this can corrupt so badly
2009/4/6 Richard Fairhurst rich...@systemed.net: Stefan de Konink wrote: Now how is it possible that there was no 415 on that update? I'm going to pass on this one as I didn't write the Potlatch relations code, Dave did - any thoughts? I'm guessing that's here: http://trac.openstreetmap.org/browser/sites/rails_port/app/controllers/amf_controller.rb#L309 # BUG: the following is commented out because it always fails on my # install. I think it's a Rails bug. #if !rel.preconditions_ok? # return -2, Relation preconditions failed As I remember it is was some kind of composite keys issue throwing a random exception if you tried to check the relation members... this was before TomH went into overdrive fixing the composite_keys rails extension to actually work. It must never have been uncommented. Anyway, Shaun refactored the whole lot for API 0.6. It now atomically checks relation consistency within the rails models when doing an update rather than relying on the caller to do it. So this should be fixed in a couple of weeks a long with everything else :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM: Several tags with same key
2009/4/2 Frederik Ramm frede...@remote.org: Hallo, Andreas Kalsch wrote: I'd like to add several tags with the same key. In the most cases this no good practice, but with urls it makes sense, e.g. to add several images to one feature. This was never supported by JOSM, and while it is currently still possible to have several tags with the same key in the database, this will not be allowed any longer as soon as we have switched to API 0.6. And while currently possible in the database, it doesn't work in the current API, so you can't actually enter them :-) In a few weeks time it just becomes official, and any existing ones will be removed. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] EDIT-Button on osm-website
2009/3/29 Martin Koppenhoefer dieterdre...@gmail.com: I wonder if it was possible to link the EDIT button on the main website to a page (or AJAX) with checkbox-choice for the editor: Potlatch, JOSM (and any other Editor offering a remote-call-function). This would underline the possibility of alternative editors to newbies as well as offering comodity to JOSM-users. It would also point out, that Potlatch is not more recommended than JOSM. And it would maybe prevent some problems connected to Potlatch-Edits (inconsistent and erratous data like multiple nodes and deleted ways that still appear in Potlatch (in general errors as result of not using API), insufficient zoom). Patches welcome. As far as I'm concerned there's no problem with that as long as the page doesn't try to confuse the user. ie: make sure it has default to potlatch (works in the browser), and big friendly I don't care, give me an editor buttons. Oh, and a please don't ask me about this ever again button. And can you point me to the trac bug reports for these potlatch problems you mention? I'm not currently aware of any problems introduced by the AMF API specifically, just a couple of errors due to the general lack of transactions. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
2009/3/25 Stefan de Konink ste...@konink.de: Dave Stubbs wrote: Who needs SQL? http://api.openstreetmap.org/api/0.5/node/292984561/ways So yes. It is. Thanks very interesting; I didn't realise this could do the trick. The API's Way.to_xml_node method strips out invisible nodes that it reads. http://api.openstreetmap.org/api/0.5/way/4043588 -- no node The OldWay.to_xml_node history calls do not. http://api.openstreetmap.org/api/0.5/way/4043588/history -- node (despite way timestamp saved after node was deleted) So I collected all the 'problematic' things. I think by what you mention, it can be trivially fixed just by fetching all nodes and reinserting them again? Some of them are due to different bugs, but in general yes. The relations that reference node 0, 1 and other numbers below about 20 are a complete mistake (bug fixed ages and ages ago now) -- those nodes should be removed from the relations. Potlatch also doesn't try to filter deleted nodes, so it'll appear in Potlatch too (and be successfully resurected if you save the way). This could be an award winning observation :) Can we test this is in a way? a) read the code. The getway and putway bits of amf_controller are fairly understandable. b) give it a go: http://www.openstreetmap.org/edit?lat=45.0965lon=-64.3565zoom=13way=4043588 Make a minor change then deselect the way to save. Checkout the node history. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
2009/3/25 Stefan de Konink ste...@konink.de: Richard Fairhurst wrote: Stefan de Konink wrote: The amount of 'potlatch' in the attached document As has been explained to you, you mean the amount of API ;) Yeah yeah... I knew this would trigger you to a response; My next mail includes the b0rk3d ways and relations. I can already tell you ~2. and the purpose of filling our mail boxes with these lists is what exactly? It's a known problem with a fix on the way with 0.6. Repairing the damage is helpful. Moaning about it with added unhelpful and ignorant opinions isn't. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
2009/3/25 Stefan de Konink ste...@konink.de: Matt Amos wrote: yeah, the wiki page could probably do with some updating. but you remember this thread last month, right? http://lists.openstreetmap.org/pipermail/dev/2009-February/014024.html the issue with things referencing deleted items should go away because the transactions wrap the used-by checks. True; But isn't Rails doing that now too? [I am talking about the main database] Never the less, I asked Dave if he checked in the MySQL database if the presented violators are in there or if this is a hypercube issue. I would like to have a reply to that, because then it might be an issue that should be addressed by more people. looks like it might be a planet generation issue. maybe take a look at the history for some of the items which are causing you problems? That is exactly the reason I want to know if it is currently in the main database or not. http://api.openstreetmap.org/api/0.5/way/4043588/history http://api.openstreetmap.org/api/0.5/node/292984561/history The issue is that the hypercube 'dump' contains the waynds on 4043588, 292984561. Grant, Tom, could any of you if specifically this relation still exist in the main database? Who needs SQL? http://api.openstreetmap.org/api/0.5/node/292984561/ways So yes. It is. The API's Way.to_xml_node method strips out invisible nodes that it reads. http://api.openstreetmap.org/api/0.5/way/4043588 -- no node The OldWay.to_xml_node history calls do not. http://api.openstreetmap.org/api/0.5/way/4043588/history -- node (despite way timestamp saved after node was deleted) The hypercube dumps probably work off the osmosis diffs which read the history tables, hence the node in there. The main planet dump reads the current tables but doesn't filter the invisible ones like the API does. Potlatch also doesn't try to filter deleted nodes, so it'll appear in Potlatch too (and be successfully resurected if you save the way). So in those cases you will find a reference to a deleted node that the main API doesn't appear to have. Obviously the current ways shouldn't contain invisible nodes... but they do... and that'll be most likely due to lack of transactions etc etc Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Improvement of tile rendering
2009/3/20 Ceriel Jacobs cerieljac...@gmail.com: On Tue, 17 Mar 2009 18:35:18 +0100 Stefan de Konink wrote: I have set this up completely inside a webserver. Cherokee, no php, just the python script that renders the thing on demand. Runs in production for months now. snip vserver!10!domain!1 = tile.openstreetmap.nl This looks really well, as tiles are shown after rendering to the requesting user. No ...more OSM coming soon messages are sent to the user. ...more OSM coming soon implies you're talking about the tile.openstreetmap.org tiles? In which case that server is running mod_tile. It's deliberately configured to only wait for the renderer for 3-4 seconds otherwise it gives you an old tile. You only get the 404 and hence ...more OSM coming soon tile if there isn't an old tile available (ie: it's never been rendered before or it's been cleared out of the server's cache). You're therefore more likely to get them under heavy load at high zoom where the old tiles are unlikely to exist and the render-on-demand can't keep up. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Improvement of tile rendering
2009/3/17 Udo Giacomozzi udo@nova-sys.net: I just set up my own Mapnik server that renders map tiles on demand and saves them on disk so that they are efficiently cached. Currently this is done using a PHP script (FastCGI handler with 5 instances) that handles 404 errors and invokes a python script to render the tile which then gets stored at the location that caused the 404 error. Invoking python from PHP is suboptimal, I know, but I'm no Python programmer, PHP lacks Mapnik support and so far this was only a proof of concept. Anyway.. I noticed that to generate a tile, a 512x512 pixel map is generated, which gets then cropped to 256x256 pixels and reduced to 255 colors by using 'convert'. I don't know if the mod_tile daemon does it the same way, but I guess it does. It doesn't. It renders meta tiles -- that's 8x8 normal tiles. This reduces the border overlap overhead. I guess the cropping is done to fix some text labelling issues (to keep text readable across tiles), but in practice this does not work well since I see lots of text cropped in Slippy Map. Also, invoking the convert tool without doubt takes massive resources compared to in-place color reduction. Have any efforts been taken to use libmagick directly or avoid external tools at least? And it uses mapnik's png256 output which does the colour reduction itself. The cycle map doesn't use any colour reduction. And, is it really impossible to avoid cropping at all? Can't Mapnik be instructed (or extended) to render labels always at the same place, no matter the viewport? The problem is label collisions. Labels cause other labels to move or not be displayed. When you add/remove data you change the flow. Tile overlaps help quite a lot but there are issues still. It could easily render everything in the same place, but that wouldn't lead to a very nice map. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osmarender patch - Better support for non-english/multi-lang areas
2009/3/12 Eddy Petrișor eddy.petri...@gmail.com: Tal a scris: On Wed, Mar 11, 2009 at 7:37 PM, Andy Allan gravityst...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:33 PM, Tal tal@gmail.com wrote: 2. Support making one tag be exactly the same as another tag using the following construct: name:he=hebrew text name=$(name:he) This is not full variable expansion, just the ability for tag A to say: i have exactly the same value as tag B. No, no, no. A thousand times no. Please reconsider this, and maybe invent a new tag Name should be a string only a string and nothing but a string, not name = (string|processing directive). We've had this discussion before regarding name=__noname__ and the conclusion was to NOT DO THINGS LIKE THIS. Cheers, Andy As I said before, I'm not keen on the $(xx) construct. I immediately said I was ok with the new-tag solution, but it seemed to me that more people in multi lingual areas (including myself) find the $(xxx) version nicer, so that what I did. I'll be perfectly content with a new tag, no name tag, and patched renderers. And if that solution can be agreed upon I have no problem to modify the patch. Unfortunately I did not follow the __noname__ discussion, so I will not question your conclusion. But I suspect that here the situation is a little different, since the name tags in a multi language parts of the maps are already broken, and should probably go away. Why don't you run a robot on the Israel planet that automatically adds/updates the name tag so it matches the name:he tag? Because: a) he doesn't know what language name is actually in b) because bots are evil Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osmarender patch - Better support for non-english/multi-lang areas
2009/3/11 Tal tal@gmail.com: 2. Support making one tag be exactly the same as another tag using the following construct: name:he=hebrew text name=$(name:he) This is not full variable expansion, just the ability for tag A to say: i have exactly the same value as tag B. Don't encourage people to try to insert random crap in free form tags such as name. Most people dealing with this will just print it and it'll look stupid. Find some other way of doing this. Several perfectly good ones were suggested on the recent thread. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osmarender patch - Better support for non-english/multi-lang areas
2009/3/11 Tal tal@gmail.com: On Wed, Mar 11, 2009 at 4:43 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: This will result in the very commonly used name=* tag becoming useless for anyone that doesn't support this ad-hoc macro language once this starts being entered into the database. It will only be useless for parts of the world that care about multiple languages. I tag in two languages, and the only reason I bother to use the name tag, is that I depend upon the slippy map on the osm site that uses that tag. If/when we had a local site, i'm pretty sure we'd not be using the name tag, and your tools would still need to be changed to properly use names in that area. Besides, even now it is somewhat useless, because you don't know what language you're getting. I tag name and name:he with the same value. Previously, and even today, people tag name as name:en, or transcription of name:he with Latin letters, or even - both Hebrew and English in the same name tag. A simple preprocessor before the tools could always change the data to the way they need it. But the regular mappers are better off working with that data model, and seeing it rendered in order to continue mapping and fix errors. So fix the editors instead. There's one option been pointed out already: use a separate tag to tell you what language the default name tag is. The editor can happily write the name to both name and name:* tags, write a language to some other tag, and provide validation that everything is working as expected. The fact that macros/redirects will confuse large numbers of people, and introduce a stage of complication and parsing into a previously raw tag which none of the existing tools will be expecting seem like good reasons not to continue. Oh and I'll update my threat from the no-names thread of ages ago: if you start doing this I'll make it my life's work to get on the local council to name as many features as possible as $(name:fr) with an explicitly stated french translation as $(name:en). Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osmarender patch - Better support for non-english/multi-lang areas
2009/3/11 Tal tal@gmail.com: On Wed, Mar 11, 2009 at 4:53 PM, Dave Stubbs osm.l...@randomjunk.co.uk wrote: Don't encourage people to try to insert random crap in free form tags such as name. It is no more crap than your answer ;) It is an attempt to offer a better solution to a serious problem in some parts of the map. I agree that this might be considered as a temporary solution since, as I see it, at the end there will be no name tag. It is simply not flexible enough for a multi language project. For that, a lot of tools will have to change, or a common preprocessor agreed upon. Until then, this is the lesser evil. Most people dealing with this will just print it and it'll look stupid. You may be right. That is a disadvantage. But as we don't tag for the renderer, we definitely do not tag for Most people dealing with this. Yes. Yes we do. What we don't do is mis-tag for the renderer. We don't tag construction sites as landuse=allotments because we like the colour mapnik uses to render allotments. We do however tag things with highway=motorway and not highway=omgponies because that's what the renderer is expecting and only osmarender will correctly handle omgponies as a motorway of arbitraryness. I know it might look like this a classic tagging for the renderer (I already said that my problem is only with the slippy map on the osm site), but this is not the case. It is purely to have better data quality. The best - and in fact the only reasonable - way to store Hebrew names in a multi lingual map of Israel is using the name:he tag. Currently we depend upon the slippy map. We tag, we see it rendered, we fix problems, add missing street names, fight about naming conventions etc. The map is steadily improving (with the natural focus upon hebrew names, but not only). The problems is that we are basing our all our work on the name tags, which DO contain random crap. Sometimes they also contain English, sometime Hebrew and transliteration, sometimes just English, and most of the time Hebrew. A computer script can't automatically go back from the name tags to the name:he tags. So as a result, we have lesser quality data - We have no idea what the name:he tags contain, because we do not see them, and the improvement to the name tags can't automatically go back to the name:he tags. This is the disturbing situation which I want to make a little better. Find some other way of doing this. Several perfectly good ones were suggested on the recent thread. I've mainly seen my proposal, copy-paste in the editor and name:local=XX. Maybe I've missed something? Are you referring to the name:local=XX ? This is OK by me, but less intuitive to the mapper, since one needs to remember a new tag. And, old tools will have NO name tags with this solution, so it'll be just a little better then using name tags with garbage. Think driving instructions with no name tags... and you think name=$(name:he) is intuitive to a non-programmer? For an intuitive end-user-experience you need to fix the editor itself. And when you start playing with the editor you can make the copy-paste automatic. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis: Filter way/node *without* key x
2009/2/13 marcus.wolsc...@googlemail.com: On Thu, 12 Feb 2009 21:34:21 +0100, Rolf Bode-Meyer rob...@gmail.com wrote: That indeed looks promissing. Unfortunatelly one seems to have be a programmer to use osmosis. Every problem is presented as a Java exception. Some of them contain at least a faint idea of what could be wrong. But something like this leaves me clueless: java.lang.AbstractMethodError at com.bretth.osmosis.core.pipeline.common.TaskManagerFactory.createTaskManager(TaskManagerFactory.java:72) This looks like the plugin was compiled against a different version of osmosis. My guess would be, that it was build against the latest development-version and you are using the last stable release of osmosis. Something like this. It's something Randomjunk the developer of the plugin has to fix. I have not seen any contact-info on his wiki-user-page so I hope he reads this mailing-list. It was built against v0.29 of Osmosis which is the version I'm still using -- it should work with that. I hadn't realised the plugin interface had changed. I'll have to take a look some time. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis: Filter way/node *without* key x
2009/2/7 Rolf Bode-Meyer rob...@gmail.com: Hi, is there a way (maybe not documented) to filter out ways/nodes without a specific key? You can try the TagTransform plugin: http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform A translation along the lines of this should drop entities not matching the regex: translation nameDrop/name descriptionDrop without mykey/description match notag k=mykey v=.*/ /match !-- no output description means matching entities are dropped -- /translation ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] One value per key? Why not one pair per object?
2009/2/3 Matthias Julius li...@julius-net.net: Stefan de Konink ste...@konink.de writes: Frederik Ramm wrote: Stefan de Konink wrote: What is the motivation to go to the one value per key thing again. Opposed to unique(objectid - key - value)? As a client programmer, I say that unique keys make everything simpler for me. It is much easier to check whether the highway tag has a value of X that it is to check whether one of the highway tags has a value of X. I'm basically shifting some of my burden onto the mappers (please make up your mind what kind of highway you're tagging). I agree completely and then you might even be thinking about k='bla' v='y' k='bla' v='z' stuff, I agree it will be a major pain, then again, if you keep it simple, it would always be a check if something has k=x,v=y render with z. If two people each implement a renderer that draws cycleways in blue and footways in red, then it is very likely that an object tagged highway=cycleway and highway=footway will show up blue on one map and red on the other. It is even possible that the same renderer will sometimes draw it red and sometimes blue... Hey, you just said yesterday that the API doesn't care whether the tagging makes sense. Why should it care in this case? One can always tag something highway=cycleway;footway. This is equally dumb. The difference is that it probably won't show up on any map. It shouldn't. But that doesn't mean the API should support every not-the-easiest-way-of-programming-it feature now does it? :-) And I should probably point out at some point that it isn't a good idea to try and use the same key more than once in API 0.5. There's at least a couple of things that have been refactored at some point and now probably won't work with duplicate keys. Saving ways to the history being one of them, and using the API to set them being another. Both probably still work on nodes. Basically API 0.5 doesn't really support duplicate keys after all, although nobody seems to have noticed, so meh. At least 0.6 will make it official. :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Handling of towns with different or alternative names
2009/1/28 Tom Hughes t...@compton.nu: Simon Ward wrote: On Wed, Jan 28, 2009 at 12:30:01AM +, Tom Hughes wrote: In practice keys are unique because although the API has never enforced uniqueness pretty much every client does because all the clients use a hash table of some sort to store tags. Hash table, or associative array/hash/dictionary? Hash tables have mechanisms to deal with collisions. I suppose I should just look at the code… Yes, OK, I was being a little imprecise. I was referring to the kind of associative array/hash/dictionary that is exposed to the user in many languages and which commonly does not allow duplicates. And in Java is called Hashtable :-) (although everybody uses HashMap these days) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Handling of towns with different or alternative names
2009/1/28 Richard Fairhurst rich...@systemed.net: Stefan de Konink wrote: If you can agree that this tag/nds out of order thing could be the main reason for these strange inserts, I am happy to help you search for the source that reflects this. I have an open mind as to what it might be. For some reason I think that the actual API call to update a way (hence: new timestamp/user) *is* done first from a code perspective, but is not finished when the request is done for current tables vs history tables. If you say 'but i create an xml and PUT it too' /way/id like anything else, then that is very interesting situation and you maybe right we are looking for the wrong editor. For its transport format, Potlatch uses AMF rather than XML. Speed is vital in an online editor, like Potlatch (or, indeed, the original applet). When using Flash, AMF both saves bandwidth and serialisation/deserialisation time. http://www.jamesward.com/blog/2007/04/30/ajax-and-flex-data-loading-benchmarks/ will give you some benchmarks. (Plus, of course, it doesn't suffer from the memory leaks that we seem to have with Ruby's XML handling.) amf_controller.rb then takes these AMF messages, and calls exactly the same Rails methods as the XML API does. I would strongly recommend you look at the code that saves ways: http://trac.openstreetmap.org/browser/sites/rails_port/app/controllers/amf_controller.rb#L330 FWIW, my experience is that data inconsistencies of this sort happen mostly when the server is under very heavy load. If a process is killed halfway through a write operation, then obviously you're going to get some sort of inconsistency. You can order the operations so that this is less likely (cf http://trac.openstreetmap.org/changeset/13184/), but as has been said here extensively, this kind of stuff is always going to happen without transactions. I've just done some research on this. Basically, the short version is that OldWay.save_with_dependencies! which does the save of the history has some hacks to get round rails being a bit shit if you don't have a unique column as your index. This means that you can't save two or more versions of a way with the same timestamp (which only has 1 second resolution); if you do then it results in duplicate tags on the first version, and an empty entry for the second version. The second update will throw an error as the way_node primary key constraint on is violated (i've tested with Potlatch on a dev env and the error icon does popup), but by that point the tags are already written. This all matches the history output -- however the current way output shouldn't be affected afaict. Stefan: before you correct these, is the data as returned by http://www.openstreetmap.org/api/0.5/way/ correct? I know the /history is broken, and therefore the osmosis generated diffs will be broken too. You can achieve the same results with the standard API (I have tested and shown this to be true). I think it's just that it's very very rare as other editors don't have the same approach/frequency to saving ways. At least, that's my interpretation, and explains why these things are more likely to happen during heavy load as update requests can get queued behind map calls, and then all get processed in the same second with the same timestamp. And it also gets Potlatch/amf_controller off the hook, at least directly. To mitigate: save up writes in potlatch... try not to send any updates with others already pending (that should happen already anyway) To fix: OldWay needs an alternative hack -- I can't think of one right now that doesn't involve adding another column which would use quite a lot of space for very little reaason. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 bulk uploader
2009/1/22 Frederik Ramm frede...@remote.org: Hi, Shaun McDonald wrote: It would be best if the bulk_import.py script was updated for 0.6. As everything needs to be wrapped into a changeset, it makes the bulk upload more complex than before. Yes and no... if you're talking uploads that are small enough to fit into one diff upload (i.e. not something like a TIGER county ;-) then bulk uploading should become trivial because you don't even have to keep track of the object IDs, you just throw your diff at the server and that's it. Such a bulk upload could basically be handled by a shell script that has three lwp-request calls. Hm, I see that each object in the diff must explicitly reference the changeset ID... so that would probably add one sed call to the shell script ;-) BTW: It seems that we're not currently imposing an upper limit for the number of changes in a diff upload, is that true? If so, we should perhaps add such a limit because the transacionality of diff uploads would otherwise make it too easy for the thoughtless script writer to mess up or data base... only thing I'm unsure about is whether we should simply abort after n cycles in the DiffReader.commit method (easy to implement, but by the time we abort the database has already been unnecessarily loaded), or whether there is perhaps a way to make this depend on the size (in bytes) of the upload and it could easily be checked before even starting to process it? Don't forget changeset size limitations. As I remember it we decided on something like a 50,000 edit limit to keep changesets from becoming land mines taking out poor innocent passers by as they suddenly find themselves trying to view a 1GB city upload. Last I saw that limit was being enforced by the API, so any diff upload that's bigger than 50,000 changes will fail automatically -- just not till rails runs the validation, probably after the whole diff has been processed. So the bulk uploader needs to split the data into useful changesets, not just multiple uploads. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Distributed Data Store
2009/1/22 Scott Shawcroft scott.shawcr...@gmail.com: Stefan, My thoughts are below. Stefan de Konink wrote: Hey, Scott Shawcroft wrote: My friend Jason (cced) and I are seniors at the University of Washington in Computer Science and Engineering. On your FAQ you say people interested in distributing the database across multiple computers should email the list. Well, here we are. We are currently in a distributed systems capstone course during which we need to spend the quarter (until mid March) on a single substantial project. Sounds fun :) There are a lot of 'ideas' here around, geographical balancing etc. The standard divide and conquer methods in databases, etc. The main problems in OSM: - Admins don't want to maintain multiple systems - The fear of anything new not developed by the devs (especially if it is not build in Ruby) Who are the admins for the systems? We're open to particular solutions and if there is a bias towards Ruby we'd look closer at it. However, it may be that there is a better solution. Who are the designated devs? The Ruby thing is just that the current API is written in Ruby on Rails. Obviously any work you do is most useful if it's applicable to the systems and data we currently have. If there's reasonable evidence of a better way of doing something then there's generally no problem in implementing it. A great example is the GPX importer daemon which was rewritten in C to make it a lot faster. The important points are ensuring any new stuff is actually better, that the admins can reasonably maintain it, and that there's a sensible strategy to get the data from where it currently is to where it needs to be. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql planet import time issues?
2009/1/20 Ivo Brodien philo...@cs.tu-berlin.de: Hello list, I am trying to import the planet file into PostgreSQL/PostGIS. I was already in contact with Jon Burgess, the author of the tool because I had a Segmentation fault after some hours of processing. He suggested to try the --slim option., although it makes the process very slow. I tried it (without changing the default 800MB cache setting). Yes, you can't now run it on a 32 bit system in non-slim mode without getting a segfault as you run out of address space. In general give it as much cache as you can. I do it with -C 2000 and it works (slowly, about 8-9 hours for the whole planet). But I have 8GB of RAM to play with. With only 2GB you're going to have to go to swap to complete the process anyway, so I'd just leave it on the default. You can check http://www.openstreetmap.org/stats/data_stats.html to see the current object counts. It's about 24m ways. If you don't need the whole planet then use an extract -- it goes a lot quicker. Otherwise invest in some more RAM -- it helps! :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Limit on the number of tags on a node
2009/1/13 Neil Penman ianaf4...@yahoo.com: Hmm, trying my post again with a message created from scratch! I didn't realise I couldn't just reply all to another message, change the subject and delete the old text! Its a bad habit anyway so time I stopped it. I get a 400 error when I try and upload nodes with more than 50 tags and about 4,300 bytes. This is to a test database, not www.openstreetmap.org/api. Is anyone aware of any limitations? API 0.5 concatenates node tags as a single text column for storage. This means that there isn't actually a limit on the number, but if the total size goes above the size of a database text column then there may be a problem. I think that's 2^16 bytes on mysql, so it shouldn't be causing you a problem. I don't know of any limits on way tags other than a 255 char limit on each key and value. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Potlatch - really BAD bug
2009/1/13 Marc Schütz schue...@gmx.net: Diff uploads will not help online editor such as Potlatch. The addition of transactions and exposure of the version numbers will help more. Why not? It may well utilize it for changes to multiple objects that should be atomic, e.g. the example mentioned here. Because potlatch uses a different API (found in amf_controller). However, in 0.6 the upload way call can be contained within a database transaction and so make the edit atomic. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] UID and username in API0.6
I'd also like to make the code so that it doesn't even parse the visible/timestamp/uid/username, thus reducing the processing required when editing the data. Is there likely to be a problem caused by doing this? Is the xml parsing code used for anything other than the data editing in the api? It's only parsing the time value that's going to take any cpu power and I think you already removed that :-) I don't think it is used for anything, but a doc comment wouldn't go amiss to tell everyone what it isn't doing, in case they try to reuse it in the future. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] UID and username in API0.6
2009/1/5 marcus.wolsc...@googlemail.com: http://wiki.openstreetmap.org/index.php?title=OSM_Protocol_Version_0.6section=14#Reliably_identifying_users Do uid and username have to be present for uploads? I am currently specifying a file-format not primarily intended for editors and would like to know if I can loose this info and still allow for small changes to be uploaded. The API will ignore timestamp/uid/username if present, and use the current time and logged in user. The version number of the object is needed to verify you're editing the latest edit. So yes, you can safely drop the user (and timestamps), and as long as you keep the version number it can still be used to make edits. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
2008/12/30 Robert (Jamie) Munro rjmu...@arjam.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan de Konink wrote: Shaun McDonald wrote: From API 0.6 there is a limit of 2,000 nodes in a way. Btw; Do you impose this also on a relation? If not, then it is pretty useless to have an infrastructure that is capable of holding an infinite amount of nodes and one that is not ;) IMHO ways should be restricted to more like 256 nodes, and relations should be unrestricted. I don't see how relations and ways should be similar in this respect. I can imagine a system that downloaded only part of a relationship, and had abstract add/remove object X from relationship Y methods, but with ways it seems much more complicated because of ordering. Because it's the same problem. It's about ensuring that API objects remain a managable size, not just for upload, but download and editing too. The add/remove would be abandoning our REST API interface which isn't exactly a trivial change for anybody, plus 0.6 makes relations ordered anyway, so it'd be just as complicated as doing it for ways. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Some more corruption
2008/12/15 Stefan de Konink ste...@konink.de: http://api.openstreetmap.org/api/0.5/way/23950375 http://api.openstreetmap.org/api/0.5/way/24644162 Would this problem be that there are two write outs to the same tag table at the same time? Yes, judging from the history two updates have overlapped and become confused. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Any tile statistics (unique visitors)
2008/12/7 Frederik Ramm [EMAIL PROTECTED]: Hi, Ian Dees wrote: It would be pretty neat to see a map of the number of times a certain tile is served. While it certainly wouldn't be any measure of visitors, it would be a pretty nifty visualization of the busy areas of the planet. I believe Andy Allan showed such pretty pictures made from Cycle Map access statistics at this year's SOTM. Yes, I made a (ridiculously inefficient) slippy heat map based on cycle map apache logs for a given day/period. It was primarily done to find areas people were looking for tiles but we didn't have them (ie: the 404 responses), so we could add the areas to our render list. We don't need that now because we cover everywhere :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Help needed: postgis database transform()
2008/12/1 Joerg Ostertag (OSM Tettnang/Germany) [EMAIL PROTECTED]: Probably my problem boils down to : Which SRID can I use to get data into the coordinate system used inside the planet.osm? But here in Detail: I need a little help in reading from the mapnik posgis database. I plan to expand the osmtrackfilter.pl to compare against the local data already existing in my mapnik-postgis-database. So I tried to get all street-segments inside a bounding box. For this i tried to select from the database. But there I have the problem that the coordintesystems are different and I have no clue how to convert between them. I want to operate with coordinates compatible to the planet.osm File. Something like lat=48.8046469 lon=9.0401476 So i thought i'll start with echo select osm_id,asText(way) from planet_osm_point limit 5; | psql gis Result: osm_id | astext ---+--- 293106148 | POINT(-2876147.15643226 4560658.25114169) 293105894 | POINT(-2874584.97662211 4563768.28055896) 293107003 | POINT(-2871694.69962705 4559831.77530905) 292977203 | POINT(-2871581.82166339 4556767.11400322) 292976398 | POINT(-2870606.29556972 4556208.15857941) (5 rows) Well at least I get some data from the database. Then the next step is to get transformed Data in the coordinate system I desire ... I did remember WGS-84 was SRID 4326, but either I'm wrong or whatever. Doing the following echo select osm_id,asText(transform(way,4326)) from planet_osm_point limit 5; | psql gis Results is an: ERROR: AddToPROJ4SRSCache: Cannot find SRID (4326) in spatial_ref_sys Well I thought I'll have a look into this in spatial_ref_sys but echo select * from spatial_ref_sys; | psql gis Result: srid | auth_name | auth_srid | srtext | proj4text --+---+---++--- (0 rows) Then I found SRID 900913 inside osm2pgsql and tried: echo select osm_id,asText(transform(way,900913)) from planet_osm_point limit 5; | psql gis Result: osm_id | astext ---+--- 293106148 | POINT(-2876147.15643226 4560658.25114169) 293105894 | POINT(-2874584.97662211 4563768.28055896) 293107003 | POINT(-2871694.69962705 4559831.77530905) 292977203 | POINT(-2871581.82166339 4556767.11400322) 292976398 | POINT(-2870606.29556972 4556208.15857941) (5 rows) Well, this seems to be the same SRID which is used inside the Database. So my Question is: Which SRID can I use to get into the coordinate system I want? OK, step 1 is to populate your spatial_ref_sys table with the default projections. Postgis comes with this as an sql file you'll need to run in your database. On my system: psql gis /usr/share/postgresql-8.3-postgis/spatial_ref_sys.sql That includes the definition for srid 4326. Unfortunately it doesn't include the definition for 900913, so transform still won't work. So step 2 is to add that definition to spatial_ref_sys. You can find the insert statement for this here near the bottom: http://trac.openlayers.org/wiki/SphericalMercator Your original SQL should then work as you expect, ie: echo select osm_id,asText(transform(way,4326)) from planet_osm_point limit 5; | psql gis osm_id |astext ---+--- 249399325 | POINT(-179.99 -28.083340594) 262907788 | POINT(-179.9725899 -16.838963791) 249399407 | POINT(-179.9 -5.64195) 240485015 | POINT(-179.8808896 -16.688173391) 242554118 | POINT(-179.8808154 -16.687760691) (5 rows) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data corruption :) II
2008/11/26 Stefan de Konink [EMAIL PROTECTED]: On Wed, 26 Nov 2008, Tom Hughes wrote: Then let me even get a better proposal; A second machines will be installed that has enforced foreign keys. This second machine will produce the planet. And will directly trigger events upon corruption so the main API doesn't need to cope with them until 0.6. So you want us to do a huge amount of engineering work, including sourcing new hardware, just to make things easier for you. Bearing in mind that this will itself delay 0.6 because it will divert effort, and that it will also be hugely duplicative of the 0.6 work. Yup :) And for all other users of your core business. Delivering consistent Geo data. Are you completely mad? No, technically I am King because I am a customer of your data, that is broken. Any proposal to fix it in a reasonable time, hence less than 1 month is accepted. Many corporate boys always go to battle with the stupid argument you just made. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data corruption :) II
Otherwise you could make this check in postgres using the CHECK expression table/column constraint. And possibly some stored procedures. But we're then writing very close to the database layer. And not even our current database layer, as I don't know if mysql supports this. i don't think postgres supports a check constraint on a column in a different table linked by foreign key. at least, if it does they're keeping quiet about it... Yes, it doesn't support subqueries in the check expression direcly, however it does support function calls, which is where the stored procedures come in. So it's possible to do it, but whether it's either efficient or desirable is another matter :-). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data corruption :) II
2008/11/26 Matt Amos [EMAIL PROTECTED]: On Wed, Nov 26, 2008 at 7:54 AM, Stefan de Konink [EMAIL PROTECTED] wrote: Then let me even get a better proposal; A second machines will be installed that has enforced foreign keys. This second machine will produce the planet. And will directly trigger events upon corruption so the main API doesn't need to cope with them until 0.6. it is worth noting that foreign keys and transactions alone will drastically reduce the number of problems, but may not solve them entirely. the foreign key from current_way_nodes to current_ways and current_nodes only ensures that those nodes have existed. the current_* table stores (as the name suggests) the current state of entities. that state may be deleted. what would be ideal is a check like node_id references way_nodes.node_id check way_nodes.visible = 1, but i can't find any documentation for this in mysql or postgres. one solution is to delete deleted ways/nodes from current_, but this would complicate the code to determine whether the appropriate response from the API is 403 or 404. thoughts, suggestions? Well, as long as the API code is good, and makes this check, then the transaction should cover it for inserts/updates. I'd assume the migration script will have to handle existing inconsistencies. Otherwise you could make this check in postgres using the CHECK expression table/column constraint. And possibly some stored procedures. But we're then writing very close to the database layer. And not even our current database layer, as I don't know if mysql supports this. The rails way would presumably be to write a validates method, which would work within the transaction, and keep it clean at the application insert/update level. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.5 API: /api/0.5/user/preferences, values truncated to 256 chars
2008/11/25 Stefan de Konink [EMAIL PROTECTED]: [snip] Is this problem at all addressed in 0.6? I'm quite surprised by this thread because I always was under the impression k and v sizes were unbounded. The choice for 256 is also very strange, 255 would have made much more sense. A post far up there ^ said VARCHAR(255). Shaun already stated that it is addressed -- the API will explicitly reject rather than just truncate. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data corruption :) II
2008/11/23 Stefan de Konink [EMAIL PROTECTED]: It is always easy to find the root of all problems: ++ | v | ++ | Potlatch 0.10b | | Potlatch 0.10d | | Potlatch 0.10e | | Potlatch 0.10f | | Potlatch 0.8a | | Potlatch 0.8b | | Potlatch 0.8c | | Potlatch 0.9a | | Potlatch 0.9b | | Potlatch 0.9c | ++ 10 tuples There was a Potlatch bug early on (my fault), which has now been fixed, that'll be responsible for referencing the low numbered nodes. The root of the problem, however (as has been stated many times before), is lack of transactions and foreign key constraints in the 0.5 API. This is being fixed in the 0.6 API. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data corruption :) II
2008/11/24 Stefan de Konink [EMAIL PROTECTED]: Dave Stubbs wrote: There was a Potlatch bug early on (my fault), which has now been fixed, that'll be responsible for referencing the low numbered nodes. Resolvement scenario? Undelete or remove members? Just remove members -- there's no useful information to recover as the user never intended to link these nodes (the bug was that the node index in the way was linked instead of the node ID). You could probably try to reconstruct the intended node ID, but it'll always be a guess. The root of the problem, however (as has been stated many times before), is lack of transactions and foreign key constraints in the 0.5 API. This is being fixed in the 0.6 API. Foreign key constraints are part of the typical database; not an API matter. If implemented it still wouldn't require transactions only a proper order of querying. I'm talking about the API code inclusive of the database schema, rather than the exposed API itself. And yes, you need transactions because the problem is that somebody could be busy deleting a node at the same time as you're adding it to a relation. The transactions don't need to be very big for this small use case, but they need to exist. It's entirely possible your database quite sensibly always considers referential constraints transactionally with the update. Note that we also have the issue that relations should reference only visible ways/nodes/relations. This is a more complex integrity problem depending on your exact database schema, and how you handle deletions, which you may not be able to express completely in the database engine itself. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data corruption :) II
2008/11/24 Stefan de Konink [EMAIL PROTECTED]: Andy Allan wrote: On Mon, Nov 24, 2008 at 11:06 AM, Stefan de Konink [EMAIL PROTECTED] wrote: Foreign key constraints are part of the typical database; not an API matter. Yep, but here's where theory and real-life meet. The new API requires changes to the database schema (e.g. new tables for changesets, changing users columns to changesetids on many tables) and you only get a limited number of times you can take the database off-line to implement things before everyone starts getting pissed off. So API0.6 includes more than just changes to the XML API. Are you saying you are not more pissing people off with bad data than with fixing all constraint problems; and adding a foreign key constraints? Pissed off count: API read-only for a day = 1000 people Occasional referential integrity problems = 1 (you :-) Seriously, there aren't that many problems considering. It's clearly not ideal, hence why it's being fixed. But the fix isn't as trivial as you make it sound, so it's been agreed to fix a few other problems and introduce some extra useful features at the same time, thus minimising down-time for everybody. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 'holes' in buildings
2008/11/21 Thomas Wood [EMAIL PROTECTED]: 2008/11/21 Brian Quinion [EMAIL PROTECTED]: Hi, I'm running my own mapnik server and have noticed a strange problem with the rendering. I don't seem to be getting the holes in buildings (i.e. http://www.openstreetmap.org/?lat=52.212704lon=0.102523zoom=18layers=B000FTF ) instead I get 2 seperate polygons, both filled. This is using the standard OSM style sheet so I'm assuming I must be missing something to do with relations when doing the osm2pgsql conversion. At the moment I'm simply running: ./osm2pgsql -d osm uk-081119.osm.bz2 The OSM file from here: http://nick.dev.openstreetmap.org/downloads/planet/ although I've also tried the uk cloudmade file with the same results. Any suggestions? -- Brian You need to use osm2pgsql slim mode (-s), apparently relation parsing is broken in the in-memory mode, since it can't decide which ways are valuable enough to keep before parsing the relation. (Or something similar) Or just the wrong osm2pgsql version... the cycle map doesn't use slim mode, and yet has polygons with holes OK for the area given. But then the cycle map's osm2pgsql is frozen on svn r7719, and has other problems all of it's own. Latest version and slim mode would be the best bet I'm guessing. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problem with Postgresql / Mapnik / SRTM Contours
2008/11/24 sylvain letuffe [EMAIL PROTECTED]: Sylvain wins the prize for noticing! Is this sarcastic ? if yes, please excuse me, I'm using your tile serveur for a personal project No, it isn't. :-) Andy was wondering loudly to himself the other day how long it would take for people to notice the changes. You win a genuine prize as the first to comment publicly on noticing! Although due to budgetary constraints, there isn't actually a prize. ;-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Lean and mean Tile- and XML-API-Server
2008/11/21 Stefan de Konink [EMAIL PROTECTED]: Matt Amos wrote: C/C++ is not a prototype language. do you mean http://en.wikipedia.org/wiki/Prototype-based_programming ? No I mean a language where you start scripting and others have no clue what you are doing until it finished and it works. Other words; Proof-of-Concept. Low level languages are not good for this, too much distractions with memory management etc., but once you know exactly what you want. Don't waste your time on a language that does 90% for you sadly has no compiler to native machine code. Meh, proper languages are often over rated. Machines are cheap, developers are expensive, and code lives far longer than most people hope. Maintaining well written code is easier than maintaining crap code, and many of your prototype languages promote well written code. Especially when you talk about ruby on rails. The entire point is an easy to maintain code base, with MVC architecture, database schema versioning, and all the crud and boiler plate taken out of your way. Point a rails developer at a well written rails app and they can figure out what's what in very little time. C/C++ has it's place, and I'm not claiming it's not faster (or even better) for this application. But that doesn't make RoR a prototyping system. Or as a mirror for your last statement: don't waste your time on a language that compiles 90% quicker when it doesn't matter. Which leaves the important question: does it matter for OSM? (and is a full rewrite the best way of fixing it if it does) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Lean and mean Tile- and XML-API-Server
2008/11/21 Stefan de Konink [EMAIL PROTECTED]: Dave Stubbs wrote: Meh, proper languages are often over rated. Machines are cheap, developers are expensive, and code lives far longer than most people hope. Who is paying for new machines in OSM? And who is getting paid for writing code? 1) The OSMF through donations and membership, other random donations etc. 2) Nobody (not by OSM(F) at any rate), so that means we're limited by how much time people are willing to provide for free (either companies or individuals). And besides which it was a general statement in response to your general statement about languages. Any applicability to OSM in particular is a fairly complex question which is, unsurprisingly, going to result in compromises. Which leaves the important question: does it matter for OSM? (and is a full rewrite the best way of fixing it if it does) As long it is slow, and someone is stupid enough to try and fix it, it matters :) Sure, except that the code, once written, doesn't just sit there. People have to maintain this stuff. It's not just about, can it be written?, it's can it be written and maintained?. So I think a better reply (well, maybe just more complete) is that as long as it is slow, and someone is stupid enough to try and fix it, and they can convince the guys who are going to end up responsible for deploying and maintaining it, it matters. Sometimes speed becomes important and it makes sense to replace certain parts of the system, ie: the GPX importer which has already been down this path. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.6: new_way
On Sun, Nov 9, 2008 at 8:00 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: In the way model, what does new_way do? I'm slightly surprised to encounter def delete_with_history!(new_way, user) when I'd have expected def delete_with_history!(changeset) The controller receives a request to /way/id with post data being the way XML. The XML is interpreted to new_way, and contains the changeset ID and the way version number. The user passed in is the currently authorised user. delete_with_history then checks for consistency between the authorised user, the new_way's changeset, and the way version number before making any change. new_way is probably a bad var name... I'd have gone with something like xml_way, input_way, request_way etc. To replicate without XML you just need to use Way.new to create a Way object with id, changeset and version all set. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways with 40k nodes, was: osmosis pgsql schema
On Fri, Oct 31, 2008 at 10:44 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, Florian Lohoff wrote: Its 2^15 because it signed - and yes - somebody managed to get abovE: This definitely has to stop. We need to (a) find all ways with more than a few thousand nodes and break them down, and (b) educate users that they shouldn't do such evil things. Imagine the poor sod who opens a little rectangle in JOSM just to find he has to wait for ages to download 40k nodes! This slows down so many things. (And what's more, once someone creates a way with 50.001 nodes, no bounding box containing even one node of that way will be downloadable through the API.) I know that shortcomings in the renderers still make it attractive for mappers to create giant polygons but we cannot allow this to get out of hand. I'm all for an API hard limit of 1000 nodes in a way. That wouldn't impact any normal stuff, but would put a stop to megaways pretty quickly without the need for a re-education programme :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways with 40k nodes, was: osmosis pgsql schema
On Fri, Oct 31, 2008 at 11:02 AM, Stefan de Konink [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2008, Frederik Ramm wrote: Any comments? You are now basically working around the actual problem. Allowing partial ways in the editors for the current bbox. I think hacking and breaking ways is bad, duplicate information, missing tags upon edit etc. I think storing ways with their tags per 'new segment' is bad too; hence the reason I proposed to use an ordered relation to represent ways. With 40k nodes in a way it takes the API about 30 seconds just to generate and serve the XML for the way, /without/ the nodes. The .osm file with no node data goes upto about 100kb. (With node data that's 5-6MB) To make a modification to the way, ie: add a tag, you have to reupload that 100kb of XML, and sit back, probably make a cup of coffee to pass the time. I don't think having a single object of this size ends up helping anybody. With relations we can add indirection to handle extremely large objects, but with small API units. It just makes everything more flexible than dealing with megalithic monoliths. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Element IDs in API
On Wed, Oct 22, 2008 at 1:18 PM, Matthias Brandt [EMAIL PROTECTED] wrote: Hi, are the IDs in ways, nodes and relations globally unique? Or otherwise: Are there two identical IDs, one as way-id the other as node-id? Yes, there can be collisions. IDs are not globally unique. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] What country is something in?
On Fri, Oct 10, 2008 at 5:38 PM, Stefan de Konink [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Roland Olbricht schreef: is anybody working currently on the What country is something in? issue from the Things-to-do-page? I would like to work on it, but I want to avoid doing work twice. Isn't that a trivial thing using PostGIS? If you have good country borders organised into nice polygons then yes, it's not that hard. I've done tests using vmap0 borders and it works quite well (they're just not very high res). The OSM borders aren't always that great though, and they're not single ways, so it would need something like the coastline checker to pull the data out and join it up in a nice way. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Auto closing of changesets in API 0.6
On Fri, Oct 3, 2008 at 4:23 PM, 80n [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 3:54 PM, Frederik Ramm [EMAIL PROTECTED] wrote: (forgot to reply to list) Hi, Shaun McDonald wrote: Should changesets automatically be closed after a period of time? If so how long? Why does a changeset need to even have an open/closed state? Its just a unique identifier for a set of changes. It forces people to use separate changesets. Otherwise it would be possible to create a changeset and then assign all edits to it forever, which wouldn't be very useful. This way changesets have a vague bound on duration (ie: how long an editing session can be kept alive), which makes some of the fun stuff you may want to do with them (like providing reversion) slightly more sane as you know whether new edits can be added or not. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik projection slightly wrong?
On Tue, Sep 23, 2008 at 4:30 PM, Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
Hi!
I just looked at applications/rendering/mapnik/generate_{image,tiles}.py
and noticed the projection string:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
+y_0=0 +k=1.0 +units=m [EMAIL PROTECTED] +no_defs +over
`a' and `b' are ment to be the equatorial and polar radius of the
earth. Since we all use GPS, I guess we want to use the WGS84
ellipsoid, where the polar radius (b) would be 6356752.315m, instead
of 6378137.000m? Is this intentional? At least, osm2pgsql uses the
same, so all of the users are identical :)
The main osm online maps are all done in spherical mercator. As the
name suggests, a and b are the same. This is the same projection
google, yahoo and microsoft use for their web maps. You'll find the
projection often referenced as EPSG 900913, which is an impossible
number to remember until you realise you can read it...
You'll see osm2pgsql has some other projection options if you want to use them.
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] on planetdiff usage
On Tue, Sep 2, 2008 at 2:47 PM, Mitya Korochkin [EMAIL PROTECTED] wrote: Hi everyone, I'd like to build weekly planet.osm files for the September 2007 using planetpatch utility (http://svn.openstreetmap.org/applications/utils/planetdiff/). I'm running the following command: ./planetpatch planet-070905.osm.bz2 planet-070905-070912.diff.xml.bz2 planet-070912.osm But in some minutes I'm getting following errors: StartElement: Unknown element name: segment EndElement: Unknown element name: segment At the same time, planet-070912.osm file is still being created. Do you know if these error messages are essential? Yes, these planets are from before the 0.5 API switch over (which happened on 6th/7th October 2007). I think you'll need to process them with a 0.4 version of the planetdiff tool (ie: r4778 in SVN). Any tools you use will need to know about segments, or else you'll need to convert the planet first by using the 04to05.pl script at: http://trac.openstreetmap.org/browser/applications/utils/conv05/04to05.pl There may be an easier way, but I don't know it. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Autocorrectable data inconsistency
On Sat, Aug 16, 2008 at 10:21 PM, Joachim Zobel [EMAIL PROTECTED] wrote: Hi. I took a closer look at the data and found that several ways (1+) in europe) have identical nodes on subsequent sequence_ids. I suspect this largely happens when someone removes a few nodes from a loop and the editor doesn't notice the weirdness. There might have been a few historical bugs on creating ways too. Potlatch has a habit of resetting the created_by tag when it makes an edit, whereas JOSM doesn't, so I think the relative created_by counts are probably misleading. It would be good to check each of the editors to see if they make an effort to stop this from happening. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] coastline
On Wed, Aug 13, 2008 at 9:25 PM, Jon Burgess [EMAIL PROTECTED] wrote: On Wed, 2008-08-13 at 21:43 +0200, Martijn van Oosterhout wrote: On Wed, Aug 13, 2008 at 9:34 PM, Jon Burgess [EMAIL PROTECTED] wrote: I approached it the other way: I generate simplified versions of the really long ways (the multi-million point ones) and work out which tiles don't intersect with any of them. For the no intersection tiles (90% of them) it only looks at the simplified ways. Much much faster. Perhaps we can do both and have it finish in a minute or two. My changes need some cleaning up if we want the ram caching to be optional. Indeed. I store the simplified shapes in, wait for it, a temporary file :) If you have some code to cache shapes in memory then we can really kick ass... I've put my changes into a branched version of the file, you can see them at: http://trac.openstreetmap.org/changeset/9804 That would be cool. You probably do some kind of simplification also and then run the process on the simplied ways with large blocks, right? Yes, this is where I started. I ran the coastline.osm.gz through the simplify.pl script and then used that for the rest of the processing. Unfortunately the results were quite bad in some places. The general point simplification results in multiple ways ending at a single point and that confuses the line merging algorithm. Ouch. I was thinking of doing it internal to closeshp but I hadn't decided on how to simplify it. Since it's happening after the line merging it should work better than your approach. Initially I was also doing it to speed up the closeshp processing, I guess this isn't required any more. There is probably a middle ground. The initial simplification would probably work if the start/end points were always left unchanged. There should be much less of a problem if we only simplify the mid-points. Hmm, something like that might work easily also. The overlap is a nice and quick way though :) Even with a large overlap the squares are still visible at zoom 2. I'm not sure this is a big problem though. I was going to try running the code again with DIVISION=1. Last time I tried I got a segv after about 5 hours in SHPDestroyTree(). It looked like a buffer or array overflow. Perhaps something between 1 and 400 with a larger overlap would work. If it's any help the current cyclemap is running with OSM coastlines at all zooms -- we're using inverted coastlines (ie: painting sea, not land). What I did was set DIVISIONS=100 and the overlap to 10% of a tile... that works fine. Unfortunately I didn't run anything through any simplifiers... so it takes bloomin ages to render each tile at zooms 1-3... but still... first steps. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Tag Transforms
Hi, I've written a new plugin for Osmosis to help in preprocessing OSM data. The plugin allows you to define a tag transform and apply it to an osm file. This transform matches tags with regular expressions, and then lets you manipulate the tags by inserting new ones or altering the existing ones. I've put a full description on the wiki here: http://wiki.openstreetmap.org/index.php/Osmosis/TagTransform skip ahead to the Examples if you get bored. It's not really had much testing yet, although I've been building some transforms which I intend to use with the cycle map sometime in the next couple of weeks. I'm interested to know how useful people think this is? (I know I have a use for it at least!) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql
On Tue, Jul 29, 2008 at 11:00 AM, Walter Lorenzetti [EMAIL PROTECTED] wrote: Hi list, I'm a newby on osm and I'd like suggest a little modification for osm2pgsql python application if possible add a constran of type PRIMARY KEY for every osm_id columns in every tables that osm2pqsql builds in db? This request is for Qgis software that requires a primary int4 column for loads data There are actually duplicate osm_ids in this column at the moment. If you really want it, then there's nothing to stop you tacking the constraint on to the end of your import script -- you can figure out how to resolve the contraint violations. But the easiest fix for your problem would be to just add an extra column -- again, nothing to stop you doing this after osm2pgsql has run. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Potlatch causing DB inconsistency?
On Tue, Jul 22, 2008 at 10:18 AM, Stefan Baebler [EMAIL PROTECTED] wrote: Tnx for the confirmation. I guess 0.6 API aims to fix that with atomic uploads, but Potlatch will remain using its own API, right? Is it now (version 0.10) preventing this somehow? Well, it's API will get upgraded to use transactions and optimistic locking along with everything else. The 0.10 changes just regularise the code to use more rails and less SQL (or at least make that an option). so the events went something like: - user adjusts the way somehow [common operation] - potlatch decides to delete old way and create a new one for some reason [stupid (breaking history), but legal] - potlatch deletes old way and all the nodes it can (those that aren't used by other ways where other rivers join the riverbank) [stupid, but ok] - potlatch creates a new way, consisting of old (now mostly deleted) nodes [illegal] Not really sure this has anything to do with missing transactions, more likely some bad logic. Foreign keys in the db on current_ways - current_nodes could prevent that, but AFAIK they aren't used for performance reasons. It's almost certainly to do with transactions... or at least lack of any locking. There's very little you can do at the moment if requests don't get executed in the order which they are sent. And that can happen as there are multiple rails boxes/threads/processes dealing with requests. API 0.6 introduces optimistic locking which should cause these situations to generate errors rather than corrupt things. But why is potlatch today STILL showing the riverbank as it would be there, but in fact it isn't? For the same reason the history call to the API still shows it. The potlatch API works slightly differently to the normal API, and in this case it doesn't check for the visibility of the nodes before returning them. It assumes that if it's in a visible way then the node is visible, which unfortunately isn't now true. If you edit the way in potlatch it should actually resurrect the nodes and make everything consistent again -- I did this just now, and it now seems fine (hopefully :-)). Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Area support
2008/7/9 Stefan Keller [EMAIL PROTECTED]: 2008/7/9 Jochen Topf wrote: Having real areas would make the handling quite a bit more practical. Agreed. An area (or polygon) simply is a basic geometry type; it's a fact in practice and computational geometry. The actual XML encoding of ways never really was according to best practices and will not scale. This is because even for ways we have to read in all nodes until the end of the stream/file before any way can be created. Now, when we misuse (application oriented) relations to encode areas, processors are again forced to read in *all* relation instances before any area can be instantiated... Can't we do that better? (the crazyness would be complete when one would 'consequently' encode areas *and* ways as partially ordered relation instances which would point to nodes). The XML encoding of ways is according to the actual data model. I'm not sure which best practices you're referring to. It would make processing a lot less memory intensive with embedded nodes, so I assume that's what you mean. I would take this discussion as a chance to enhance the OSM/XML encoding: Ways should be encoded with nodes (coordinates) embedded, and areas (polygons) ought to be encoded with one way as outer boundary and zero or more inner ways (boundaries) - embedded. I would even differentiate areas which overlap and areas which don't (but this is more on the conceptional and application modelling level and makes no difference in the encoding). Look on the simplicity and usability of such an XML encoding below... How are you handling nodes shared by multiple ways? Embedding them N times, or outputting them first and referencing them? Same for ways referenced by areas (if that was the intention)? It should be relatively easy (but memory intensive) to write a converter from the current format. The planet dump code and the API would be complicated though.. you'd need to check each node wasn't part of a way before you could output it -- performance of these components is a big concern. There's also the diff format to think about and how this would mesh (ie: how you'd stream an update). Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] [OSM-talk] When mental models go wrong: OpenStreetMap
On Fri, Jul 4, 2008 at 3:05 PM, m*sh [EMAIL PROTECTED] wrote: Am Fr, 4.07.2008, 12:39, schrieb Erik Johansson: This has come up before, in different ways each time. I know started thinking that any editor would first let you choose the type, and then let you draw it, like in Google Map Maker. But since we had the segments untagged in the beginning I think the easiest path was to add tagging after you draw. Why should there be any order at all? I do not understand that. Except for the very basic fact that you usually have raw data from your GPSr that you are editing. So first there is the Waypoint or Way and then you edit its properties. And if you create an additional node manually you may chose what to edit first - the North/West-Values or the tags... Yeah, there's no really good reason why you need to edit in that order, other than it's easier to program, and probably more how most people think. Our dynamic ontology, and largely tag ambivalent editors are why it's that way round. That all changes if I have a SimCity like setup where I choose the road tool, then the rail tool, and then the water tool etc.. but that requires the editors to work with map features (presets) as the starting point rather than an afterthought. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] PUT /api/0.6/{node|way|relation}/{id|create}
On Mon, Jun 9, 2008 at 5:10 PM, Stefan de Konink [EMAIL PROTECTED] wrote: Tom Hughes schreef: In message [EMAIL PROTECTED] Stefan de Konink [EMAIL PROTECTED] wrote: Tom Hughes schreef: The proposed change makes: - The QUERY_STRING to be irrelevant It already is. No current API request uses QUERY_STRING. Then make the query string irrelevant. I repeat myself. The query string is already irrelevant. Steve: it doesn't, toms point (which I agree with) is that it shifts complexity to the server (and I further think this is a bad thing) So *remove it from the specs*! If you don't depend on it. It isn't in the specs? query_string != request URL ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] PUT /api/0.6/{node|way|relation}/{id|create}
On Mon, Jun 9, 2008 at 5:41 PM, Stefan de Konink [EMAIL PROTECTED] wrote: Tom Hughes schreef: In message [EMAIL PROTECTED] Stefan de Konink [EMAIL PROTECTED] wrote: - Assures the client always get the id back That is already assured by the current API definition. For 'updates' too? According to spec only an id is send after a create. Well you don't need it on an update as you already know the ID. Not if you create a changeset with updates and creates. Should the client maintain which object was a create and which one was an update? Now that sounds like making it difficult for the clients, instead of just returning all id's in the diff/changeset. Unsurprising the changeset spec addresses these issues. You mean this? When downloading data the client will receive a version number. This number must be stored and provided when updating (or deleting); if it does not match the server's current verision number at the time the update/delete is made, the operation will fail. I don't really see how changesets are going to address all changes at the same time + returning version numbers. Since it is not an atomic operation, how can one reliably getting these id's before a /close ? Now you're confusing a changeset with the diff upload call. The diff upload call /is/ atomic. You can have multiple diff upload calls per changeset. The changeset spec in the 0.6 API includes all of this information. Anyway it gets of the original point, which I would like to have solved first. I think it has been solved: just implement the API the way it is. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] PUT /api/0.6/{node|way|relation}/{id|create}
On Mon, Jun 9, 2008 at 6:47 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
Dave Stubbs schreef:
I think it has been solved: just implement the API the way it is.
That is the actual question. Why does the api require a {node|way|relation}
if the actual XML, first child, already gives this information?
Because it lets you easily route the request to the relevant piece of
server code without having to parse the (potentially large) payload
first.
ie: http://trac.openstreetmap.org/browser/sites/rails_port/config/routes.rb
which dispatches the API commands to the relevant rails controller and
action to handle the request.
It is of course possible to do it without that. YMMV on whether this
gains or loses much, but it changes the API quite a lot in the process
which is probably a bad thing without a clear cut gain.
Dave
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Question about ShieldSymbolizer in template file
On Wed, May 28, 2008 at 9:11 PM, Brian Peschel [EMAIL PROTECTED] wrote: I was looking at the template file osm-template.xml. In there I see a definition for a ShieldSymbolizer. Style name=roads-text Rule Filter[highway] = 'motorway' and [length] = 1/Filter MaxScaleDenominator50/MaxScaleDenominator MinScaleDenominator100/MinScaleDenominator ShieldSymbolizer name=ref face_name=DejaVu Sans Bold size=11 fill=#809bc0 placement=line file=%SYMBOLS_DIR%/motorway_shield1.png type=png width=17 height=17 min_distance=100/ /Rule What interests me is the 'placement' attribute. (I am not sure if this should be in the mapnik mailing list or this one, but since it is the OSM template file, I am posting here). Looking at the mapnik source code for the load_map() method, this isn't supported. mapnik never reads this field out of the xml file. Since the shield_symbolizer class inherits from the text_symbolizer class, I know it can be set, it just isn't being done. Is this an oversight on the mapnik side? Or does this attribute have no meaning for a shield symbolizer and (probably) should be removed from the template file? The mapnik renderer classes hard code the shield symbolizer to a point placement. It doesn't really make much sense otherwise. So yes, the placement attribute in the style file is redundant (and a little misleading given it's set to line), and can be removed. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] C++ implementation of the API
On Wed, May 28, 2008 at 10:07 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, The problem here is the remedial action taken by the user/editor: they're going to try to work out the conflicts by downloading the latest version of the region. If this comes off a replication server that's a couple of minutes behind, You could make it so that the intial map query is served from a replicated server, and any give me the latest version of object X because there was a comnflict downloads from the master DB. Yes, you could. Although I'd imagine that would last 5 minutes till someone decided that hey, this one gives more up-to-date data and so from then on set it as default. I'm sure all the main editors and [EMAIL PROTECTED] would behave nicely, so this might be enough to reduce load. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] C++ implementation of the API
On Sat, May 24, 2008 at 8:48 PM, Joachim Zobel [EMAIL PROTECTED] wrote: Am Donnerstag, den 22.05.2008, 00:06 +0100 schrieb Tom Hughes: Writing Apache modules in C is hard, and I don't think using mod_cpp will make it much easier. Doing Apache modules in Perl (mod_perl has API access including filters) is a lot easier. Ye gads no. We want to keep the memory footprint under some sort of control so mod_perl is a non-starter. Everybody seems obsessed with low memory footprint. Why? Memory is cheap, and we are not planning an embedded system. What is the number of concurrent requests we need to handle? http://munin.openstreetmap.org/openstreetmap/rails1.openstreetmap-memory.html http://munin.openstreetmap.org/openstreetmap/rails2.openstreetmap-memory.html with a hundred new users a day. So sure, memory is cheap, but not having to buy it is cheaper, especially as the system scales. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] C++ implementation of the API
2008/5/25 Ludwig [EMAIL PROTECTED]: Would it not be better to think about new services that could be offered by OSM rather than putting a lot of effort into fixing something that is not broken? Suggestions would be WMS, WFS, i18n, custom layer support, or some sort of support where the OSM DB can be integrated well with a GIS. Not all of this would have to run off the writable database... Thank you for your valuable input. I can see you've put a lot of time and effort into this. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Fri, May 16, 2008 at 10:13 AM, Dair Grant [EMAIL PROTECTED] wrote: Frederik Ramm wrote: First of you might want to do rollback from Z to Y only because you want to keep Y to X. Changesets are a grouping of edits that make things easier because one only has to work with the groups - e.g. not show all individual edits, but show the group as a whole, etc. That is really the core idea of a changeset; it deals with a collection of changes as one entity. If an editor wants to be able to revert/have a check in comment for/etc individual changes, they can just commit each change in its own changeset. Looking at how this model is used elsewhere (any source control system), that'd be like committing after each keystroke/newline. I doubt that would be useful - the thing changesets bring is the ability to record why some changes were done as a whole. For most rcs systems such changes actually are atomic though, and don't allow multiple edits per changeset. We really have to support that if we're to keep Potlatch and the possibility of live editing systems, and still maintain a sensible number of useful changesets. I.e., if you look back at some old data you want to see that user X's Saturday morning contribution was added road names based on NPE map. Being able to see user changed tag X to Y, user dragged node here, user changed tag Y back to X, user changed tag X to Z is not useful; it's just information for the sake of it. If an editor wants to monitor individual edits in order to provide coaching or feedback to users, that's best done by watching user actions as they happen and providing feedback based on that (recording that info in the DB for every action for every user is pointless, as who would ever really go back and process it?). We already do store this information if they're using Potlatch. If they're using an editor with a save concept then obviously not. Is it useful? Probably not most of the time. You want changesets as some universal access and documentation method for the history of everything, and I want them as closed, near-atomic changes. +1 to the latter; changesets let us group related changes together, and document what they were for - that's the point of having them. Which comes down to how these changesets are actually being implemented in the server. I was under the impression that it was just a changeset ID column added to the node/way/relation history tables that could then be used to query what changes happened for a particular changeset. In this model we already have the detailed information, and this whole argument is over the format of a changeset query where it would be quite possible to implement it both ways, and have both available at the same time. Of course if it's intended to collapse changesets as they are created, then that's a different matter. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 11:46 AM, Christopher Schmidt [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote: It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Is that a design goal? That behavior seems unexpected to me. It's a goal to let it happen, think Potlatch style live editing. It's also possible for another changeset to edit the object in between as well, so this probably shouldn't be as transparent as catapult might suggest. The changeset data download will have to take this into account. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Newby question
On Mon, May 12, 2008 at 3:22 PM, Shaun McDonald [EMAIL PROTECTED] wrote: On 12 May 2008, at 15:13, Alex Wilson wrote: Hi, I'm new to this mailing list but have been following the good work at OSM for a while and have been very heartened by the project's growth. I have a simple question: I'm interested in the relative runtime of the sub-components of the Osmarender-based tile generation process. Specifically the relative time for running the Osmarender code itself (the XSLT+Perl) versus rendering the resultant svg as a tile? I am presuming the former is a small proportion of the total runtime whilst the svg rendering dominates? If not, I was wondering if there's any interest in developing a version of the code in a compiled language for efficiency reasons? Take a look at mapnik. I think that it does what your looking for. The problems that I know of with Mapnik are that it can take a bit to setup, and you can't do incremental updates of the database that it works off (hence why there are only weekly updates to the map). Although if you're only interested in small sections of data retrievable with an api map call then there is no reason you couldn't download the data [EMAIL PROTECTED] style, and import to postgis/shape and render using mapnik. This would all happen very quickly -- probably faster than the [EMAIL PROTECTED] equivalent (I haven't tested, so I couldn't guarantee that). Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6
On Wed, May 7, 2008 at 10:10 AM, Raphael Studer [EMAIL PROTECTED] wrote: is there anything else that should be put in 0.6? Probably a good idea to talk about it now. There is something I have in mind since a long time. Whats about creating a tag_key, tag_value and tags table? tag_key could be something like: tag_key_id(int), tag_key(varchar) tag_value could be something like: tag_value_id(int), tag_value(varchar) tags could be: tag_id(int), tag_key(int-refto tag_key_id), tag_value (int-ref to tag_value_id), version etc... The way_tags table could be changed to: way_id, tag_id In the nodes table the tags field could be removed and a node_tags table would be added: node_id, tag_id What would be the advantages of this change, I have 3 in mind. 1. Database Size would be decrased, because tags are nod saved by each way and node itself. 2. Typos could be minimized, because you could do an autocompletion (as Potlatch have it at the moment) based on the these tables. You also could show tags other ways/nodes used in combination with the tag entered at the moment (like the amazon customers buyed this, also bought ). 3. A MediaWiki Plugin for the Map_Features could be created, with ALL used tags. Therefor some more enhancemets on the tables would be needed to store the description/images/etc for the tags. The Disatvantages: Someone needs to do this. Please feel free to comment the idea. You also have to realise just how many tags there are. On nodes and ways there are close to 1 billion tags, comprising of about 50 million distinct key-value pairs (this was the last time I counted which was a while back). So while you'd save on space, the table join to get the tags back wouldn't be that cheap. As far as typos go, well, the typos are in there too so they'd turn up in your autocomplete if you used it verbatim. You also have to separate out tags used on nodes, tags used on ways, and tags used on relations. As far as your map features extension goes, this wouldn't need to be real-time so it could be done on a different machine by processing the planet dump. I think there would be a lot of value in a site which could achieve something along the lines of an extended TagWatch, but you probably don't need an API change to do it. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] The future of Potlatch
2008/5/2 Yann [EMAIL PROTECTED]: Well, a couple of questions. - Is cloudmade the same company with which SteveC tried to put advertising on openstreetmap a year ago, putting it online without asking anybody before, arguing it was because of money issue which proved wrong after a couple of weeks? - Is this flash applet going to be opensource, and made available for development to the community, or closed source, giving that company control over openstreetmap and the way data gets entered? I've been happy using potlach so far - not sure why a new version is needed: any thread pointing this out anywhere? You get the idea. Imho stevec is trying to turn osm into his commercial game *again*, and to be honest it's quite tiring. Oh right, but openstreetmap ain t communists like wikipedia. Nice over-reaction there Yann. I think Richard pointed out why a new version of Potlatch is wanted: Potlatch is written in ActionScript 1, [...]. The latest version is ActionScript 3, [...]. CloudMade believes this is holding back the development of OSM [...]: more Flash designers would come to work on it, resulting in a better editor. Whether you believe that's true is another matter, personally I'd tend to agree to some extent, and if I was investing money in a codebase I'd want it to be as maintainable as possible, which probably means something other than AS1. From what Richard said it implies to me that any new editor would be open source, but you'd have to ask CloudMade.. who as yet haven't actually made any statement at all on the whole issue... probably a sensible plan of action given your post. And as has already been pointed out, there's room for competition in the editor market, and CloudMade doesn't get any more say in what happens when you click Edit than anyone else. If we have multiple editors vying for that position then a solution needs to be found where the individual user can make that choice. I think it would be fair to say that SteveC is trying to make himself some money from OSM, but seeing as how either you or I could do the same thing if we wanted, I don't see your issue. You seem to be jumping the gun a little on the whole evilness line. Wait till they actually do something evil -- word has it they're looking for new offices in the hollowed out centre of an island volcano and the new editor will be called the Lighter ActionScript 3 Revisor, or LAS3R, so I'm sure you won't have to wait long. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] The future of Potlatch
On Thu, May 1, 2008 at 6:35 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: [warning - long ponderous e-mail follows!] Hi all, A fairly weighty issue concerning the future of Potlatch has arisen, and I'm completely baffled as to what to do - so I thought I'd ask the community for thoughts and advice. CloudMade (Steve and Nick's VC-funded company set up to commercialise OSM data, www.cloudmade.com) wants to commission a new online Flash editor for OSM. It would, I believe, probably be written by developers from Stamen Design (www.stamen.com): some of you will remember that Stamen's Tom Carden wrote OSM's early Java editing applet, and they've also written a slippy map in Flash called Modest Maps. As you can imagine, this has taken me aback a bit. As I understand it, their main issue is a technical one. Potlatch is written in ActionScript 1, which is the same language as JavaScript, but for Flash. The latest version is ActionScript 3, which is much more like Java for Flash. The end user doesn't notice a difference, but the programming style is very different. CloudMade believes this is holding back the development of OSM: that if the editor were written in the latest version of the language, more Flash designers would come to work on it, resulting in a better editor. Steve cites OSM's move from pure Ruby to Ruby on Rails as an example of how a contemporary language encourages more people to contribute. And they're also worried that if I were run over by a bus then no-one would be able to speak ActionScript 1 and maintain Potlatch. I'm not so sure. I think people are beginning to contribute code to Potlatch; that as essentially JavaScript it's approachable enough; and that the problems of attracting developers is symptomatic of core OSM in general (as per http://trac.openstreetmap.org/log/sites/rails_port). I hope that Potlatch, as something maintained by an active community participant _for_ the community, has demonstrated a pretty rapid rate of improvement anyway. It's meant to be small and compact, of course, not a a bells-and-whistles editor like JOSM: nonetheless, in the last few months, for example: it's become the only editor yet to offer revert/history, gained very good relations support, background layers, flexible GPX import, etc. And there's a lot of stuff on the way, mostly focusing on usability - from a generic 'undo' and pop-up help panel to a new, super-user-friendly tagging panel with draggable POI icons and things like that. It's got faults, everything has, but it's come a long way in the last year. For what it's worth I think it's the best thing I've ever coded. For most purposes AS3 probably is a better language - except for the fairly major proviso there's no open-source player even in development. Indeed, if I were starting all over again I'd probably do it in AS3, and in a couple of years I may well migrate Potlatch to AS3 (or 4, or whatever) anyway. But right now it's more important to spend time improving usability for mappers, given that - like most people here - I do have a full-time job which isn't OSM (which isn't computer-related at all, in fact) and consequently time is not unlimited. So I really don't know what to do. Part of me thinks that the most important thing is that Potlatch is still available and users are offered the choice. Part of me thinks, well, if there's going to be a new Flash editor, there's no point in me doing any development on Potlatch from today forward. Part of me wants to say well, screw you and walk away. And part of me wants to take CloudMade up on its OSM Grants scheme (http://blog.cloudmade.com/) and say, ok then, I'll announce a medium-term feature freeze, take a few weeks' holiday, learn AS3 and recode it for a large amount of $$$. I'm utterly stumped and would welcome suggestions. Thanks for reading. :) np :-) OK, first up potlatch's code: - ActionScript 1 in my professional opinion sucks donkey balls - how on earth you kept sane while writing Potlatch with that kind of lead weight I don't know, but Good Job! - there are occasions in the code where it could do with some redesign -- there's been lots of improvements along these lines made by yourself in the lead up to 8 and onwards. - having it's own API is a bit of a maintenance nightmare -- IMHO it should at least use rails models throughout to reduce the impact of this When it comes to attracting developers there is a problem here: the learning curve to start coding Potlatch is massive. You have to learn AS1, you have to learn how flash works in weird ways, you have to learn to avoid Ming bugs such as using return statements in the wrong place. And once you get into it, you end up going round in circles tearing your hair out because you missed one of those bugs or quirks. On top of all that you have to learn how Potlatch itself works (which is the easy bit). I can understand this will discourage many casual patches
Re: [OSM-dev] The future of Potlatch
-- AS1 / AS3 Dave - I think your definition of donkey balls might be different to mine. ;) Or rather, when you've been sucking horse balls for several years then donkey balls don't seem very different. Er, I should probably rephrase that. Yeah, I don't think the relative merits of various equine testicles is really where I want the conversation to go... To me (coming from a Perl script kiddie background, rather than Proper Programming In Java) You'll be glad to know I have opinions on Perl as well :-). I was once told that it's possible to write a program to generate haikus in perl, where the program itself is in fact a haiku. I was told this as if it was a good thing. To me it merely sounds evil. I found programming actionscript almost as painful as using C again. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Potlatch compiling setup
On Thu, Apr 17, 2008 at 9:20 AM, Martijn van Exel [EMAIL PROTECTED] wrote: Hi Richard (others), Could you tell me, what do you need to compile Potlatch from svn? I would like to contribute a help popup (inspired by the popup behind the '?' key in google reader). latest ming library, Ming 0.4.0.beta5 [1], with the perl bindings should do the trick. Oh, and a text editor that supports setting tabs as 4 spaces ;-) You'll also need an osm server rails install to run it against -- replace the potlatch.swf in the public/potlatch directory with the compiled swf you make. Then for ming action script fun remember the golden rules: - only one return per function unless you want some very confusing results - similarly don't ever use the break keyword - run for loops over local vars only so as not to have to remember the complex scoping rules which can stop them working In true SteveC style: Have fun! Dave [1] http://www.libming.org/moin.cgi/Releases ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] osm2pgsql fails on current data
On Mon, Apr 14, 2008 at 11:31 AM, Lauri Hahne [EMAIL PROTECTED] wrote: On 14/04/2008, Martijn van Oosterhout [EMAIL PROTECTED] wrote: You're right, I was thinking too far ahead. I won't complain if they enter 6;8 and they shouldn't complain when it's treated as if they had entered 6. I was thinking that we should point out that using semicolons is nice, but doesn't actually work in many cases. That wouldn't be too hard, since the meaning is clear. The problem mostly with tags with multiple values is that the meaning sometimes becomes ambiguous. But unfortunately there are cases when it's necessary to have multiple values. The most common of these is if two refs share a road. A road near me actually officially has two refs and two int_refs. Google renders them properly at http://maps.google.com/?ie=UTF8ll=61.428096,23.785744spn=0.084233,0.32135z=12 so we can't be any worse... The point is you can model these things quite well with relations. Obviously if you don't want to worry about that right now then continue to use semi-colons -- it's better than nothing. Currently the main renderers support neither method. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] osm2pgsql fails on current data
On Sat, Apr 12, 2008 at 6:01 PM, Martijn van Oosterhout [EMAIL PROTECTED] wrote: On Sat, Apr 12, 2008 at 3:46 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, there are some ways tagged admin_level=6;8 (way #23636282 e.g.) which seem to break osm2pgsql: Thinking about this more and more: that just isn't going to work, we need to discourage people from doing that. And I think i need to add some checking osm2pgsql to detect these kinds of errors sooner (i.e. before the database). If a way is for two adminn levels, then I suggest using two relations using the same way. Well, it's standard to separate multiple values with the semi-colon. It gets promoted a hundred times every time something where you have multi values comes up in tagging discussions. I don't think it's currently supported by anything, but that never stopped anyone :-) As for dealing with numbers I actually added some code to my copy of osm2pgsql to actually parse numbers so that the import isn't broken by a bad tag value. Feel free to apply to SVN if you want. It's geared for the capacity tag we're using when marking bicycle parking... somebody had put capacity=10-20... the code takes the average. Dave parseint.diff Description: Binary data ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Potlatch's add relation button
On Thu, Apr 10, 2008 at 8:24 AM, Lauri Hahne [EMAIL PROTECTED] wrote: Potlatch's add relation button looks exactly like http://www.sampo.fi/lehdistopalvelu/leipikset/images/logot/Sampo_Group_musta.jpg Maybe it should be changed. I agree completely. They can be contacted at: Sampo plc Fabianinkatu 27 00100 Helsinki Finland Tel: +358 10 516 0100 you probably want to talk to whoever's in charge of marketing and corporate branding. :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Potlatch backgrounds on Ubuntu
On Tue, Apr 1, 2008 at 6:51 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: I've had a report from a user saying that he can't access any Potlatch background imagery (Yahoo, OAM or whatever) on Ubuntu 7.10, Firefox 2.0.0.13, Flash 9.0.115.0. Anyone else have any experience with this? I use Ubuntu for Potlatch development, and I can tell you it works with Firefox 2.0.0.13 and Flash 9.0.48.0. That's apparently the last flash version available on the ubuntu updates server. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Tag Handling in the Database
On Thu, Mar 27, 2008 at 4:45 PM, Gervase Markham [EMAIL PROTECTED] wrote: Mikel Maron wrote: The discussion that followed Gervase's email last week was fascinating, especially the analysis of the OSM community as a anarcho-collective. Believe it or not, I was being ironic when I wrote that. Anyone who answers the question Would you be upset if someone burgled your house? with Yes doesn't actually believe in anarchy. And anyone who answers it with No should please send me their home address. Unfortunately there are at least two interpretations of what anarchy means. One basically means a complete mess, and the other is more of a social philosophy where there is no top-down power. When referring to a social system I would presume you meant the latter where anarchy does not imply burglary. You can of course argue all you like about whether the second kind of anarchy inevitably leads the first kind. Or whether property /is/ theft in the first place :-) Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
