Re: [Potlatch-dev] Status of potlatch2 development?

2013-02-19 Thread Steve Bennett
On Tue, Feb 19, 2013 at 6:39 AM, Richard Fairhurst wrote:
 So, the question is: what purpose does P2 serve when iD is live and the

 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 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 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, 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:


It fixes a centroid calculation bug. You can very quickly verify that
it works and doesn't catastrophically fail.


This will not unduly tax your cerebral resources.


Stylistic considerations aside, this is an easy one.


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

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 repository

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?

2013-02-09 Thread Steve Bennett

No active devs left on this list? Did everyone move to iD?


On Tue, Jan 29, 2013 at 10:01 PM, Steve Bennett 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?


Potlatch-dev mailing list

[Potlatch-dev] Status of potlatch2 development?

2013-01-29 Thread Steve Bennett
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?


Potlatch-dev mailing list

Re: [Potlatch-dev] Outstanding pull requests (Attn Richard F)

2012-07-18 Thread Steve Bennett
On Tue, Jul 17, 2012 at 9:52 PM, Richard Fairhurst 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, 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.


Note the broken formatting, lack of whitespace, and minimal comments.


 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

Speaking of which, here's another pull request I didn't mention earlier:

From memory, that was something like 15+ hours work - completely
ignored. Meaning bad data continues to be created in the OSM database.
( )

Is it unreasonable to expect quicker responses?


Potlatch-dev mailing list

Re: [Potlatch-dev] Outstanding pull requests (Attn Richard F)

2012-07-17 Thread Steve Bennett
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.


On Tue, Jul 17, 2012 at 5:27 PM, Richard Fairhurst wrote:
 On 17/07/2012 04:30, Steve Bennett wrote:

 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


 Potlatch-dev mailing list

Potlatch-dev mailing list

Re: [Potlatch-dev] Magic Roundabout v2

2012-05-17 Thread Steve Bennett
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?


On Sun, Mar 18, 2012 at 3:20 PM, Steve Bennett 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.

 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.)

 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, 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #4395: Potlatch2 creating one node ways

2012-05-08 Thread Steve Bennett
On Tue, May 8, 2012 at 8:11 AM, OpenStreetMap wrote:
  Please read the How to be a helpful bug reporter paragraph on the first
  page of 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #4395: Potlatch2 creating one node ways

2012-05-08 Thread Steve Bennett
On Tue, May 8, 2012 at 5:40 PM, Frederik Ramm 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;. 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 describes at least one
reproducible situation where single-node ways get created.

(No idea about your hypothesised reason for #4395 being created.)


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #4375: Potlatch 2: join nodes function creates duplicate nodes in ways

2012-04-26 Thread Steve Bennett
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.


On Tue, Apr 24, 2012 at 5:44 PM, OpenStreetMap 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.

  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:
 OpenStreetMap is a free editable map of the whole world

 Potlatch-dev mailing list

Potlatch-dev mailing list

Re: [Potlatch-dev] Brokenness on Mac with Flash 10.1

2012-03-26 Thread Steve Bennett
On Mon, Mar 26, 2012 at 5:42 PM, Richard Fairhurst wrote:
 Out of interest, Intel or PowerPC?

2.66 GHz Intel Core 2 Duo. 4GB 1067 MHz DDR3. OSX 10.6.8.


Potlatch-dev mailing list

Re: [Potlatch-dev] Brokenness on Mac with Flash 10.1

2012-03-26 Thread Steve Bennett
On Mon, Mar 26, 2012 at 5:09 PM, Tom Hughes wrote:
 Certainly not related because the new version hasn't been deployed on the
 main site yet!

 It''s only on 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.)


Potlatch-dev mailing list

Re: [Potlatch-dev] Weekend summary

2012-03-26 Thread Steve Bennett
On Mon, Mar 26, 2012 at 6:01 PM, Richard Fairhurst 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 in the next few days.

Live now, woot.


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #4298: Keyboard shortcut: Move to next selected node in a way

2012-03-16 Thread Steve Bennett
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

Re: [Potlatch-dev] State of play

