[OSM-dev] [OSM-talk] osmeditor2 and JOSM

[Immanuel Scholz]

Hi Nick,

some comments about your ideas ;-)

> - direct communication with GPS, removing the need for GPSBabel.
> There is apparently an open-source (LGPL) JAR for serial GPS communication
> (see http://www.tegmento.org/gpsylon/#gpstool)
>  making this feasible.

Uhm, if you speaking of life import from GPS while it is recording, and
displaying the result directly on screen, this could be difficult. If you
really want to try this, I recomment implementing a special Layer for this
(subclass Layer or RawGpsLayer, whatever fits better) which holds the
imported data in a seperate data storage and only after the user clicks
some stuff (maybe a menu item in layer submenu) the so-far imported data
get merged into the main dataset. This way you circumnavigate all problems
with concurrent access to your data while it is imported.

If you just planning adding an off-line import from the GPS device, hook
yourself somewhere into the Open action or copy it and make an own import
action (if the library in mention does not access your GPS file system
like).


> - remove the need for people to know about Map Features, with a drop-down
> selectable list as in osmeditor2.

Err? I thought I made the annotation preset feature precisely because of
this...

You select some stuff, choose your most loved tag-set from the annotation
combo box and voilá --> new POI.
(You noticed, that you can specify annotation presets without any user
interaction boxes which then will immediatly get applied without an dialog
popup, right? ;)


> - an optional display style where ways are rendered in different colours
> according to type, as in the slippy renderer, osmarender, Freemap or
> osmeditor2.

Look for SimplePaintVisitor, copy this and reimplement the drawing stuff
in your most loved way. Then hook it in, as example by choosing the actual
painter from a preferences property (e.g. like I did it with the
LookAndFeel or Projection in class Main). When that's finished, insert a
property for that in the preferences dialog, like for the Look and Feel.


> - show POIs as icons (as per the slippy renderer, osmarender, Freemap,
> osmeditor2)

Should be possible with the own-made painter too.


> - Landsat, particularly for estimating areas.

There is a start of a landsat background image layer, but I didn't
finished it. The biggest problem arrised to me was that I did not wanted
to query the landsat server on every single move/zoom for the whole screen
again, but meaningful caching/tiling seemed not that trivial with a free
zoomable/scalable map...

Maybe you better start over and ignore the WmsServerLayer class completly...


> Any UI design/usability ideas would be very useful, as I think others are
> stronger in this area than I am.

HA! One advice from me: DON'T LISTEN TO ME!
At least when it comes to user interface. Most of my assumptions of my
users out there proved wrong ;-)

Anyway, I plan to change the global idea of user interaction with JOSM
dramatically in the future. The general shifts will be:

- moving away from many mapmodes that can few things to few mapmodes that
do many things (dependent on context). As example, there is no need for
switching to a seperate select-mapmode, you should just be able to select
by dragging an area in one "smart" mapmode. Also moving objects can be
done by dragging over an already selected object (hinted by the cursor
turns into a hand symbol), as it is standard with almost any design tool
I've seen (except XFig).

- provide a context menu on right mouse button clicks. Moving the map with
the middle button instead (or alternativly by pressing some key... maybe
Ctrl - haven't decided). The current middle mouse button tooltip will be
the normal tooltip when waiting for some seconds without doing anything.

- dramatically exploit the ideas of searching and bookmarking. I like to
have a search field in the upper toolbar, where you can search for almost
any stuff and JOSM jumps to this place, selecting the hits. Also, placing
user defined bookmarks (= selections of objects with a name) should be
easy, intuitive, searchable and shareable with others.


> We could then offer a fairly straight choice of editors for users,
> Potlatch or JOSM, which should cover most needs.

What is Potlatch? (Except of beeing an native american ritual)


> Given the quite large number of users who want to use a 100% Open Source
> environment, it would also be of benefit to make it compatible with GNU
> Classpath or other open source Java VM.

GNU Classpath is not a VM, but an implementation of the standard library.
I recommend looking at ECJ as a VM together with Classpath (CVS version
for Java5), since has the best support for Java5. GCJ is also worth
looking on, although still somewhat instable.

If you plan to use "retroweaver" to make the JOSM .class files compatible
with 1.4, remember that this would be great news for Macintosh OSX 10.3
users but does not help much for the Freedom-guys, because I doubt that
this will run better with Classpath. ;-)

Ciao, Imi