[OHM] JOSM extension suggestions

Wed Nov 6 19:32:14 UTC 2019

Jerry -

The only thing better than this note would be to have you there. This is
amazing input. The meeting will be far better with your thoughts. Can I
thank you enough! Will send out meeting notes after.

Thanks, Jeff

On Wed, Nov 6, 2019, 11:09 AM SK53 <sk53.osm at gmail.com> wrote:

> Hi Jeff,
>
> I'm afraid I don't really know much more than that.
>
> I think it makes sense to go down the route of an "OHM Utils" plugin using
> a small docking panel, with the view to incrementally extending
> functionality. An alternative would be have an OHM menu, or in the best of
> both worlds although both choices for the functionality,
>
> A few other thoughts:
>
>    -  An OHM validation CSS style would be a simpler way to provide some
>    instant hint that start or end dates are missing. A fairly sophisticated
>    one was the Irish Townlands which painted each set of boundaries a
>    different colour, but just something which showed tagged objects without
>    start date or end date in glaring technicolor would be a decent start. In
>    general the in-built validator of Josm is dealing with geometrical issues,
>    which are handled by code rather than some of the rule-based validation
>    seen in iD, but it's 10 years since I looked at the code.
>    -  A selector for tagged objects without start/end date (e.g., a
>    button) and the option to then add the existing defaults (e.g. visible in
>    the OHM panel). The predicate is something like "modified and tagged and
>    not(start_date)" in the Search menu (not entirely sure about last bit as I
>    often do these in sequence rather than a single statement).
>    - Docking panel should show & allow selection of time range, whether
>    as a slider or otherwise I don't mind. Does anyone use epoch at all? This
>    may change if an object with different start & end points is chosen, or
>    that perhaps should be shown separately.
>    - More whacky: a clone this object in another time period tool.
>
> These suggest to me that useful things could be achieved without being
> overly ambitious. I certainly feel that one needs to play with an interface
> to get a feel for what works best: obviously existing work provides at
> least some ideas.
>
> Not sure I can join you today as it's a little late for me these days.
>
> Regards,
>
> Jerry
>
> On Mon, 4 Nov 2019 at 15:30, Jeff Meyer <jeff at gwhat.org> wrote:
>
>> Hi Jerry -
>>
>> First of all, clearly, you know more about the JOSM extension world than
>> I do. I just know it's tough to do edits with data from a bunch of time
>> periods in the same area.
>>
>> Any chance you could help me guide these efforts? : )
>>
>> I haven't set up a time yet, but we could work around your schedule. If
>> you could join us, that would be great!
>>
>> For your questions, see my current draft answers below & I'm open to
>> correction / suggestions for any of them.
>>
>> Would you create a standalone OHM plugin?
>> - I'm not sure. Do you mean "not an internal JOSM plugin?" What I had in
>> mind was an OHM editing plugin that you could select from the Preferences
>> panel and was assuming that was not a JOSM internal plugin. What do you
>> suggest is the best approach.
>>
>> Would the code reside on GitHub? Josm still lives in SVN & the mirror
>> Github repo is about 6 months out-of-date
>> - I was aware that JOSM was in SVN and assumed that that would be the
>> best place to keep it.
>>
>> Have you considered the JOSM Scripting
>> <https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Scripting> plugin?
>> This might be a way of achieving endpoint toggling w/o touching Jsom core.
>> - I had not! I'll check into it. To be far, endpoint toggling is not the
>> core interest!
>>
>> Validation has been in Josm core since 2013. What approach would you want
>> to use for the validation/missing data flagging?
>> - Again, this is new to me, but in looking, I'd think we'd want to host
>> the rules on an external URL from the normal JOSM validator rules, as those
>> are OSM specific. Then, maybe add the rules with the same scripting tool
>> that flips the end point? Does that make sense?
>>
>> How would you plan maintenance? I'm always a bit flabbergasted how many
>> plugins stop working when I spin up a version which is a few months old.
>> - Great Q, and one that I'd need to discuss with the developers. My guess
>> is this would be a model where we'd wait until it broke, call up the devs
>> and ask for a fix. Not the greatest model, as it's "just too late" instead
>> of "just in time," but also probably more reasonable from a cost
>> perspective. Unless, of course, we had a JOSM-plugin-smart member of the
>> community who could help with that maintenance...
>>
>> Any thoughts, suggestions? This whole idea is a blank slate right now.
>> It'd be really great if you could join me on the call (and no additional
>> duty beyond that... unless you want it! : ) )
>>
>> Thanks,
>> Jeff
>>
>>
>>
>> On Mon, Nov 4, 2019 at 3:29 AM SK53 <sk53.osm at gmail.com> wrote:
>>
>>> Hi Jeff,
>>>
>>> Just some general queries about how you plan to do this?
>>>
>>>    -  Would you create a standalone OHM plugin?
>>>    -  Would the code reside on GitHub? Josm still lives in SVN & the
>>>    mirror Github repo is about 6 months out-of-date
>>>    -  Have you considered the JOSM Scripting
>>>    <https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Scripting> plugin?
>>>    This might be a way of achieving endpoint toggling w/o touching Jsom core.
>>>    -  Validation has been in Josm core since 2013. What approach would
>>>    you want to use for the validation/missing data flagging?
>>>    -  How would you plan maintenance? I'm always a bit flabbergasted
>>>    how many plugins stop working when I spin up a version which is a few
>>>    months old.
>>>
>>> Personally, I'd be hesitant about anything which may require
>>> integration/forking/… with Josm core. Largely because it's enormous and
>>> changes frequently. Being hosted on SVN is also a downside.
>>>
>>> I'd probably like something which automatically adds start & end dates
>>> as one creates data (or rather tags data, which is when a true historical
>>> element is created). They'd need to be set by the user for an editing
>>> session.
>>>
>>> Regards,
>>>
>>> Jerry
>>>
>>> On Fri, 1 Nov 2019 at 23:12, Jeff Meyer <jeff at gwhat.org> wrote:
>>>
>>>> Hi all -
>>>>
>>>> I'm looking at getting some JOSM extension work done, talking with some
>>>> developers next week & could use your input.
>>>>
>>>> Here's what I have in mind so far, please let me know what else you'd
>>>> suggest:
>>>>
>>>> So far, suggestions include:
>>>> - Time-based filter / slider to make it easier to work on one point in
>>>> time
>>>> - Warnings for ways / relations missing key tags: start_date, end_date,
>>>> license, source, attribution, etc.
>>>> - Updated slippy map to point at OHM & not OSM
>>>> - Toggle to change between OSM and OHM API endpoint
>>>>
>>>> Any thoughts?
>>>>
>>>> Thanks,
>>>> Jeff
>>>>
>>>>
>>>> ---
>>>> Jeff Meyer
>>>> 206-676-2347
>>>> osm: Open Historical Map (OHM)
>>>> <http://wiki.openstreetmap.org/wiki/Open_Historical_Map> / my OSM user
>>>> page <http://www.openstreetmap.org/user/jeffmeyer>
>>>> t: @OpenHistMap
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Historic mailing list
>>>> Historic at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/historic
>>>>
>>>
>>
>> --
>> Jeff Meyer
>> 206-676-2347
>> osm: Open Historical Map (OHM)
>> <http://wiki.openstreetmap.org/wiki/Open_Historical_Map> / my OSM user
>> page <http://www.openstreetmap.org/user/jeffmeyer>
>> t: @OpenHistMap
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/historic/attachments/20191106/c0ecd228/attachment-0001.html>