<div dir="ltr">> Having a<br>> tool that does the selection part according to a direct route would also be a<br>> help but might be more demanding - the acceptable features for waterways or<br>> railways differ from those for streets, and even for streets the subsets that<br>

> fits for buses differs significantly from the subset for cyclists. So the<br>> feature will require some clever user interface to handle this explanation<br>> challenge.<br><br>I thought about algorithm guessing connection type based on:<br>

- what type was previously selected (i.e. if a user had selected a type X <br>  in the past, then this selection will be assumed as more likely the next time)<br>- common tags on ways that contain selected nodes<br>- decision by user (this would be optional, there would be possible to<br>

  skip this in case when two previous items were sufficient.<br>  I imagine it as a messagebox that is not capturing focus and is <br>  appearing at the bottom of the screen. Something similar to <br>  box "You have X unread messages" recently added to JOSM).<br>

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

    - tags that must appear<br>    - tags that indicate this route type<br>    - tags that should not appear and indicate that it is not this type<br>    - tags that must not appear<br>    <br>Quick examples of types:<br>

- bus<br>    - must appear: "highway=*"<br>    - indicate: psv=yes, psv=designated, bus=yes, bus=designated<br>    - should not appear: highway=pedestrian<br>    - must not appear: highway=footway, highway=cycleway, highway=path<br>

      psv=no, bus=no, (access=no AND NOT bus)<br>      <br>- waterway<br>    - must appear: "waterway=*"<br>    - must not appear: waterway=riverbank<br><br>In general the biggest problem will be with various flavours of highways <br>

(at least bus, car and bicycle), other linear features rarely share <br>nodes and it should be easy to detect way based on what is the same on <br>two selected nodes (except some degenerated cases like selecting two <br>
nodes that are both railway/highway crossings, with the same rail and <br>
the same road).<br>    <br>> > This approach may make coding more complicated but it would solve far<br>> > more general problem.<br>> Having another selection aid for JOSM would indeed help even more. I you want<br>

> then you could also focus the project to this challenge and leave aside the<br>> tagging issues.<br><br>I like this idea, but is it big enough to qualify as entire project?<br>Maybe yes, especially after considering that things often are harder than<br>

expected and take far more time than it seemed at start.<br><br>In this project I see following parts<br>- creation of ticket on JOSM bugtracker (I am not expecting this, but in <br>  case that JOSM developers reject the entire idea I would instead create <br>

  plugin with this functionality).<br>- collecting use cases (two nodes + what ways would be expected to be <br>  found by algorithm)<br>- setting up development environment, with ability to build JOSM<br>- interface (new position in tool menu, icon, fetching data about what is <br>

  selected, error messages)<br>- algorithm that will find suitable connection (probably A* with cost <br>  functions)<br>- interface (selection of ways found by algorithm)<br>- automatic testing of algorithm based on collected use cases would be <br>

  an interesting thing but I am unsure whether it would be feasible<br><br>At this point it should be already useful for many tasks and faster than <br>configuring filters to select linear feature consisting of multiple ways.<br>

It would depend on how JOSM developers would see it, but it could be <br>at this stage merged into JOSM trunk (in case of backup plan I would <br>release a plugin).<br><br>Subsequently I would add handling of connection types<br>

- fixing bugs reported by user, encountered in released version<br>- modification of algorithm (multiple A* searches? Maybe something <br>  smarter and faster would be needed.)<br>- interface (selecting connection type)<br>

- loading user-defined connection types in reasonable and editable format<br>- definitions of some obvious types<br><br>Here I see good point for second release. I think that it should happen<br>before final deadline of GSoC and I would spend final days on<br>

- fixing bugs reported by users<br><br>Is there anything that I missed here? Is my plan realistic (GSoC coding<br>starts on 19 May and finishes on 11 August)?<br></div>