Re: [Potlatch-dev] Status of potlatch2 development?
On Tue, Feb 19, 2013 at 6:39 AM, Richard Fairhurst rich...@systemed.net wrote: So, the question is: what purpose does P2 serve when iD is live and the default? I think there's two principal niches. One is working with third-party data, as per Snapshot Server and vector background layers. P2 does this very well and there's no support for it in iD. P2 looks like it'll be the go-to solution for projects like the DfT cycling data for a while yet. Secondly, there's simply the comfort of editing. I find P2 to be a very efficient and enjoyable editor to work with, which is perhaps not too surprising, but there are plenty of others who think so too. A comparable spot in the editor market to Merkaartor, if you like. But we do need to be aware that Flash Player is no longer a given, and I suspect that in a year's time, market penetration even on the desktop will be lucky to hit 80%. That second reason means that, for me at least, the priority is to get a version of P2 up and running on Adobe AIR. We can, of course, still have an online build too (especially for the third-party data use) and I see no reason why P2 can't continue as a selectable option on the osm.org Edit drop-down. Exasperatingly, AIR on Linux is limited to version 2.6, which I think equates to Flash Player 10.3. Thanks for the update on this interesting situation. I haven't played with iD until just now. The GUI looks excellent, and I love the modal editing (press 2 then click to create a POI - no fiddly double clicking). Looks like no tag templates (features) yet, but presumably underway. So, it looks like I'm not in either niche, and will presumably switch to iD soon. A few questions then about iD development: - are the internals at all similar to Potlatch? Is it feasible to port any features (ie, back-end node/way manipulations) over? I know ActionScript isn't exactly JavaScript, but... - is there a specified direction or policy on what kinds of advanced features will be allowed in? Is iD intended only as a beginners' editor? Can advanced features be included? - has there been any discussion about an openstreetmap.org version vs a MapBox version? Perhaps the former would have a different policy on the previous question... For the small remaining time that P2 is the default editor on osm.org, I'm happy to - indeed, would seek to - remain the maintainer of that instance. Any pull requests that can be instantly and confidently merged, I will (and do) merge promptly. Anything that requires a day's work for me to understand isn't going to happen; I can't afford to give a day away like that. Here's a couple I prepared earlier: 1) https://github.com/systemed/potlatch2/pull/66 It fixes a centroid calculation bug. You can very quickly verify that it works and doesn't catastrophically fail. 2) https://github.com/systemed/potlatch2/pull/58/files This will not unduly tax your cerebral resources. 3) https://github.com/systemed/potlatch2/pull/49 Stylistic considerations aside, this is an easy one. 4) https://github.com/systemed/potlatch2/pull/36 Aesthetic considerations aside, this is also easy. I will grant you that the following pull requests are non-trivial to understand, but are also pretty easy to verify. And considering that the *current situation* is producing bad data, the risks are probably justified. https://github.com/systemed/potlatch2/pull/67 https://github.com/systemed/potlatch2/pull/33 It's still sad to see those poor pull requests sitting there - if you had any idea how many hours those two bug fixes took. *sigh* That doesn't, however, stop anyone from running their own forked instances, and indeed that should be valuable in proving that a particular pull request will work or otherwise. So, Steve, I would encourage you to put your own build of P2 somewhere and people can then play with and test that as a prelude to getting them merged into the github.com/systemed repository later. Yeah, it's a good idea. I'm not sure of the logistics, but I'll have a go. If I provide a merged .swf, is there anywhere you or someone could host it? Personally I think maintaining a standalone desktop editor will be a whole bunch more fun. It frees up P2 to be P2, rather than everyone's first experience of contributing to OSM; it's more realistically forkable (anyone can offer a build for download); the UI doesn't have to be constrained by the browser window; performance should be better; it's less likely to attract the BAN crowd; and we can dump trac and use something sane. For my part, I'm 100% a web guy. I barely use any desktop apps at all these days and would live in a browser if I could. And the motivation of contribution to P2 has always been about working on the OpenStreetMap editor. Not some advanced tool used by a few hardcore types. But that's purely a personal, aesthetic view. [1] Apart from rendering all nodes, rather than just those in the currently selected way... that's a bit too GIS-like
Re: [Potlatch-dev] Status of potlatch2 development?
*crickets* No active devs left on this list? Did everyone move to iD? Steve On Tue, Jan 29, 2013 at 10:01 PM, Steve Bennett stevag...@gmail.com wrote: Hi all, Anyone know what the current status of development is? I have a number of pull requests on Github that have been sitting there for nearly a year. Richard Fairhurst hasn't responded to the last couple of emails I've sent him. I keep seeing bugs I'd like to fix, but if pull requests get ignored, there doesn't seem much point. Anyone know what's going on? Thanks, Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Status of potlatch2 development?
Hi all, Anyone know what the current status of development is? I have a number of pull requests on Github that have been sitting there for nearly a year. Richard Fairhurst hasn't responded to the last couple of emails I've sent him. I keep seeing bugs I'd like to fix, but if pull requests get ignored, there doesn't seem much point. Anyone know what's going on? Thanks, Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Outstanding pull requests (Attn Richard F)
On Tue, Jul 17, 2012 at 9:52 PM, Richard Fairhurst rich...@systemed.net wrote: Very happy with 1 if someone would like to set that up. Very happy with more people helping to review the code too. Could we start with a dev branch that all pull requests should be made to (and are accepted by default)? Or perhaps a reviewr repository to which push permission can be readily granted, for features that need reviewing? I unfortunately don't have a perfect solution - but perhaps someone else does. Also very happy if anyone wants to make the pull requests easier to review. So, for example, https://github.com/systemed/potlatch2/pull/66 completely reindents everything - I can't see what's changed and what hasn't. If someone were to resubmit this so that only the changed lines are shown, that would be great. This is what I'm talking about. I spent several hours tracking down that bug and finding a solution to it. If there was a dev branch that this was accepted on, anyone could easily verify that the centroid calculation is now fixed. Instead, it sits on a shelf for a month because some reformatting made visual inspection difficult. Before: https://github.com/stevage/potlatch2/blob/74fc99c26e8362f8adda25958248f046a2ad20ff/net/systemeD/halcyon/WayUI.as Note the broken formatting, lack of whitespace, and minimal comments. After: https://github.com/stevage/potlatch2/blob/9a8037a7ba692ddec4af5001eaadde62740ecefd/net/systemeD/halcyon/WayUI.as Also, given that you've preached at me several times on this list on the best and most friendly way to deal with people, I would perhaps say that a personal mail would have been nice before a public calling out. :( Yeah, true - consider my karma reduced. I wanted to publicly vent my frustration at the current process. I'd like to contribute more, but not if this is the result: pull requests that get ignored for months (or years!), or get fobbed off due to to some concern about formatting or an imperfect UI. If you're saying that the preferred mechanism is for contributors to privately cajole the lead maintainer every time they want a pull request looked at, then, no. All the pull requests are sitting right there: https://github.com/systemed/potlatch2/pulls Speaking of which, here's another pull request I didn't mention earlier: https://github.com/systemed/potlatch2/pull/67/commits From memory, that was something like 15+ hours work - completely ignored. Meaning bad data continues to be created in the OSM database. (https://trac.openstreetmap.org/ticket/4378 ) Is it unreasonable to expect quicker responses? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Outstanding pull requests (Attn Richard F)
Could we consider changing the process? Any of these things would help: 1) A dev build where almost all pull requests are accepted, and which is the accepted starting point for new features. (The production build is a subset of those branches) 2) More reviewers/people with permission to accept pull requests for the prod build 3) Lower standard required to accept pull requests. I completely understood the urgency of working on the purge process. Starting a whole new editor project? Not so much. Steve On Tue, Jul 17, 2012 at 5:27 PM, Richard Fairhurst rich...@systemed.net wrote: On 17/07/2012 04:30, Steve Bennett wrote: https://github.com/systemed/potlatch2/pull/33 https://github.com/systemed/potlatch2/pull/36 https://github.com/systemed/potlatch2/pull/49 https://github.com/systemed/potlatch2/pull/66 Seriously, now. These slow review times, and blocking pull requests for trivial reasons (I'm not a great fan of the digger, [I] want to check first whether it can be done without try... catch) are total motivation killers. Yeah, I know. Mea culpa. I've been ridiculously busy recently due to, basically, changing jobs and another project. I'm hoping to get a chance asap. Richard ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Magic Roundabout v2
Hi all, I didn't get any response to this. Could someone please have a look at this branch? I put quite a lot of work into this, and it's a pretty useful tool - especially since we're about to do a huge amount of remapping in some areas. Or should I just submit a pull request? Steve On Sun, Mar 18, 2012 at 3:20 PM, Steve Bennett stevag...@gmail.com wrote: Hi all, I've cleaned up, improved and reworked my old magic_roundabout patch, and rebased it off the current master. It's a pretty cool piece of code, but there's quite a lot of it. Previously there were some issues with how it dealt with undo/redo, but I've reworked that now. https://github.com/stevage/potlatch2/tree/magic_roundabout2 Here's the introduction I wrote for it originally: Introducing the amazing Magic Roundabout tool. This tool creates a roundabout from scratch. To use it, start drawing a way from the node that will be at the centre of your roundabout. The length of the way you're drawing determines the radius of the roundabout. Press 'M'. Bam! In one hit, it: 1) Creates a circular way of the appropriate size and location, with an appropriate (?) number of nodes. 2) Creates junctions wherever it hits any other roads 3) Determines the most appropriate highway=* tag (the highest of any of the roads that it touches. 4) Sets those tags, plus junction=roundabout 5) Splits any ways that ran from the central node across the roundabout 6) Removes the interior half of those ways. What it doesn't do: 1) Have a particularly newbie-friendly interface (currently A for magic roundabout - open to ideas) 2) Do anti-clockwise roundabouts 3) Do composite undo. 4) Handle any special cases. (I haven't really looked. It's 3am. The undo stuff confused me greatly.) Improvements: Did do: 6) Now handles a wider variety of cases, so it almost always ends up with clear space inside the roundabout. Didn't do: 3) Now it's a well-behaved card-carrying member of the composite undo society. 4) Now it handles various special cases, and seems pretty solid. Included in this patch is also another tool, on which Magic Roundabout relies: Make Junctions: 1) Select a way that crosses some other road/railway ways 2) Press J 3) All missing junctions between the two ways are detected and created. Now, the git history of this branch is a bit messy, so I'm open to suggestions on what to do next. There were files touched in the branch (notably, autocomplete.as) which were totally irrelevant. I've undone these changes, but they're still in the history. (I did experiment with removing them with git filter-branch but it got a bit scary...) So, would anyone mind having a look at the new, improved version, and suggesting any improvements? Then, hopefully we can get it into the main branch. Thanks, Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4395: Potlatch2 creating one node ways
On Tue, May 8, 2012 at 8:11 AM, OpenStreetMap t...@openstreetmap.org wrote: Please read the How to be a helpful bug reporter paragraph on the first page of trac.osm.org and come back when you can file a helpful report. Please read how to be an asshole to people who are trying to be helpful... oh wait, apparently you wrote that one. Someone goes to the trouble of logging into the Trac, fighting through the horrible user interface, filing a bug with the correct component, and writing a bug report in a foreign language, complete with example of the bad behaviour - and your response is to tell them to fuck off for not having RTFM. Let's be nice to the people who report bugs, and maybe they'll give us some more details. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4395: Potlatch2 creating one node ways
On Tue, May 8, 2012 at 5:40 PM, Frederik Ramm frede...@remote.org wrote: In Richard's defence, there are over 1500 changesets with a comment of removing multiple consecutive identical nodes in ways/delete one node ways. please help by giving hints, about how this potlatch bug can be reproduced http://trac.openstreetmap.org/ticket/2501;. It seems that it is a long-standing problem, and repeating that there is a problem doesn't bring us closer to a solution. I can't speak for anyone else, but there is nothing in any of my mapping workflows that would ever cause me to view such a changeset message. They're not very visible. If fixing this bug is a priority, by all means, let's do something like contact individuals, or post on mailing lists etc. Being rude to people who submit bug reports is never appropriate, even if they're the 1000th person to report the same error. That's our problem, not theirs. It would be just as easy to reply Thanks, we're working on it, see #2501. You seem to have just submitted a patch that fixes the multiple consecutive nodes part, but the one-node-way part seems to be yet unsolved. Nonetheless you (Steve) closed ticket #2501 as fixed; is it possible that the submitter of #4395 created his ticket in response to your closing of #2501, to remind people that half of #2501 is not fixed yet? All the recent (last 18 months) discussion on that bug report was about the repeated nodes problem - although admittedly it was originally raised with a broader scope - hence my closing it. It looks like https://trac.openstreetmap.org/ticket/4378 describes at least one reproducible situation where single-node ways get created. (No idea about your hypothesised reason for #4395 being created.) Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4375: Potlatch 2: join nodes function creates duplicate nodes in ways
Good to know - I'll take a look next week. Pretty sure I wrote that code, and it sounds like I missed a special case or two. Steve On Tue, Apr 24, 2012 at 5:44 PM, OpenStreetMap t...@openstreetmap.org wrote: #4375: Potlatch 2: join nodes function creates duplicate nodes in ways ---+ Reporter: Firefly! | Owner: potlatch-dev@… Type: defect | Status: new Priority: minor | Milestone: Component: potlatch2 | Version: 2.0 Keywords: | ---+ It seems to be a bug inside the Potlatch function join nodes (key J). When I stick together two (or more) areas by joining nodes, sometimes the OSM inspector tool tells me, I have created duplicate nodes in one of the resulting ways. f.e. http://www.openstreetmap.org/browse/node/1728680163 http://www.openstreetmap.org/browse/node/1706551424 I can reproduce it as follow: Way 1 contains node 1a and node 1b. Way 2 contains node 2. I join node 2 with node 1a. Later I join the resulting node with 1b. After uploading I will get the duplicate node in way. Normally this situation will not happen so often, but at edges of three or more areas you can have a lot of nodes and it is almost impossible to take care for all ... Best regards -- Ticket URL: https://trac.openstreetmap.org/ticket/4375 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Brokenness on Mac with Flash 10.1
On Mon, Mar 26, 2012 at 5:42 PM, Richard Fairhurst rich...@systemed.net wrote: Out of interest, Intel or PowerPC? 2.66 GHz Intel Core 2 Duo. 4GB 1067 MHz DDR3. OSX 10.6.8. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Brokenness on Mac with Flash 10.1
On Mon, Mar 26, 2012 at 5:09 PM, Tom Hughes t...@compton.nu wrote: Certainly not related because the new version hasn't been deployed on the main site yet! It''s only on http://master.apis.dev.openstreetmap.org/ currently. Ooh, is that new? I've been wishing for a bleeding edge build for a while :) Incidentally, that one is showing my locale as null. It's also showing a variation on the above-reported problem. Dragging POIs to the main map causes the POI icons themselves to disappear, the feature panel doesn't work etc. (Again, Chrome is fine.) Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Weekend summary
On Mon, Mar 26, 2012 at 6:01 PM, Richard Fairhurst rich...@systemed.net wrote: - FileBank to allow all images/config files to be stored in a .zip, so you can load one assets file per P2 instance rather than 300 or so. Should be live on osm.org in the next few days. Live now, woot. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4298: Keyboard shortcut: Move to next selected node in a way
Interesting idea about making follow behave this way when you're not drawing a node. And shift-F to go backwards? ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] State of play
On Sat, Mar 10, 2012 at 6:41 PM, Tom Hughes t...@compton.nu wrote: I would just delete them once they aren't needed anymore. Delete them locally, you mean? Do you then need to push the deletion? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Testing new versions
On Thu, Mar 8, 2012 at 7:12 AM, SomeoneElse li...@mail.atownsend.org.uk wrote: How hard would it be have a version of Potlatch2 available after merging for final testing before becoming the default P2 version on the site? To be useful it'd need to be able to be invoked with a GPX file (not necessarily as another edit dropdown, though that'd be nice). With the best will in the world, sometimes when fixing stuff other stuff breaks, and it'd be nice to be able to catch any issues before they go live for everyone. I also think this would be really useful. There was a recent bug that I couldn't reproduce on my machine but I could reproduce on the deployed site. Unfortunately I couldn't distinguish* between something unique about my machine and bug has been fixed in master, but not yet deployed. Having access to a bleeding edge build deployed on openstreetmap.org would have been very useful in that case. Similarly, if we suspect a new bug report has already been fixed, we could just say Would you mind trying to reproduce it on the beta site? Steve * Ok, I guess I could have tried to find out the version number of the deployed version, then checkout that version. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] More UX testing
On Sun, Mar 4, 2012 at 5:05 AM, Andy Allan gravityst...@gmail.com wrote: No, often they don't realise. For example, when there's a supermarket tagged as an area, they think the supermarket isn't mapped, and try adding an icon for it. The turquoise building outline (or whatever) doesn't lead them to think that it has been mapped. So, areas should show the icon on the centroid, next to the text (if any)? Well, I think hairdressers was one. But the bigger point is that if the map style has different icons (e.g. the opencyclemap style) then switching map styles doesn't update the sidebar. The icons displayed are more of a map style consideration than a map features consideration, to a certain extent, so maybe the map style should define the icon, and the sidebar pick them up from there. Dropping an icon and having a different one appear isn't great. Just looking at the default style and default map_features, the POI icons line up pretty well between the map and map_features. There are a few with no map icon (eg bookshop), but most are the same (including hairdressers). The only one that is actually a different icon is the various place=* features. Other styles like the cycle map one don't seem to have many POI icons defined anyway, so the point seems moot? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Designation tag on most map features
On Tue, Feb 21, 2012 at 10:07 PM, Richard Fairhurst rich...@systemed.net wrote: Firstly, we need the ability to load alternative map_features files. The reason that isn't implemented right now is because no-one has coded it. ;) Hmm, I wonder if potential contributors are possibly put off by the lead maintainer responding to reasonable questions with dismissive remarks like My decision as P2 maintainer is that designation= is an appropriate tag in this place, that's why I put it there and that's why it will remain there. Secondly, the best way of getting the pretty easy change requests fixed would be to identify someone to curate the default P2 map_features.xml. At Give control (and the whole workload) of map_features to a single person? Why is that a good way, let alone the best way? The problem of selecting a sensible subset of the vast number of tags in use is a really hard one, and requires debate and discussion, not autocratic decision making. present it's largely done by Andy and me when we get a spare minute, but we do of course have the rest of P2 to look after! On occasion I try and devote a whole day to fixing the accumulation of little P2 issues - the last time was in October, I think - and often this sort of thing gets tackled then. To find someone with an editorial eye to sensibly curate the tags on a ongoing basis would be good, but I'm not pretending that person would be easy to find. Sounds like you need more P2 contributors in general - see my first comment above. For the specifics of sensibly curating the tags, I suggest the sensible way forward is to work with something like Sam Vekeman's excellent open map features spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0Am70fsptsPF2dGZBb3FfWHlhWTVBTGZ5ZV81LVFSMkE Then we for each feature we can systematically: - support - not support - plan to support (when someone gets around to it) - support (/plan) in an optional (region-specific? plugin?) way Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Internationalisation
On Mon, Feb 20, 2012 at 5:38 AM, Richard Fairhurst rich...@systemed.net wrote: This is happening to me now too (on the Mac, in both Safari and P2). Bit bemused as to why - nothing has changed in the P2 code that should cause it AFAIAA. Will look it into it, though probably not until next week as I'm on deadline with the day job. As far as I remember, it's been doing this for months for me. Maybe as long as the whole time I've had the mac - about 6 months. I don't have any dev tools on the mac though, so a bit hard to investigate. Incidentally, just to be clear, the only [object Object] I see is in the GPS data dropdown, so it could be a race condition or something in how that gets populated. The Chrome Flash player on Mac seems flakey to me in general. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Designation tag on most map features
I've just noticed that about a year ago, the designation tag was added to the common inputSet, meaning it appears on a wide variety of features: https://github.com/stevage/potlatch2/commit/e1970c90ae07d1d1bb98692a80d2131ae115ae5e There are two issues with this: 1) The designation=* tag is apparently only relevant to UK mappers. (IMHO it's a bit redundant alongside highway=* and access=*, but that's beside the point...) 2) Putting it in this inputSet means it shows up on all kinds of objects other than highway=*. Obviously 2) is easy to fix. But what about 1? Is it time we implemented locale-specific map_features? IMHO it's incorrect to display a region-specific tag like this to everyone in this way. I'm guessing that's the cause of its misused here: http://www.openstreetmap.org/browse/way/143010599/history In the meantime, what can we do about it? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Internationalisation
On Wed, Nov 30, 2011 at 10:47 PM, Andy Allan gravityst...@gmail.com wrote: Any feedback from anyone? I'd love to hear from people who a) i18n was working 2 months ago and is working now b) i18n was working 2 months ago and isn't working now c) i18n was not working 2 months ago but is working now d) i18n was not working 2 months ago and still isn't working now The biggest problem is that I'm in group a) so it's hard for me to debug. b) would worry me, c) is ideal and d) would be unfortunate but certainly worth knowing. e) I don't know if i18n used to work on my Mac, but it's not working now? I get 3 copies of [object object] in the GPS drop down list. From trial and error, the middle one is the right one :) My main computer is an XP desktop, but I use a Macbook Pro for work, and sometimes do a bit of OSM on it, using Chrome. Another issue I've noticed (possibly a quirk of Flash on mac) is my system-wide keyboard settings (I use Dvorak) aren't respected in the main editor. So pressing say d (physically the h) key is interpreted by Potlatch as an H. More annoying for punctuation. Actually typing in edit boxes is fine. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Github, and tram/road issues
On Thu, Feb 16, 2012 at 8:11 PM, Andy Allan gravityst...@gmail.com wrote: http://wiki.openstreetmap.org/wiki/Potlatch_2/Developer_Documentation#Sending_patches We like patches in any way, but if you're sending a pull request, please send it to systemed on github ([1]) aka Richard, rather than git.openstreetmap.org or the openstreetmap account on github. Thanks. Thanks, I did eventually stumble upon this. Are there any policies/practice around using feature branches? I'm not sure if it's a Github limitation (or standard Git), but it seems one doesn't actually send individual pull requests - at any one time, you can have a grand total of 1 pull request outstanding. If I'm working on a bug fix for bug #1234, is it easier if I make a branch (eg, bug-1234) first? Does that help anything? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Github, and tram/road issues
Hi all, I just did a pull request to the Github repository (which is fairly up to date) but it looks like no one is watching. Is there somewhere else these pull requests should go? It's here anyway: https://github.com/openstreetmap/potlatch2/pull/5 This particular issue (tram routes not showing up in simple editor) was trivial to fix but raises two other issues. The situation where a tram line runs down the middle of a road is relatively common in my city, but fairly rare around the world. So ideally we probably don't want the Tram Route: add to a route drop down appearing on every road. What we would like: 1) If there is already a tram route relation on a road, then show the drop down. 2) If the road (highway=*) is also a railway=tram, then show the drop down. Is either of these possible atm? I'm not sure. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] What happened to the Natural category?
On Mon, Jan 9, 2012 at 8:57 AM, Charlotte Wolter techl...@techlady.com wrote: I edit a lot in the American Southwest, where there are a lot of natural parks, national forests, preserves and many other natural areas. However, Potlatch2 includes no category for natural. Wwe used to have it in Potlatch1. Why is it no longer included? It looks included to me, on the live version on openstreetmap.org. Select a closed way (area), and 'natural' is a category between Water and Barrier. Also, because the Southwest is a desert area, where a road crosses a stream, often there is only a ford rather than a bridge. This is because 99% of the time the stream is dry. Can we add ford to the Bridge drop-down menu? Seems pretty reasonable. The actual tag is ford=yes, so it would be a separate checkbox. Btw you can add requests here: http://trac.openstreetmap.org/ And can we add intermittent under the Water category? For anyone implementing this, the tags are intermittent=yes or seasonal=yes. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Git starter?
On Thu, Sep 1, 2011 at 2:34 AM, Andy Allan gravityst...@gmail.com wrote: A few other things spring instantly to mind - an ill-advised redesign of the Undo system, a few problems with the Magic Roundabout system (e.g. having a 50% chance of nuking a way when trying to shorten it) and, more than anything else, lots of cases of commits generating compiler warnings. That these commits were to trunk kept necessitating other developers stepping up and fixing the build before they could continue with their own work. That was getting quite disruptive. I see - thanks for elaborating. I hadn't realised that those issues were so problematic. I guess one advantage of commit first, discuss later is that some of these issues (eg, the undo system) get forced into the limelight. There's clearly a balance, though, so I look forward to seeing how it works out this way in practice. I'd written that before the situation was clear. But there's also the distinction that it's not necessarily what OSMF is deploying, and I try to discourage anyone from getting worried about which repo to clone from. If you clone from mine, and then want to pull changes from someone else, it all comes out the same. Any notion of One True Repo just causes more confusion later on! I guess it's the difference between there is one true repo (and also other true repos) and there is no one true repo. Again, thanks for the explanation. Make sure you realise that there's nothing that makes it the definitive repository other than social factors. Unlike svn there's no central repository. It's only definitive in that Richard is the current maintainer, and the only difference he has over the rest of us is that TomH generally doesn't disagree with him (on p2 matters at least!). But you could also view the OSMF repo as definitive if you care about the version that's actually deployed on osm.org Ok, so Richard runs the debug repository, Tom runs the production repository. Anyway, I have now got a working build again. I think the gotcha that hit me last time was that you can't do this: 1) Clone from the OSM repository to your computer 2) Make changes 3) Publish to Github You have to do this: 1) Clone from OSM repository to your Github account 2) Clone from your Github account to your computer 3) Make changes 4) Publish to Github, and optionally send pull request (git push/git push origin) There's probably some way of recovering if you go down the wrong path (rebasing maybe), but it was beyond me. Anyway, I'm all good now. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Git starter?
On Wed, Aug 31, 2011 at 5:01 AM, Andy Allan gravityst...@gmail.com wrote: If there's any gotchas let me know. Ok, since you asked: First you need to get a copy of the potlatch2 repository from somewhere. It doesn't really matter where it comes from... ... There's many different ways to share your changes with the rest of the world... These are not good words to reassure the newcomer that these instructions are simple will take him where he wants to go :) The github.com account is optional. When it comes to publishing your changes then yes, you do need to put them somewhere public, whether that be on github[1], another server, your own server, or where ever suits. When you have something published then just let one of us know where (e.g. by emailing the list) and we can start reviewing and incorporating your code. I find this bit of using git somewhat deflating. With SVN, I was able to commit my changes into the repository. Although the changes weren't immediately in the production release (fortunately), other developers would immediately see them next time they did an update. Perhaps it's irrational, but committing to the repository is a lot more satisfying than publishing to my own private repository and hoping that someone comes along and takes a look. Before: svn commit After: git commit Email list Andy, Richard, or someone (who are the code reviewers, anyway?) reviews changes, optionally accepts. If you need a hand with any of this just give me a shout, I'm more than happy to help. I guess I'll have to try the github fork/clone thing again and see what goes wrong again. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #3562: Make dragging unselected POI do select pan
On Tue, Jul 19, 2011 at 2:29 AM, OpenStreetMap t...@openstreetmap.org wrote: and took about five minutes. People have spent orders of magnitude more time filing tickets/usability reports/what-have-you about this... than actually fixing it. If only people were more prepared to roll up their sleeves and do stuff... ;) Speaking for myself: 1) I tried to migrate to Git and failed. I had two goes at it, spend a couple of hours, and couldn't get a working dev environment. Also, I don't really get the Git workflow - checking into SVN was very straightforward, but Git seems to be something like store it in your own repository and then convince people to do something with your changeset. I keep meaning to re-investigate. 2) I don't have internet at home atm. So the onlly value I can add is commentary, for the next few weeks. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #3836: potlatch2.2 locks up, unable to save edited data
On Tue, Jun 21, 2011 at 7:46 PM, Richard Fairhurst rich...@systemed.net wrote: Very much intentional behaviour and what you should do! Fwiw, I found this quite unintuitive and only realised how it worked after some months of use. It would be good (such helpful words, I know) to have some kind of visual indication that a changeset is open, and hence to see what changeset is currently pending. Actually, now that I think about it, there's really no interface support to manipulate changesets, other than the shortcut key to close a changeset. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Potlatch 2 stylesheet changes
On Mon, Jun 13, 2011 at 5:40 AM, Richard Fairhurst rich...@systemed.net wrote:
1. casing-width is now relative to the stroke width.
OLD: { width: 5; casing-width; 7; }
NEW: { width: 5; casing-width: 1; }
How is this interpreted:
way { width: 5; z-index: 2; }
way { casing-width: 1; z-index: 2; }
Will the second one have a total width of 7 or 1?
Steve
___
Potlatch-dev mailing list
Potlatch-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] New docs
On Fri, Mar 18, 2011 at 12:20 PM, PierZen infosbelas-...@yahoo.fr wrote: Richard, as you said, the vmatch does the job perfectly with assigning the value=unspecified using the following tag definition. tag k=highway v=unspecified vmatch=primary|secondary|tertiary|footway|track|unspecified/ Yep. Although with this particular tag, this would be better: tag k=highway v=road vmatch=primary|secondary|tertiary|footway|track|unspecified/ highway=road being the official way of specifying an unspecified road. Hmm, I wonder if we should have a special value that tells Potlatch2 to wipe the values if the main key value is not set. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Codebase and git
On Wed, Mar 9, 2011 at 6:25 AM, Andy Allan gravityst...@gmail.com wrote: Happy to answer any questions, but remember things are neither set in stone nor necessarily fully thought-through! Hi Andy, First - thanks for taking the time to write up this documentation. My question is about the paragraph beginning Publishing your changes. There's many different ways to share your changes with the rest of the world. Let's take the hypothetical situation in which a time poor dev (let's call him Steve) just wants to get back to his old workflow, and doesn't particularly care to investigate this brave new world of Git any more than he needs to. Would you mind spelling out the best way? From my brief skimming of the rails port page, it looks like I should sign up at github, and commit changes there. Is that the best? I don't really want to explore one method, only to find out later that there was some downside I didn't know about. I just want to commit stuff somewhere central that you, Richard and whoever can see (and hopefully act on) patches at... Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] HOT Potlatch2 presets
On Tue, Mar 15, 2011 at 1:53 PM, Pierre (PierZen) infosbelas-...@yahoo.fr wrote: At this point, the menus are visible but we cannot select the various HOT categories from the left menu. The HOT dialogues Boxes are not showed properly. When selecting a node or a way, and selecting a HOT Menu item on the left, the dialog box and name of the category listed always correspond to IDP Camp. I don't know if this is the cause, but a few things I notice: - your comments aren't valid XML ( !-- -- --) - you have some presence= - you have some entries with duplicate icons: feature name=Source categoryHOTFeaturesCommonTags/category icon image=features/hot.png/ icon image=features/hot.png/ point/ line/ inputSet ref=HOT Source / /feature Maybe the problem is some kind of XML QA issue like these? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #3567: Add ability to create a no_u_turn restriction with a way via
On Tue, Mar 8, 2011 at 7:44 PM, Ed Loach e...@loach.me.uk wrote: Does that make sense? It not I'll try and draw a diagram. I think there are some junctions like this on the A4123 between Wolverhampton and Birmingham, but it's been a while since I drove down there. Ok, I get it now, but it would be very good to have a concrete example, with the roles etc worked out. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] I wrote some overview documentation
http://wiki.openstreetmap.org/wiki/Potlatch_2/Developer_Documentation/Overview Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #3360: Switching backgrounds doesn't respect Dim setting
Thanks Ed, with that description it was actually quite easy to fix. Steve On Sun, Mar 6, 2011 at 5:17 AM, Ed Loach e...@loach.me.uk wrote: I'm back at my keyboard now. And on the live site I reproduce the problem as follows: Go to edit mode. It has correctly remembered that when last editing I used Bing undimmed. Switch to Mapnik background layer. This shows as dimmed though the dim check box still suggests it should be undimmed. Check the box and uncheck it to get Mapnik not dim. Switch back to Bing layer. Again check box remains as not checked, but background defaults to dimmed. To get it not dim you have to check and clear the checkbox. Want me to add all that to the trac ticket? Ed -Original Message- From: Ed Loach [mailto:e...@loach.me.uk] Sent: 05 March 2011 16:44 To: t...@openstreetmap.org; potlatch-dev@openstreetmap.org Subject: Re: [Potlatch-dev] [OpenStreetMap] #3360: Switching backgrounds doesn't respect Dim setting I don't use Yahoo imagery. Will see if I can find steps to reproduce, but when I reported it it seemed to be every time I switched the background defaulted to dim even if dim checkbox wasn't checked. Sent from my HTC -Original Message- From: OpenStreetMap t...@openstreetmap.org Sent: 05 March 2011 15:28 To: potlatch-dev@openstreetmap.org Subject: Re: [Potlatch-dev] [OpenStreetMap] #3360: Switching backgrounds doesn't respect Dim setting #3360: Switching backgrounds doesn't respect Dim setting +--- Reporter: EdLoach | Owner: potlatch-dev@… Type: defect | Status: closed Priority: minor | Milestone: Component: potlatch2 | Version: 2.0 Resolution: fixed | Keywords: +--- Changes (by stevage): * status: reopened = closed * resolution: = fixed Comment: Fixed. Ow. My poor confused brain. [25522]. I don't even know if this was the OP's problem, but there was a bug where Yahoo imagery was always dimmed. -- Ticket URL: http://trac.openstreetmap.org/ticket/3360#comment:3 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] What to code next?
Hi all, Just wondering if anyone has any cool ideas for features or whatnot, that they haven't got around to entering as bugs in Trac. I don't have any immediate code this next, so I'm open to suggestions. Otherwise, I might explore the simultaneous features issue (http://trac.openstreetmap.org/ticket/3530). I'm also open to non-coding requests like mapcss, map_features, or documentation. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Codebase and git
On Mon, Feb 28, 2011 at 8:31 PM, Richard Fairhurst rich...@systemed.net wrote: r25368 should be the base for the functionality freeze. That's certainly not to say that we abandon the stuff that's been done since then, but we will separate it into the essentials (a and b above) and the enhancements (new functionality) as part of the move to git, and then move the new functionality into the core code as and when it's ready. Can you elaborate a bit on who we is, in this context? And what kind of process of review and integration of new features do you envisage? I guess I'm wondering how long we can expect to wait between developing a new feature and seeing its deployment. Also, is there any possibility of hosting a bleeding-edge build, configured to work on the live OSM db? That way, if we develop a feature at someone's request, they can immediately get access to it, rather than having to wait for the next stable build. Something like http://www.openstreetmap.org/edit?editor=potlatch2-dev;... Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Introducing Magic Roundabout tool
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(). You mean, provide an alternative contract, I think. :) I might even go so far as provide a more useful contract... Writing actions in the future tense is hard. My first thought was to create a ImmediateCompositeUndoableAction class. But it seems overkill for such a small change. But, you know, if you feel that the contract is important, it would be quite easy. And then in addition to addAction on MainUndoStack, we could add addDoneAction which takes an ImmediateCompositeUndoableAction, so there is no risk of un-done actions being not done, nor done actions being re-done.. 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 Sure, that would work. But to me, it's messy to have to create a subclass of action for these rather esoteric, single-trick ponies. Anyway, let me know if you want me to write a generic ImmediateCompositeUndoableAction class. Steve ___ 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 11:21 PM, Andy Allan gravityst...@gmail.com wrote: add a separate undo step for every junction. Since only one keypress causes MakeJunction, it should be undoable in one button press. MakeJunction should have its own composite action and push things onto it when it loops round like this, then passes just one action back to the caller. Err, yes, that was certainly the goal :) Oh, and finally, I suspect some of these composite actions should be in net/systemeD/connection/actions - especially MakeJunction since you've now shown with MagicRoundabout that it's a useful too for other actions to build on top of. Good idea - didn't occur to me. Right, well, if this all turns out to be gobbldy-gook don't worry too much - I'm happy to rewrite them when I get a chance. If you want to give it a go yourself I'm 100% happy to explain further or answer questions. Thanks, I'll have a bit of a read up and explore. The big problem I was encountering was that I needed the intermediate results of some of those actions, in order to take later steps. It was no good saying after this method, we'll create a circle, then we'll split some things, then we'll delete some ways. Ok, now go and do that stuff. I actually needed the split to have taken place so I could identify which half of the split was the one that I wanted to delete. I was since then thinking that what I might need was a kind of CompositeUndoableAction that also carries out the actions straight away (like the main undo stack), as well as piling them up for later. As your doc points out: A Composite action doesn't actually make any changes itself - it just figures out what list of changes are going to be needed to meet the overall goal. and Although usually irrelevant, this becomes important when iterating over things, and sometimes tricks like iterating backwards over the list become necessary. You can see the ultimate in juggling while working out relations handling during SplitWayAction since you need to insert the new way perhaps multiple times into a given relation, but you need to work out all the insert indexes up-front before any actual inserting is done. 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? Also, while I'm irreverently questioning everything: There's two conventions that don't help much in understanding, but they are widely used This is very true. Could we perhaps change them? Maybe rename undo as actionStack, and rename the ubiquitous performAction argument as actionStackFunc or something. Until last night, I honestly had no idea that actions weren't getting executed immediately. And even then I only had a suspicion about it, until I caused an infinite loop with some code that kept trying to delete a node until it ran out of nodes (which never happened because they never got deleted). So, I think these conventions are perhaps beyond quaint and have reached harmful and counterproductive. (Something about the term undo in particular made me assume that we were piling up a list of actions in case we needed to undo, whereas actually we're piling up a list of actions *to be done*. The fact that the user may later undo them is actually quite irrelevant.) 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. But, since I clearly don't understand how this stuff works, these impertinent suggestions may be completely off the mark. Steve ___ 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 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 difference is from this: Create action A Create action B Create action C Add to main undo stack - do action A - do action B - do action C To this: Create action A - do action A Create action B - do action B Create action C - do cation C Add to main undo stack - (already done). I might be overlooking something, of course. I still get a couple of spurious entries in the undo list which I haven't really investigated yet. And there were some weird fake duplicate nodes being shown, which might be a symptom of node state not being managed properly. Steve ___ 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: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.
Steve
___
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 3:02 AM, Steve Bennett stevag...@gmail.com wrote: 4) Handle any special cases. (I haven't really looked. It's 3am. The undo stuff confused me greatly.) Oh, what do you know, I found one. If two of the ways meeting at the middle are actually one two ends of one long way, then too much gets deleted. Steve ___ 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 6:20 AM, Andy Allan gravityst...@gmail.com wrote: Unfortunately it doesn't compile - I think you added a length() function to Elastic.as but haven't added it in! Also, DrawWay.as#328 needs fixing since that doesn't compile either. Could you have a look as soon as you get the chance - I'll hold off from uploading my commits for the moment and just work on things locally. Doh, I committed too far down the tree - forgot that Halcyon isn't in the Potlatch2 dir. Done now. (Also, best to avoid committing code with compiler warnings - there's now some missing type declarations, class-scoped vars (I suspect you want these instance scoped), duplicate variable declarations - give me a shout if you're unsure or don't have time and I can sort them out for you) Whoops, sorry about that. All fixed now. I've discovered some slight flakiness, in that occasionally it produces a bad result, and if you try to undo, you get an exception. I'll need to understand a bit more how to use the undo system. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] i18n using babelFx
On Wed, Feb 23, 2011 at 2:10 AM, NopMap ekkeh...@gmx.de wrote: Just to explain the situation: I am running an (unmodified) P2, but I have built a custom map_feature file from scratch. Of course it would be good to translate both. I wonder how this would best work? Maybe we could have auxiliary map_features files that only serve to change the descriptions and names. Something like: paths.xml: feature name=Cycle path id=cycleway ... /feature. paths_fr.xml feature ref=cycleway name=Piste cyclable / But it could get complicated trying to assign id's to every element, including input's etc. Or do you simply have lists of translations, with contexts, like cycle path-piste cyclable? That would be very fragile though, breaking every time a description in English changed... Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #3528: Grouping map features that share a top-level tag
On Mon, Feb 14, 2011 at 6:25 PM, NopMap ekkeh...@gmx.de wrote: I would like one map_features entry that shows only one drop-down box with a combined list of foot and hiking relations. When you assign relations to an item, nothing needs to change. When you create a relation or change its tagging, only hiking should be saved as it is used more frequently and also more intuitive. The important part is having only one drop-down-box for selecting equivalent relations. Ok, done: http://trac.openstreetmap.org/changeset/25359 Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] What do the new cycleway values mean?
On Thu, Feb 3, 2011 at 11:32 PM, Andy Allan gravityst...@gmail.com wrote: Aargh, what a lot of confusion. The cycleway=shared|segregated is an option for standalone ways (either highway=cycleway or highway=path) to indicate whether the bikes and pedestrians share the same tarmac. In the UK there are two white-on-blue street signs - one with a man and a bike beside one another with a white line between them (i.e. segregated) and one with the man above the bike and no dividing line (i.e. shared). There is a third sign (cycling only) but that can be expressed by bicycle=yes foot=no etc. I've implemented this here: http://trac.openstreetmap.org/changeset/25365 I think it's a pretty good tagging scheme actually. The only thing it doesn't really cover is priorities (eg, paths where pedestrians have right of way), and situations with more than just bikes and pedestrians (notably, horses). Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
No, it won't, for reasons already explained by Nop. Moreover the current system has the distinct advantage that it can be used to describe what's on the ground - a stroke of a pen on a planner's chart I disagree, but as this is a distraction from the actual discussion at hand, I'll leave it. Which is actually a different thing. What I'm suggesting is that proposed and construction would be two more icons on the grid of road types, whereas you are suggesting the lifecycle should be a dropdown on every single one of the hundreds of thousands of normal roads. It's quite unfair to compare two icons against hundreds of thousands of normal roads. The fair comparison would be a minimum of 3 icons (road, rail, footpath/cycleway) against one dropdown box. Pretty unnecessary, imo. I think you're misunderstanding the current purpose of the simple tab - providing a simple UI for the majority of the mapping. Proposed buildings is pretty niche, and should be incorporated in a way becoming of its niche-ness. Adding dropdowns over every object for such a rare occurrence is the messy way. Ok, proposed buildings are niche. Roads under construction aren't. Maybe this is some philosophical difference we're going to need to debate out, but I see covering these tags properly as comprehensive, complete and thorough - not messy. Yes, the UI needs to be designed in a way to maximise access to common tagging tasks - I've even created tickets to that effect. But the trade-off you're suggesting between simplicity and completeness is artificial, imho. So here are three potential solutions: 1 put tags like this on a tab called advanced, which simple users don't have to use. 2 hide tags like this unless some user option called advanced is enabled. 3 put tags like this only in an enhanced map_features.xml. the tagging code is way complicated In CategorySelector? I'll have to have a look. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
On Wed, Feb 16, 2011 at 10:24 PM, Richard Fairhurst rich...@systemed.net wrote: I'm also a little aware (having optimised the CategorySelector stuff yesterday) Btw - awesome. :) Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] How about another build?
On Tue, Feb 15, 2011 at 10:36 PM, Andy Allan gravityst...@gmail.com wrote: Ah, I've just done this a different way, and then read your email. Ho-hum! Interesting - I'd totally forgotten about my above suggestion. I actually implemented something extremely similar to your implementation (http://trac.openstreetmap.org/changeset/25309) but didn't get around to checking it in. Cool. :) Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Suggestion for lifecycle tag - comments?
Hi all, Thought I'd solicit comments before implementing the following: feature tag k=highway v=tertiary lifecycle=road/ inputSet ref=road_lifecycle/ ... /feature inputSet id=road_lifecycle input type=choice presence=onTagMatch name=Life-cycle lifecycle=yes choice value= text=Complete description=Road is open for business./ choice value=proposed text=Proposed description=Road has official approval, but construction has not started./ choice value=construction text=Under construction description=Road is under construction./ ... /input /inputSet lifecycle id=road stageproposed/stage stageconstruction/stage stageabandoned/stage ... /lifecycle This would have the effect that highway=proposed, proposed=tertiary would get matched (thanks to the lifecycle definition). Selecting from a dropdown with lifecycle attribute set would cause the same split tag structure to be created (or removed). (That same attribute would cause the key attribute on the lifecycle element to get set to the tag on the feature that has the lifecycle attribute - a bit ugly) Anyway think the element names could be refined slightly. Are there any other tags that work this way, apart from the lifecycle ones? Do different tags have different lifecycles (I seem to recall that railways have more states). Should I just hard-code it all? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?
On Wed, Feb 16, 2011 at 9:41 AM, Andy Allan gravityst...@gmail.com wrote: My first thought is to just have another couple of highway types ( a proposed highway and a highway under construction ) with a list of classifications in a choice input, and maybe some date inputs for when they are opening and so on. My feeling is that proposed is really not a type of highway, and that eventually this tagging scheme will be replaced by something a little less idiosyncratic: highway=tertiary lifecycle=proposed That could all be done quite easily with the current map_features code, and more importantly, there would be no unnecessary UI for managing the lifecycle of the 99.999% of roads in OSM that are neither proposed nor under construction. Ok, first, I don't think the UI would be different either way. All the code would be happening behind the scenes, to make a simple UI: simply an extra dropdown on a misc tab or something. I think what you're proposing shapes the UI too much around the underlying tagging scheme. And I don't think you could change from one lifecycle stage to another through the Simple view. For example, if you changed from Proposed road highway=proposed proposed=tertiary to Road under construction, you'd actually get: highway=construction construction=tertiary proposed=tertiary Not to mention you'd need to duplicate all the road types for every life cycle stage. You'd also need to add proposed railway, proposed cycleway, proposed foothpath, proposed track, proposed bridleway, proposed building, etc etc (and repeat for construction etc). Pretty messy, no? Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Short cut keys for node-by-node navigation
I just added some node navigation shortcuts in http://trac.openstreetmap.org/changeset/25299 . I think they're cool so thought I'd describe them here: When a way node is selected, , (aka ) moves down one node, while . (aka ) goes up a node. If you reach the end of the way, you loop around. When you cycle ways (using /), the node you had selected before, if any, is remembered. Pressing , or . (they're not distinguished) while on a way goes back to selecting a way node. If there was a previously remembered way node, that's the one that gets selected. Otherwise, it's index 0. What all this means is that you can navigate from any node or way to any other connected node or way entirely by keyboard: and while on a way, / to change ways at a junction. It's slightly clunky (mainly because you can't really tell which way is up or down for a given way until you try), but it works well enough to be useful. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Waynode-only map features
On Thu, Feb 3, 2011 at 11:46 PM, Andy Allan gravityst...@gmail.com wrote: On Thu, Feb 3, 2011 at 12:27 PM, Steve Bennett stevag...@gmail.com wrote: Also, are we perhaps reaching the point where not all node features should be dnd's? For example, I don't think dnd highway=turning_circle is particularly useful... Absolutely - there are also things that I'd like potlatch2 to recognise when selected (e.g. country nodes) without encouraging anyone to add more. We also have the issue that some of our point tags are inappropriate for pois - e.g. turning_circle should be an option for selectedwaynode but possibly not for selectedpoinode - but the whole distinction between nodes and ways on one hand and pois, points, lines and areas on the other is a little bit confused in p2 at the moment. I've done the first part of this - you can't drag-and-drop turning circles any more. See http://trac.openstreetmap.org/changeset/25270 Any preferences for how node vs waynode distinction should work? Should node always imply waynode (but not vice versa?) How about: Option 1: waynode Option 2: point wayrequired=yes Presumably either way it would also imply that draganddrop=no. Incidentally, is there a particular reason that map_features uses point/line/area terminology, rather than node/way/area? I'd be happy to convert it, if not. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] What do the new cycleway values mean?
On Thu, Feb 3, 2011 at 9:31 PM, Dave Stubbs osm.l...@randomjunk.co.uk wrote: Segregated cycle path: A path where cyclists and pedestrians are separated by a painted line or kerb. Sounds an awful lot like cycleway=track to me. Shared cycle path: A path where cyclists and pedestrians share the full width of the path. That's what we, in Australia, call a bike path and tag highway=cycleway, foot=designated, bicycle=designated. Added by Shaun in December to get more accurate cycle path information for routing purposes (e.g. CycleStreets) That's all well and good for CycleStreets, but I'm iffy about having it in an international edition of Potlatch. It makes choosing the right cycleway tag absurdly difficult. Another issue here...why is a path where cyclists and pedestrians share the full width of the path an option on a *road*? Is it implying that in addition to the road, there is a parallel shared bike path? Eck...very unintuitive. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] What do the new cycleway values mean?
On Thu, Feb 3, 2011 at 10:35 PM, Andy Allan gravityst...@gmail.com wrote: On Thu, Feb 3, 2011 at 9:58 AM, Richard Fairhurst rich...@systemed.net wrote: I think it's worth being cautious on adding things purely based on their %age occurrences too - without checking how many people vs 1 automated import have created them, whether they are rendered or something else is, even whether they make sense. Editorial judgement is required here. Yeah, I've looked to taginfo in the absence of other information about the tags. I'd quite like Potlatch to play a role in promoting good tag usage. If a proposed tag has strong community support, presumably we would want it implemented in Potlatch before waiting for numbers in taginfo. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] What do the new cycleway values mean?
On Thu, Feb 3, 2011 at 10:35 PM, Andy Allan gravityst...@gmail.com wrote: Who would like to see some judgement used in picking icons for the dnd panel, mutter mutter! Do tell? I'm probably guilty of whatever the crime is. Do you mean that the icons just look bad together (all different colours) or that they're badly drawn...or what? Also, are we perhaps reaching the point where not all node features should be dnd's? For example, I don't think dnd highway=turning_circle is particularly useful... Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[Potlatch-dev] Ugly POI icons
On Thu, Feb 3, 2011 at 11:35 PM, Tom Hughes t...@compton.nu wrote: The places section has five (yes, five) completely identical icons. Whereas what it probably should be is one icon place with a drop down specifying the type. Is anyone interested in map_features supporting this kind of feature - one defined only by a key, not a key-tag pair? It would also be useful for various rail types. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Proposed filtered way-drawing mode - thoughts?
On Thu, Jan 27, 2011 at 11:58 PM, Richard Fairhurst rich...@systemed.net wrote: My (very) strong preference is not to introduce another mode or extra configurable options. That way lies JOSM. :) Wise words. So I'd suggest: because we already have it: it's simply a custom stylesheet. As long as you don't include a !:drawn rule, then the offending items simply won't show up. The new @import syntax means there's no need to reinvent the wheel for most of it. There's already support for assigning keypresses to stylesheets. Ah, yes. That had occurred to me but I wasn't sure the language is quite expressive enough. Is it possible to have a rule that does if nothing has been drawn, and this way has a tag which is not one of the following, then draw as follows? The hard thing about this task is expressing not does it have X tag but does it have *only* tags from Y set. I guess as a fallback it wouldn't be too painful to whitelist the top 100 or so popular keys. Are you also assuming here that there would be something like potlatch-no-boundaries.css which imports potlatch.css, then does some extra stuff? I'll need to get more familiar with classes and :drawn. (Excuse my thinking out loud...) We have an awesome stylesheet engine (even if I do say so myself) - let's use it. Indeed. :) Would it be worth considering a way to indicate draw this, but make it non-interactive? Incidentally, http://wiki.openstreetmap.org/wiki/MapCSS still says that @import is not supported. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Proposed filtered way-drawing mode - thoughts?
On Fri, Jan 28, 2011 at 5:32 AM, Andy Allan gravityst...@gmail.com wrote: I think that would be useful, but I'll leave the syntax to others. I lean strongly towards always showing data in Potlatch, since every object can be transmorgified into a different type of object. For example, if you are hiding certain things (e.g. rivers) there's nothing stopping you from changing a road into a river and it then disappearing, or forgetting that you've hidden certain things and adding duplicates. Yep. I think a style that indicates this is some object you've elected not to care about would be the way to go. (Or, at least, one way to go) In saying that it's always worth remembering that Halcyon, and MapCSS too, are general purpose tools. I sometimes end up coding things that are a little to potlatch2-specific into them! Yes...but if MapCSS is a general purpose tool for editors and renderers, then having features useful to one but not the other should be fine, right? Incidentally, http://wiki.openstreetmap.org/wiki/MapCSS still says that @import is not supported. Wiki found in inaccuracy shocker! :-) I was waiting for the SOFIXIT. :) I haven't actually tested the @import feature so I don't know if it has any limitations or whatever. But yer. Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] CSS @import
On Mon, Jan 24, 2011 at 8:01 PM, Richard Fairhurst rich...@systemed.net wrote: In particular, it'd be great to use this so we could have two core stylesheets: a Standard one and an Enhanced one. Would you mind explaining a bit what the original thinking behind multiple stylesheets in Potlatch 2 was/is? For example, there is an OpenCycleMap stylesheet, but although I'm keenly interested in mapping bike paths etc, I've never felt compelled to use it. Is it intended for performance, or improved usability...? If there is a trade-off between elaborate styles and performance, then maybe the user wants to see it presented as options: Core styles + elaborate cycling stuff - fancy POI icons + elaborate road types Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Setting up Adobe Flex project
Err, in case the previous was confusing, when I say Adobe Flex I
mean Adobe Flex Builder 3.0.2. (Also, does this violate the rule
about not using Flex SDK 3.2?)
On Sun, Dec 12, 2010 at 11:55 AM, Steve Bennett stevag...@gmail.com wrote:
Hi all,
I've never used Flex (or done Flash development for that matter)
before, so please bear with me. I've been happily compiling P2 from
the command line with the SDK, but thought I'd give the IDE a burl.
There don't seem to be any project files in the SVN. So, what's the
best way to set up a Flex project using the existing P2 source files?
Also, since I'm on the topic, to build with ant from the commandline,
I had to add these two lines to the top of build.xml:
property name=FLEX_HOME value=${env.FLEX_HOME}/
property name=ASDOC value=${env.ASDOC}/
I'm surprised that it builds for anyone else - or maybe FLEX_HOME gets
directly to ant by the Flex IDE?
Steve
___
Potlatch-dev mailing list
Potlatch-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Source key and map_features.xml
Hi Richard, Let me say up front that I'm more than happy to be picked on :) I'm not precious about my ideas, so if they're wrong, please demolish them as fast as possible. Since writing my original message I did a bit more reading about the source tag, and I guess it's a bit more optional than I'd thought. And, yes, given the B key, maybe I was over-reaching a bit. It my reflect my Wikipedia bias, where source is everything. Ed's idea of an automatically-set changeset tag is potentially a useful one. Not to be called source=, because having a background open doesn't mean you're actually copying from it (I usually have one open just for context, but do most of my mapping from GPS traces). Perhaps background_open=. It shouldn't be too difficult to populate this with all the backgrounds used in the changeset. Could I humbly point out that if changesets are going to be given this importance, they're going to need a proper interface: the user will need to be able to manipulate changesets, revisit old ones, and have certainty about what changeset is currently open. The GUI should probably also hint that it's time to close one etc. Personally, I've never paid the slightest attention to them. One problematic trait of OSM (and I'm certainly not picking on you here Steve, many many people are a million times more guilty :) ) is people's belief that everything can be solved through code, and in particular, by editors insisting on/preventing certain things. I do have a belief that what people do on a computer is shaped to a large extent by the user interface they're working in. GUIs that make the socially correct behaviour easy and the socially less desirable behaviour hard are a good idea. But I agree that the knee-jerk suggestions one often sees (show an alert if x! prevent the user doing y!) fall a long way short of that ideal. I'd also say that good UI design is really, really hard, and that's why most open source projects do it so badly. There just aren't the resources to spend on it. If only. It's an abdication of the community's responsibility to write some decent, enticing docs, which it has so far completely failed to do in six I don't think the model of go rtfm, then come back and drive the gui like a guru is going to work. But good quality documentation, policy etc that can be embedded directly in context-sensitive help would be great. The recent work on taginfo is a big step in the right direction - having a single knowledge base that flows into design decisions in editors, renderers etc. years. As we've seen with changeset comments, insisting on them doesn't mean you always get useful ones. Rather, it means those who'd add them anyway add them; those who wouldn't write nothing, or ..., or Fixed Stuff, or Fuck you. Of course. The way to get good changeset comments is to make them valuable to the user. The community needs to help the new mapper understand why, and when, source tags are important. Forcing newbies to fill in something they don't understand just doesn't work, sadly. To be clear, I wasn't advocating forcing anything. And I agree with your philosophy. Something I'm hoping to do in the medium term is give people the ability to choose from pre-defined tag preset files, just as you can for backgrounds and for stylesheets. Then if you want an advanced mapper's speedy toolkit with source instantly accessible, you can have it; if you want a million shades of access tags, you can have it; yet P2 can still provide the new mapper with a simple, comprehensible default. Is such a level of customisation warranted? These kinds of things seem to very rapidly lead to huge amounts of confusing choice with debatable value. Then you have dozens of unmaintained, broken (because they didn't get updated to the latest format) tag preset files to choose from... (Anyway, that's just a mooted future feature I guess so I'll wait till I see it. :)) Steve ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
