[geomoose-psc] When Open Specs Close

[TC Haddad]

Yesterday I edited the wiki page that Brent linked to, to add the GeoCat
Bridge QGIS plugin, which was recently referenced on the MapServer list as
another mapfile syntax generator. Mentioning it here because I had been
testing their "StyleViewer" this last week, and it's pretty uncomplicated
to use, and the tabbed interface allows flipping from MapServer to
GeoStyler syntax pretty easily, so that's potentially a single
(well-supported?) UI that helps with both raster and vector styling. Screen
grab here for the curious: https://imgur.com/a/VM4XRbH

I think having users do their styling in QGIS is the way to go if at all
possible, and there are other QGIS plugins (e.g. SLYR:
https://github.com/north-road/slyr) out there that are already tailored to
enticing migration from the E**I ecosystem of styling (LYR files) to QGIS.
So that means with some documentation glue, users could be coached on how
to bring existing cartography into QGIS from the proprietary world, and
then transfer it to MapServer or GeoStyler cartography for use in GeoMoose,
without too many steps.

At least, this is what comes to mind on the cartography side from my "GIS
in the trenches" experience with users in small communities.

Tanya


On Thu, Dec 14, 2023 at 8:14 AM Dan Little via geomoose-psc <
geomoose-psc at lists.osgeo.org> wrote:

> -
> 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
> https://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20231227/cfa84cd5/attachment.htm>