2012-03-10 Thread Steve Bennett
On Sat, Mar 10, 2012 at 6:41 PM, Tom Hughes 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?


Potlatch-dev mailing list

Re: [Potlatch-dev] Testing new versions

2012-03-08 Thread Steve Bennett
On Thu, Mar 8, 2012 at 7:12 AM, SomeoneElse 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 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

* 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

Re: [Potlatch-dev] More UX testing

2012-03-03 Thread Steve Bennett
On Sun, Mar 4, 2012 at 5:05 AM, Andy Allan 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?


Potlatch-dev mailing list

Re: [Potlatch-dev] Designation tag on most map features

2012-02-24 Thread Steve Bennett
On Tue, Feb 21, 2012 at 10:07 PM, Richard Fairhurst 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:

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


Potlatch-dev mailing list

Re: [Potlatch-dev] Designation tag on most map features

2012-02-19 Thread Steve Bennett
On Sun, Feb 19, 2012 at 11:20 PM, Richard Fairhurst wrote:
 In other words, wikifiddling is not an important criterion in whether a tag
 is included. 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.

Ok, so I can try and understand you, can you define this
wikifiddling you're so opposed to? I find your attitude utterly


Potlatch-dev mailing list

Re: [Potlatch-dev] Internationalisation

2012-02-19 Thread Steve Bennett
On Mon, Feb 20, 2012 at 5:38 AM, Richard Fairhurst 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.


Potlatch-dev mailing list

[Potlatch-dev] Designation tag on most map features

2012-02-18 Thread Steve Bennett
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:

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:

In the meantime, what can we do about it?


Potlatch-dev mailing list

Re: [Potlatch-dev] Internationalisation

2012-02-18 Thread Steve Bennett
On Wed, Nov 30, 2011 at 10:47 PM, Andy Allan 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Github, and tram/road issues

2012-02-16 Thread Steve Bennett
On Thu, Feb 16, 2012 at 8:11 PM, Andy Allan wrote:

 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 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?


Potlatch-dev mailing list

[Potlatch-dev] Github, and tram/road issues

2012-02-15 Thread Steve Bennett
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:

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] What happened to the Natural category?

2012-01-09 Thread Steve Bennett
On Mon, Jan 9, 2012 at 8:57 AM, Charlotte Wolter 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
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

Seems pretty reasonable. The actual tag is ford=yes, so it would be a
separate checkbox. Btw you can add requests here:

And can we add intermittent under the Water category?

For anyone implementing this, the tags are intermittent=yes or seasonal=yes.


Potlatch-dev mailing list

Re: [Potlatch-dev] Git starter?

2011-09-03 Thread Steve Bennett
On Thu, Sep 1, 2011 at 2:34 AM, Andy Allan 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

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Git starter?

2011-08-31 Thread Steve Bennett
On Wed, Aug 31, 2011 at 5:01 AM, Andy Allan 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 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.

svn commit

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #3562: Make dragging unselected POI do select pan

2011-07-18 Thread Steve Bennett
On Tue, Jul 19, 2011 at 2:29 AM, OpenStreetMap 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #3836: potlatch2.2 locks up, unable to save edited data

2011-06-21 Thread Steve Bennett
On Tue, Jun 21, 2011 at 7:46 PM, Richard Fairhurst 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


Potlatch-dev mailing list

Re: [Potlatch-dev] Potlatch 2 stylesheet changes

2011-06-16 Thread Steve Bennett
On Mon, Jun 13, 2011 at 5:40 AM, Richard Fairhurst 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?


Potlatch-dev mailing list

Re: [Potlatch-dev] New docs

2011-03-18 Thread Steve Bennett
On Fri, Mar 18, 2011 at 12:20 PM, PierZen wrote:
 Richard, as you said, the vmatch does the job perfectly with assigning the
 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

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Codebase and git

2011-03-18 Thread Steve Bennett
On Wed, Mar 9, 2011 at 6:25 AM, Andy Allan 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...


Potlatch-dev mailing list

Re: [Potlatch-dev] HOT Potlatch2 presets

