Skip to content

PSC Meeting 2022 01 21

Jump to bottom Edit New page
Eli L Adam edited this page Jan 26, 2022 · 5 revisions

https://web.libera.chat/?channels=#geomoose

Previous Meeting

Attending

This meeting was performed asynchronously due to scheduling conflicts. The following have checked-in:

  • Duck
  • klassenjs
  • EliL - also on email list: Generally I don't like the asynchronous meeting style. I find myself tediously commenting on points that would be a rapid discussion. I am a big fan of preparation in advance of a meeting and think we could do more of that to make our discussion more rapid and productive.
    ** We should probably start our next meeting by running through these points for discussion. Maybe preparing for the meeting in advance as well.

Agenda

  • Top Three Issues Responses. Brent made a nice list of priority issues. Duck has also been picking at the recent tickets list.
    • Zoom to Layer Extent Anyone wish to volunteer to draft an RFC for this? We have a lot of layer types, Duck could develop this much faster if we had a chart that had the layer-type, and if that service provides a "get extent." Or are we okay with the user specifying it in the mapbook?
    • Linking two dropdowns in the Search This will require revisiting some major assumptions to how the service-form generator works. Not impossible but this is likely a 8-12 hour project. Duck thinks it can be done without any breaking changes.
    • Bring back popups. This is another one that Duck feels we should RFC. Do we want to simply have the callback functions listed in the ticket? Do we want this to work with just vector layers? Should we add support for something like JSON Grid / UTF Grid? Keep it focused on the MVT format layers?
  • Direction setting
    • Duck loves this idea! +100
    • EliL +1 on direction setting
    • Mobile readiness. This post has some great information about global user bases. In fact, this article as been in Duck's brain a lot over the last month or so. It really gives some interesting perspective on the field of modern devices. Maybe we should collect a set of screen shots to see what others are doing in the space to offer a mobile experience that users enjoy using. Adding touch events and additional CSS tricks are one-thing but actually creating an experience is a larger set of work. It also begs the question: Can we force a more rigid application in order to deliver a more reliable experience? Right now, site administrators can choose which elements to place in the UI, where, and how to style them. Is that still useful? Can we "enforce" more norms? This makes the application more deploy-and-go but will ultimately remove some of the freedoms from those who want to customize the interface but do not want to setup a NodeJS environment. This would definitely lead to a 4.0. (EliL: I think with "map" you've already lost those lower dot users. We offer almost all the information we offer in GeoMoose through a text search as well; some users only ever use that. Mobile is good and I support that but don't think that we-or any map other than PDFs will pick up those lower dot users.)
    • Plug-in system. A lot has evolved with the React ecosystem since starting the project. But not everyone wants to be a React developer with a full NodeJS development environment. When are we losing the script? I think this begs a lot of the same questions as being more enabled for mobile.
    • Additional projections. With the latest versions of OpenLayers this has become much more do-able. The ability to meet survey needs still is not there and using projections other than Web Mercator will break a large number of layers. There are sites in the wild using OpenLayers with EPSG:4326 as the projection. We could definitely do a spike on UTM support.
  • Item 3
    • note 1

klassenjs: I'm seeing more demand for first class mobile support and ability to embed GeoMoose (or a simplified GeoMoose interface) into other pages. I'm ok with improving the demo apps and potentially creating a responsive demo app, but I'd hate to loose the embedding/customizing potential. I feel maintaining the line between the demo/example applications and the GeoMoose library/framework is important. I also think we should be documenting more of what can be done in app.js. There have been a couple questions on the list lately that could easily be solved with some custom code in app.js. Maybe we need a place where community contributed code snippets for things like this can live.

Next Meeting

Add a custom footer
Clone this wiki locally