[geomoose-psc] When Open Specs Close

Tue Dec 26 14:03:56 PST 2023

Hi Dan and all,

These are good points to contemplate.  Looking at the GeoMoose project, the niche filled, our userbase, and the process of setting up a GeoMoose site from scratch needs review since some of these things haven't been evaluated in probably ten years (GeoMoose has been around a while now!)

Creating a MapFile used to be a right of passage with a text editor, the command line, trial and error, and shp2img.  Back in those days, there were ways to start with some example files and begin editing/refining.  Speaking of E**I, (and things like Avenue, AML, and other old things), there were a few decent scripts to go from Ar*Map (or .axl) to a 90% complete MapFile.  TileMill and Mapnik went a similar way 2010ish and there is also Magnacarto.  It sometimes surprises me that there is not more popularity for QGIS plugins to export to MapFiles or that various SLD efforts didn't take off more.  I think the creation of the MapFile is probably the biggest hurdle to GeoMoose implementation.  Part of this may be ignorance on my part (getting good at MapFiles and then enjoying text editing them means that I'm not very aware of the easiest beginner paths to making MapFiles).  The link Brent sent could be informative in this regard.  Getting back to some of Dan's questions,

>1. How can we keep being the "plug-in-data-and-go" solution? How do we become the best at that? MapServer can feel very difficult to work with despite
>its performance. I think MapServer 8 is a great piece of software and I understand many of the design decisions but if I've grown up on E**I stuff, at this point,
> it'll be difficult to approach.

I think the plug-in-data-and-go is our niche.  I think to be the best at that, we need some kind of non-text editor MapFile styling method (this could be E**I or QGIS export tools, a styling GUI, or something similar).  If we can also offer a quick route to a working site with taxlots in one color with identify, select, and search working over OSM or other backgrounds, then users will know that it is worth pursuing more effort in MapFile creation and other aspects of site configuration.

>2. How can we get better at vector styling? This may be Ahab's Whale but is definitely something I think about. Styling in the app, styling data, how do we
>serve data that is easy to style? Etc. etc.

I'm not entirely sure that I follow the vector styling.  Do you mean in the app?  I think that we do a reasonably good job with the various in app shape drawing and related aspects.  I also see in app vector drawing and styling as a minor (but important) part of the niche so not having that much potential since it is a minor part.

For the other more ambitious things on the list, I second Brent's comment of focusing on integrating best of class packages and your caution that keeping up with changes for any of those could be full time jobs.

I also prefer text files and version control, but that doesn't require a text editor (generated text files can be put in version control).

Do people want to plan a chunk of time for a session looking at the GeoMoose project, the niche filled, our userbase, and the process of setting up a GeoMoose site from scratch?  We've discussed a sprint and could include reflection and planning in addition to code.

Best regards, Eli

________________________________
From: geomoose-psc <geomoose-psc-bounces at lists.osgeo.org> on behalf of Jim Klassen via geomoose-psc <geomoose-psc at lists.osgeo.org>
Sent: Friday, December 15, 2023 11:59 AM
To: geomoose-psc at lists.osgeo.org <geomoose-psc at lists.osgeo.org>
Subject: Re: [geomoose-psc] When Open Specs Close

I strongly prefer text files (and their usefulness with version control) over GUIs for most things, but to add to the text file editing pain, we still have a number of cases where an error in configuration causes everything to just stop working, usually with some gibberish console error like "j is undefined", instead of a message pointing at the problem.  That can be challenging to resolve even for those of us with years of GeoMoose experience... I suspect it is something that would cause most people who are staring out to just give up.

On 12/14/23 19:02, Brent Fraser via geomoose-psc wrote:

Hi Dan (and others),

So many things to consider, but to stay focused I would say:
  Keep it simple, and stick to what we're good at: integrating best of class packages (such as mapserver, GeoServer, and OpenLayers).

I would look for a good mapserver mapfile editor (or style creator) project and integrate that into our workflows.
https://github.com/MapServer/MapServer/wiki/MapFile-Editors

As for vector styling (especially via GM's mapbook), do we have any users interested in doing that?  If we do, something like GeoStyler might be the answer.  Our involvement could be as simple as adding How-to (or even just a link) to our doc.

A couple of years ago I started writing a GeoMoose Implementation Roadmap to help new users create a working site with their data.  It was scary how much text file editing you had to do on the server (and you better get the syntax right).

Best Regards,
Brent

________________________________
From: "Dan Little via geomoose-psc" <geomoose-psc at lists.osgeo.org><mailto:geomoose-psc at lists.osgeo.org>
Sent: 12/14/23 9:25 AM
To: GeoMOOSE PSC <geomoose-psc at lists.osgeo.org><mailto:geomoose-psc at lists.osgeo.org>
Subject: [geomoose-psc] When Open Specs Close

- https://github.com/openlayers/ol-mapbox-style/pull/940#issuecomment-1855415159

We use a "vendored" version of the ol-mapbox-style-spec to power GeoMoose's styling right now. This may have an effect on us over the next few months that motivate moving some of the styling engine over to something like GeoStyler's.

This does force me to shine light on a few GeoMoose things that I've been struggling with in the last two years:
1. How can we keep being the "plug-in-data-and-go" solution? How do we become the best at that? MapServer can feel very difficult to work with despite its performance. I think MapServer 8 is a great piece of software and I understand many of the design decisions but if I've grown up on E**I stuff, at this point, it'll be difficult to approach.
2. How can we get better at vector styling? This may be Ahab's Whale but is definitely something I think about. Styling in the app, styling data, how do we serve data that is easy to style? Etc. etc.

Things I know we can't make a part of our standard install and expect easy uptake:
- Cloud
- Docker
- "Compile."

There are solutions I would love to think about but have left off the table:
- Create a mapfile editor. It's been tried but with narrow constraints it might work.
- Jump to QGIS server and/or piggy back on it to allow publishing whole apps. Keeping up with these changes are likely a full time job.
- "F**k it, we're the mapserver now!" Collaborate with or upon a solution written in rust or go that support cross platform compilation. Double click a binary, it starts the server, go through the wizard to tell it where some data is, and you're off to the races. Want it as a service? Sure here's the 10-step guide to making it work with pm2 or on Debian.

Thank you for taking the space for this. 😆 I genuinely want us to have a product that people can use, use easily, and provide some real benefit to the ecosystem in ways other projects aren't. I love that this team has always focused on what it takes to do GIS in the trenches and what that user profile looks like.

_______________________________________________
geomoose-psc mailing list
geomoose-psc at lists.osgeo.org<mailto:geomoose-psc at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/geomoose-psc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20231226/04e6251f/attachment-0001.htm>