You are not logged in.

#1 2014-02-20 21:35:56

Fernando Trebien
From: Porto Alegre, Brazil
Registered: 2013-05-18
Posts: 888

Good reasons to avoid Potlatch

Hello everyone,

I've decided to translate my own post in the Brazilian forum. It was written in a moment of intense frustration, but I hope it is received as positive criticism and that it disseminates awareness of the issues. In fact, for a long time I've been in full favor of taking Potlatch off of the main website, since we now have iD.

Edit: as I've learned that there's no intention to make Potlatch unavailable, I'd only like to say: it does not matter to me if it stays on, as long as the following issues are better addressed.

Fernando Trebien wrote:

Hello folks,

One year ago I abandoned Potlatch and the program is still facing the same troubles. I'm writing this as a warning for the [Brazilian] community and also as criticism because the issues are well known but will never be addressed.

My first example is a problem introduced in Brasília a few days ago. Let me start by stating one opinion clearly: it was NOT the user's fault. The way I see it, Potlatch suggested that his mapping was correct.

It all begins at this junction.

REASON 1: the editor does not lead the user into mapping turn restrictions correctly

The user had removed the restrictions I had added and replaced them with his own, but he/she forgot to fill in the From and To boxes. The user could have done it this way:
1. First, the user would have clicked the intersection point and would have defined that there is a turn restriction there. So far so good, this is what the user did.
2. The left panel then indicates there is a restriction and a restriction icon shows on the map at that point. To the user, that seemed enough, so he/she didn't go further. But it is not enough: one must fill in the From and To fields, which were empty. How could the user have known it if the program does not indicate he/she should have done that? There's another problem: these streets have no name (in reality, they often don't), so instead their ID is displayed. But how does one find this code? It is not obvious. One more thing: when the streets do have a name, the situation can be worse: as both sides of a crossing street almost always have the same name, the user may think that either is ok (after all, the name is right, right?), so he/she may not care to check the ID.
3. The first thing to do is click one of the ways that should participate in the relation.
4. The user must then enter the Advanced pane by clicking at the bottom corner of the left panel.
5. Then, at the very top corner, without any highlight, we find the way and its ID. "Yay, I'm feeling lucky! Now all I need to do is memorize this number!"
6. Back to the intersection point, within the Simple pane.
7. If the user still remembers that number, he/she may finally fill in one of the fields.

Now all the user needs to do is repeat the whole process to fill in the second field. Hm.


Further south, I've remapped the restrictions. This is how they should appear in Potlatch when they are complete and correct:

Maybe the user could have avoided this problem if he/she had realized he/she could visualize the structure of the restriction by clicking Show right beneath it:

But don't you agree that it is not so obvious [with so many other buttons nearby and an unclear need to fill in the From and To fields]?

I think the worst part of it is that even experienced Potlatch users would have no means to edit this restriction more quickly. By comparison, in JOSM using the turnrestrictions plugin, the recipe is much simpler:

1. Select the intersection point
2. Hold Shift and select the entering way
3. Keep holding Shift and select the exiting way
    (holding Shift adds new things to the selection, the order of adding is important in this case)
4. Click the button Create a new turn restriction in the panel Turn Restrictions (which can be enabled in Window > Turn Restrictions after installing the plugin in Preferences > Plug-ins)


5. Finally, a dialog is displayed in which all one usually needs to do is choose the right type of restriction, which in this example is "Only Straight On". Selecting the From and To ways is not necessary because they are already filled in the order they were selected.


REASON 2: restriction relations become inconsistent when splitting lines that participate in them

This is an old issue. Let's see what happens with this restriction when we split one of its members:


Restriction 3523410 now has two "from" members. This is inconsistent and breaks most systems that rely on OSM for routing.

So how could the user have figured this if the program is not telling him? [I'm not keen to recommend "check the new ways for relations every time you split them".]

REASON 3: not understanding multipolygons and other elements that have been around in OSM for quite a long time

Look how this area is rendered in the main website. If one edits it with iD, this is shown:


If one edits it with Potlatch, it would be this:


"What are these 3 thin black lines?", the user would think. Particularly, what are that black line going along the sidewalk and the other one along the axis of the dual carriageway? "Hm, I'll click them to see if I can find out." As the bottom image shows, Potlatch indicates Unknown, leaving the user perplexed. If the user is not paying enough attention, he/she may skip the small text right below (which I highlighted but has no particular highlight in Potlatch), and then the user may (and often will) think someone has mapped this thing incorrectly and will feel tempted to delete that line.

Going further: the small text contains "low level" OSM notation (referring to kinds of elements, kinds of relations, and names of tags), but Potlatch was made precisely to avoid going deep down these details. As a result, we cannot expect the user to know what this text means, unless the user is already well aware of OSM's internals. Similarly, we cannot expect the user to understand what appears inside the Advanced pane, which is where the user is led to when he/she clicks edit (an unnoticeable action link within that text).

REASON 4: no alerts when deleting relation members

In the previous case, the thin black line makes up the bounds of a big park. Believing the line is useless, or believing that the park was mapped incorrectly since every other park ever seen looks like a pretty green polygon, the user finally decides to delete that line. Absolutely no warning is given. At this point, the multipolygon representing the park becomes an open area with a missing bounding member. Information has been lost, and in no way we can expect that the user knows he/she had done any damage.

Confusion is even bigger when handling (suburb) limits that use streets as members. See this example:

"Why on Earth is 'Rua Porto Calvo' painted differently in different pieces?" Answer: because one of its pieces is a member in a boundary relation. But the user does not know that. Unless, of course, the user already knows OSM in depth.

"Every other street is a single 'thing', so maybe I should fix this." The user selects both ways, clicks the chainlink icon to combine them, and the result is *drum roll* a malformed boundary relation with an open corner that connects to nothing. I've seen things like this happening to state boundaries, resulting in errors that were hundreds of kilometers long.

In case the user didn't notice that briefly shown, almost camouflaged pop-up at the bottom of the screen saying something about check relations ("what is that? oh, whatever", there's no explanation after all), he/she simply goes on. "Hm, it's not yellowish as I wanted. Oh, I know what to do! I'll undo what I did, then I'll delete the brown piece and draw the yellow over it! I'm so smart!" Needless to say, the suburb multipolygon will end up with an open side.

User's fault? I'm convinced it is not.

Easy to fix? It depends. In some cases, it takes minutes (if not dozens of minutes) to confirm what is the correct limit and roll back to the previous normal situation.

Why I am talking about "not alerting when combining" along with "not alerting when deleting": because combining always involves deletion. You have two lines, A and B, and by combining them, one of the two (say B) is deleted and the other one (A) is extended incorporating B's points. A becomes A+B, and B disappears.

This is just a warning about what I see Potlatch users doing here and in other regions of Brazil. AVOID IT! iD and JOSM are far superior [when it comes to usability].

Note for international users: I believe this problem is not restricted to Brazil (I don't think there's any reason to think that Brazilians are "dumber" in any way). It should affect any country, and it probably happens most often with users that are not so computer literate or technologically inclined, since figuring these details out requires understanding how the program works.

Let me quote-translate some of the feedback I've got so far:

Nighto wrote:



Just to be clear, I believe that means "a thousand times +1".

Nighto is one of the most involved users (if not most of all) in Rio de Janeiro.

naoliv wrote:

If anything has been irritating me a lot lately is reason 4 (both for iD and Potlatch). It makes me tired to keep fixing broken administrative boundaries because the user has deleted something and received no warning.

naoliv is one of the most involved users (if not most of all) in São Paulo.

In fact, iD suffers from the same problem as in reason 4, but not the others, so it is already much better. An elaborate fix has already been proposed, but something much simpler (as a warning on any situation) would already be much better than allowing loss of information (which, to me, means loss of contributor time and loss of map quality and reliability).

Last edited by Fernando Trebien (2014-03-02 04:29:33)


#2 2014-02-20 23:08:34

Fernando Trebien
From: Porto Alegre, Brazil
Registered: 2013-05-18
Posts: 888

Re: Good reasons to avoid Potlatch

I've got some some feedback that there's no intention to make Potlatch unavailable, so this makes these issues a bit more urgent to me. If anyone agrees, please help request better handling of these situations at Potlatch's issue tracker.

Last edited by Fernando Trebien (2014-02-20 23:08:55)


#3 2015-06-02 15:08:07

Registered: 2015-06-02
Posts: 2

Re: Good reasons to avoid Potlatch

Good summary and I agree with you about some of the issues with P2. Fortunately, Potlatch isn't the default editor any longer so new users are not too likely to be presented with it. Yes, it would be great if these issues could be fixed and/or iD editor could be made available to those using Internet Explorer.

Personally, I use Potlatch2 simply because I find iD too restrictive and JOSM requires Java which I've eradicated from my household over 2 years ago. Although Potlatch requires Flash which carries its own security issues, they're easier to contain than Java. Flash plugin can be restricted to the browser and by using a browser like Firefox and NoScript, Flash can be restricted to specific websites only, essentially sandboxing the plugin. I use HTML5 video for YouTube these days so Flash is only active on


#4 2015-06-02 15:21:31

From: Germany
Registered: 2008-06-17
Posts: 2,763

Re: Good reasons to avoid Potlatch

Dascombe wrote:

Personally, I use Potlatch2 simply because I find iD too restrictive and JOSM requires Java which I've eradicated from my household over 2 years ago.

There are very little reasons to eradicate Java from one's household. The Java browser plugin should be disabled, sure, but that has nothing to do with Java desktop software such as JOSM.

OSM in 3D: OSM2World


#5 2015-06-02 17:11:07

Registered: 2015-06-02
Posts: 2

Re: Good reasons to avoid Potlatch

Tordanik wrote:

There are very little reasons to eradicate Java from one's household. The Java browser plugin should be disabled, sure, but that has nothing to do with Java desktop software such as JOSM.

It's just another piece of software that has a history of security vulnerabilities that needs to be kept up to date. The worst part is that when updated, it automatically re-enables the browser plugin (at least it used to when I had it last installed). The overwhelming consensus is that unless you need Java, it's best to simply uninstall it. To me, Java is past its expiration date at the home PC level. Lastly, for too many reasons to discuss here, I just don't like Java as a programming language.

I don't have much love for Flash either and if not for Potlatch, I wouldn't have it installed on my laptop (it's not installed on my desktop). Unfortunately, the wife's laptop can get by without Java just fine, but she needs Flash. Firefox and NoScript I trust to control things more than Oracle's ability to keep their patches coming in a timely manner.

Anyway, this is getting off topic now; sorry for the derail.


Board footer

Powered by FluxBB