[OSM-dev] JOSM plugin public transport update (Google Summer of Code program)

Roland Olbricht roland.olbricht at gmx.de
Tue Mar 18 18:13:03 UTC 2014

Hello Markus,

I'm sorry for the delayed answer. I'm currently preparing my talks on the 
FOSSGIS conference (German version of SotM) and this took much more time than 

> I thought about algorithm guessing connection type based on:
> - common tags on ways that contain selected nodes

This is really smart. It would avoid most of the time bothering the user.

> - what type was previously selected (i.e. if a user had selected a type X
>   in the past, then this selection will be assumed as more likely the next
> time)

Also a good idea although I would see this rather as choosing which item to 

> Some types would be predefined. There would be possibility to edit existing
> and add more.
> A connection type would have:
> - name
> - icon (not sure, requires testing whether it would be helpful)
> - set of data about tags that would identify ways that can be included
>     - tags that must appear
>     - tags that indicate this route type
>     - tags that should not appear and indicate that it is not this type
>     - tags that must not appear

Additionally, features with certain tags could and should block routing even 
if they just cross the path without sharing a nnode. Think of a gate 
(barrier=gate or a military no-go area).
> I like this idea, but is it big enough to qualify as entire project?
> Maybe yes, especially after considering that things often are harder than
> expected and take far more time than it seemed at start.

Yes, it is big enough. It is more more meritful to arrive at a useful piece of 
code first and then do one or more exciting features on top than a monolithic 
goal that could (and then, by Murphy's law, will) fail completely.

> In this project I see following parts
> - creation of ticket on JOSM bugtracker (I am not expecting this, but in
>   case that JOSM developers reject the entire idea I would instead create
>   plugin with this functionality).
> - collecting use cases (two nodes + what ways would be expected to be
>   found by algorithm)
> - setting up development environment, with ability to build JOSM
> - interface (new position in tool menu, icon, fetching data about what is
>   selected, error messages)
> - algorithm that will find suitable connection (probably A* with cost
>   functions)

- Deal with various tagging variants.
- Deal with features intersecting without nodes when they should block 
- Make a proper handling of implicit way splitting (may require user action, 
but the less the better. Users wouldn't accept to click through hard-to-
understand and possibly multiple modal windows).
- Make a proper Undo (This one being particular important)
- Maybe cope with runtime and/or space constraints

> Subsequently I would add handling of connection types
> - fixing bugs reported by user, encountered in released version
> - modification of algorithm (multiple A* searches? Maybe something
>   smarter and faster would be needed.)
> - interface (selecting connection type)
> - loading user-defined connection types in reasonable and editable format
> - definitions of some obvious types

- Making a user interface to handle user-defined connection types, might be a 
quite large sub-editor).
- Fitting that into the various JOSM storage ideas (File format, storage in 
the central JOSM wiki repository, store in local user preferences).

- Probably i18n for the interface parts.

- Find sensitive testing case and defend the whole thing on various community 
mailing lists (I will assist you, but it is inevitable to meet the real needs 
of various local comunities, and inevitable to make the software really 

> At this point it should be already useful for many tasks and faster than
> configuring filters to select linear feature consisting of multiple ways.
> It would depend on how JOSM developers would see it, but it could be
> at this stage merged into JOSM trunk (in case of backup plan I would
> release a plugin).

I think it would be helpful to first have it as a plugin and see it in action. 
This allows to proof it has proper encapsulation for the other code parts. 
That has proven in the past very useful for code maintenance and is therefore 
common for new and significant improvements).

> Is there anything that I missed here? Is my plan realistic (GSoC coding
> starts on 19 May and finishes on 11 August)?

Yes, I'm confident that this will work. I'll have a closer look at your 
proposal in the train tomorrow and then comment as soon as I found my Wifi on 
the conference venue :)



More information about the dev mailing list