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

Mateusz Konieczny bulwersator at gmail.com
Tue Mar 18 21:35:03 UTC 2014


I wonder about checkpoints for "good standing with their communities"
on 19 May, "mid-term evaluation" on 23 June and "final evaluation deadline".

Should there be a precise set of what must be be done till 19 May and 23
June,
or is it decided based on whatever there is an active development? I assume
that to pass "final evaluation deadline" entire project must be delivered,
but how
the two previous ones are supposed to be handled?

I am unsure what I should write as "detailed timeline: how do you plan to
spend your summer?". Should I declare when each feature will be finished? Or
is it about something else?

My proposal is available on
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mateusz_konieczny/5629499534213120
I would appreciate any feedback.

> > - 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
> highlight.

I think that it may be better to avoid forcing user to click in cases when
algorithm guessed right without additional data.

> 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 am not sure. In the first case barrier should have either different layer
or
share node ("If a linear barrier crosses a highway, they must connect with
a node at intersection." - from Barriers article on wiki), and in the
second
road should have access tags. Though both cases are currently not
reported as a problem by JOSM validator (I filed ticket for the first case,
as
wiki is quite clear. Second seems to have no suggested solution on wiki,
maybe it should be discussed on tagging mailing list).

> - Deal with various tagging variants.

Added as part of defining route types ("improving definitions of route
types
to handle tagging variations").

> - Deal with features intersecting without nodes when they should block
> routing.

I think that all cases like this are mapping bugs and should be reported
by JOSM validator (expecting every single router to parse thing like
military
no-go areas instead of checking access tags on roads is IMHO a poor idea).

> - 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).

Added to proposal as "implicit way splitting (for nodes that are in
the middle of way), with minimal required user action"

> Make a proper Undo (This one being particular important)

I am confused here, there is probably no need to revert way selection.
Is it about implicit splitting requested during selecting route? I added
note about this.

> Maybe cope with runtime and/or space constraints

I mentioned it in the new proposal version ("algorithm that will find
suitable connection in acceptable time, without too high memory usage").

> Making a user interface to handle user-defined connection types, might be
a
quite large sub-editor).

I am not sure is it necessary, I thought that types would be edited like
validator
rules. Possible to do, but 99,9% of users never needs to do it and others
may simply edit text file.

> Fitting that into the various JOSM storage ideas (File format, storage in
the central JOSM wiki repository, store in local user preferences).

Is is about distributing plugin or is it about how it will work? Or maybe
both?

> - Probably i18n for the interface parts.

Now "making translations possible" is mentioned while discussing interface.

>- 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
> useful).

I hope that this one will require changes no bigger than (re)defining route
types.

> I think it would be helpful to first have it as a plugin and see it in
action.

OK, I will rework proposal to indicate that it is intended to start as a
plugin
and mention integration into JOSM trunk as potential future goal.

Should I mention public transport plugin in proposal as source of this idea?

> 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 :)

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20140318/8a435cc0/attachment.html>


More information about the dev mailing list