2011-03-14 Thread Steve Bennett
On Tue, Mar 15, 2011 at 1:53 PM, Pierre (PierZen) 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
 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

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
icon image=features/hot.png/
icon image=features/hot.png/
inputSet ref=HOT Source /

Maybe the problem is some kind of XML QA issue like these?


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #3567: Add ability to create a no_u_turn restriction with a way via

2011-03-08 Thread Steve Bennett
On Tue, Mar 8, 2011 at 7:44 PM, Ed Loach 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.


Potlatch-dev mailing list

[Potlatch-dev] I wrote some overview documentation

2011-03-05 Thread Steve Bennett


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #3360: Switching backgrounds doesn't respect Dim setting

2011-03-05 Thread Steve Bennett
Thanks Ed, with that description it was actually quite easy to fix.


On Sun, Mar 6, 2011 at 5:17 AM, Ed Loach wrote:
 I'm back at my keyboard now. And on the live site I reproduce the problem as 

 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?


 -Original Message-
 From: Ed Loach []
 Sent: 05 March 2011 16:44
 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
 Sent: 05 March 2011 15:28
 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


  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

 Ticket URL:
 OpenStreetMap is a free editable map of the whole world

 Potlatch-dev mailing list

 Potlatch-dev mailing list

 Potlatch-dev mailing list

Potlatch-dev mailing list

[Potlatch-dev] What to code next?

2011-03-03 Thread Steve Bennett
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

I'm also open to non-coding requests like mapcss, map_features, or


Potlatch-dev mailing list

Re: [Potlatch-dev] Codebase and git

2011-02-28 Thread Steve Bennett
On Mon, Feb 28, 2011 at 8:31 PM, Richard Fairhurst 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;...


Potlatch-dev mailing list

Re: [Potlatch-dev] Introducing Magic Roundabout tool

2011-02-26 Thread Steve Bennett
 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

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.

 Create action X
 Add to main undo stack
  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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Introducing Magic Roundabout tool

2011-02-25 Thread Steve Bennett
On Fri, Feb 25, 2011 at 11:21 PM, Andy Allan 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

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.


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.

Potlatch-dev mailing list

Re: [Potlatch-dev] Introducing Magic Roundabout tool

2011-02-25 Thread Steve Bennett
On Sat, Feb 26, 2011 at 12:43 AM, Andy Allan 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:

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Introducing Magic Roundabout tool

2011-02-25 Thread Steve Bennett
On Sat, Feb 26, 2011 at 2:52 AM, Dave Stubbs 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

For example, passing a function to an operation, where the function
represents a storage operation for an undoable 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));


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)

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Introducing Magic Roundabout tool

2011-02-24 Thread Steve Bennett
On Fri, Feb 25, 2011 at 3:02 AM, Steve Bennett 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


Potlatch-dev mailing list

Re: [Potlatch-dev] Introducing Magic Roundabout tool

2011-02-24 Thread Steve Bennett
On Fri, Feb 25, 2011 at 6:20 AM, Andy Allan wrote:
 Unfortunately it doesn't compile - I think you added a length()
 function to but haven't added it in! Also,
 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] i18n using babelFx

2011-02-23 Thread Steve Bennett
On Wed, Feb 23, 2011 at 2:10 AM, NopMap 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:


feature name=Cycle path id=cycleway

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...


Potlatch-dev mailing list

Re: [Potlatch-dev] [OpenStreetMap] #3528: Grouping map features that share a top-level tag

2011-02-18 Thread Steve Bennett
On Mon, Feb 14, 2011 at 6:25 PM, NopMap 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

Ok, done:


Potlatch-dev mailing list

Re: [Potlatch-dev] What do the new cycleway values mean?

2011-02-18 Thread Steve Bennett
On Thu, Feb 3, 2011 at 11:32 PM, Andy Allan 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:

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).


Potlatch-dev mailing list

Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?

2011-02-16 Thread Steve Bennett
 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?

2011-02-16 Thread Steve Bennett
On Wed, Feb 16, 2011 at 10:24 PM, Richard Fairhurst wrote:
 I'm also a little aware (having optimised the CategorySelector stuff

