> Having a
> tool that does the selection part according to a direct route would also
be a
> help but might be more demanding - the acceptable features for waterways
or
> railways differ from those for streets, and even for streets the subsets
that
> fits for buses differs significantly from the subset for cyclists. So the
> feature will require some clever user interface to handle this explanation
> challenge.
I thought about algorithm guessing connection type based on:
- 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)
- common tags on ways that contain selected nodes
- decision by user (this would be optional, there would be possible to
skip this in case when two previous items were sufficient.
I imagine it as a messagebox that is not capturing focus and is
appearing at the bottom of the screen. Something similar to
box "You have X unread messages" recently added to JOSM).
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
Quick examples of types:
- bus
- must appear: "highway=*"
- indicate: psv=yes, psv=designated, bus=yes, bus=designated
- should not appear: highway=pedestrian
- must not appear: highway=footway, highway=cycleway, highway=path
psv=no, bus=no, (access=no AND NOT bus)
- waterway
- must appear: "waterway=*"
- must not appear: waterway=riverbank
In general the biggest problem will be with various flavours of highways
(at least bus, car and bicycle), other linear features rarely share
nodes and it should be easy to detect way based on what is the same on
two selected nodes (except some degenerated cases like selecting two
nodes that are both railway/highway crossings, with the same rail and
the same road).
> > This approach may make coding more complicated but it would solve far
> > more general problem.
> Having another selection aid for JOSM would indeed help even more. I you
want
> then you could also focus the project to this challenge and leave aside
the
> tagging issues.
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.
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)
- interface (selection of ways found by algorithm)
- automatic testing of algorithm based on collected use cases would be
an interesting thing but I am unsure whether it would be feasible
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).
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
Here I see good point for second release. I think that it should happen
before final deadline of GSoC and I would spend final days on
- fixing bugs reported by users
Is there anything that I missed here? Is my plan realistic (GSoC coding
starts on 19 May and finishes on 11 August)?
_______________________________________________
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
