[OSM-talk] Suggestion for JOSM

[Ævar Arnfjörð Bjarmason]

On Mon, Nov 2, 2009 at 12:48 PM, Richard Fairhurst <richard at systemed.net> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>>
>> On Mon, Nov 2, 2009 at 8:12 AM, Richard Fairhurst<richard at systemed.net>
>>  wrote:
>>>
>>> I would commend this forced simplification to the JOSM devs. Ways are
>>> automatically split after an interval of n seconds.
>>
>> Unlike Potlatch JOSM is a powertool. It shouldn't force you to do
>> anything.
>
> ...is a very high-minded principle which nonetheless leads to some lousy
> edits in the database.
>
> I would have a bit more sympathy had I not, once again, spent a good while
> last night clearing up some ways, badly traced in JOSM with 45-degree angles
> all over the place. Had the mapper used a good "GPX->simplified way"
> function, he would have created a road which was much closer to reality yet
> nonetheless took him much less effort.
>
> It's the responsibility of the tool developer to lead the user to the right
> choice. Glib phrases like "unlike Potlatch JOSM is a powertool" (I note JOSM
> #67 is still open :p ) don't absolve responsibility for UI design. By all
> means offer the choice, but make the 90% case the default.

I have nothing against good UI design which would make this sort of
thing easy. Doing this in JOSM currently is much harder than it should
be. What I usually do when I want to do this is:

 1. Import the GPX track
 2. Convert it to OSM
 3. Split up the bit I need & select it
 4. Search for "-selected" to invert selection
 5. Delete (nukes all the bits I don't want
 6. Merge to main datalayer
 7. Manually connect the track to other roads
 8. Manually clean it up (e.g. getting rid of self-intersections)
 9. Maybe simplify it. But sometimes the automatic utilsplugin
simplify process sucks so I'd rather do it myself

1-8 should be made easy, but I disagree with you that JOSM should
force some simplification process. I've already cited an example where
this did more harm than good.

Perhaps the utilsplugin can be improved to use a better algorithm or
have a way to configure the amount of simplification that it does, but
there will always be cases where the software does stupid things and
I'd rather not have to edit the source code for my editor & recompile
it because someone thought his algorithm was so smart that it knew
better than its users in all cases.

That is all.

>> We would do well to remember that not everyone wants to spend an hour
>> to perfectly trace some way in the middle of nowhere. Sometimes
>> importing an almost raw GPX track is quick, good enough and perfectly
>> appropriate.
>
> Yep. Exactly my point. The challenge for the developer is to balance "not
> everyone wants to spend an hour" and "_almost_ raw" (my emphasis), and in
> this area I think Potlatch gets it about right. <mandy rice-davies>Though I
> would say that, wouldn't I?</mandy rice-davies>

I certainly agree that for this case Potlatch's UI is way superior for
the common case.