Btw - awesome. :)


Potlatch-dev mailing list

Re: [Potlatch-dev] How about another build?

2011-02-15 Thread Steve Bennett
On Tue, Feb 15, 2011 at 10:36 PM, Andy Allan 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 ( but
didn't get around to checking it in. Cool. :)


Potlatch-dev mailing list

[Potlatch-dev] Suggestion for lifecycle tag - comments?

2011-02-15 Thread Steve Bennett
Hi all,
  Thought I'd solicit comments before implementing the following:
tag k=highway v=tertiary lifecycle=road/
inputSet ref=road_lifecycle/

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./

lifecycle id=road

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?


Potlatch-dev mailing list

Re: [Potlatch-dev] Suggestion for lifecycle tag - comments?

2011-02-15 Thread Steve Bennett
On Wed, Feb 16, 2011 at 9:41 AM, Andy Allan 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:


 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

to Road under construction, you'd actually get:

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?


Potlatch-dev mailing list

Re: [Potlatch-dev] Lat vs Latp

2011-02-13 Thread Steve Bennett
On Sun, Feb 13, 2011 at 10:59 PM, Richard Fairhurst wrote:
 In other words, latp-y co-ordinate is just a simple matter of
 multiplication, just like lon-x co-ordinate (in the Mercator projection, at
 any rate).

 If you didn't project it then things would look squished and you wouldn't be
 able to use tile backgrounds.

Ah, thanks. That explains why latp is used almost everywhere over lat.


Potlatch-dev mailing list

[Potlatch-dev] Short cut keys for node-by-node navigation

2011-02-13 Thread Steve Bennett
I just added some node navigation shortcuts in . 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.


Potlatch-dev mailing list

[Potlatch-dev] Waynode-only map features

2011-02-11 Thread Steve Bennett
On Thu, Feb 3, 2011 at 11:46 PM, Andy Allan wrote:
 On Thu, Feb 3, 2011 at 12:27 PM, Steve Bennett 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

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.


Potlatch-dev mailing list

Re: [Potlatch-dev] What do the new cycleway values mean?

2011-02-03 Thread Steve Bennett
On Thu, Feb 3, 2011 at 9:31 PM, Dave Stubbs 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] What do the new cycleway values mean?

2011-02-03 Thread Steve Bennett
On Thu, Feb 3, 2011 at 10:35 PM, Andy Allan wrote:
 On Thu, Feb 3, 2011 at 9:58 AM, Richard Fairhurst 
 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


Potlatch-dev mailing list

Re: [Potlatch-dev] What do the new cycleway values mean?

2011-02-03 Thread Steve Bennett
On Thu, Feb 3, 2011 at 10:35 PM, Andy Allan 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...


Potlatch-dev mailing list

[Potlatch-dev] Ugly POI icons

2011-02-03 Thread Steve Bennett
On Thu, Feb 3, 2011 at 11:35 PM, Tom Hughes 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] Proposed filtered way-drawing mode - thoughts?

2011-01-27 Thread Steve Bennett
On Thu, Jan 27, 2011 at 11:58 PM, Richard Fairhurst 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

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, still says
that @import is not supported.


Potlatch-dev mailing list

Re: [Potlatch-dev] Proposed filtered way-drawing mode - thoughts?

2011-01-27 Thread Steve Bennett
On Fri, Jan 28, 2011 at 5:32 AM, Andy Allan 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, 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.


Potlatch-dev mailing list

Re: [Potlatch-dev] CSS @import

2011-01-24 Thread Steve Bennett
On Mon, Jan 24, 2011 at 8:01 PM, Richard Fairhurst 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


Potlatch-dev mailing list

Re: [Potlatch-dev] Setting up Adobe Flex project

2010-12-11 Thread Steve Bennett
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 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?


Potlatch-dev mailing list

Re: [Potlatch-dev] Source key and map_features.xml

2010-12-05 Thread Steve Bennett
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

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. :))


Potlatch-dev mailing list