<div dir="ltr"><div>A good source is src/gm3/actions/mapSource.js:193. You can see the way it structures the object to pass into the add action. I won't say the code is the cleanest but we have a lot of small flags that make the world of what's possible pretty detailed. However, you should be able to strip it down to just the options that you need by taking a gander there. <br></div><div><br></div><div>There's a lot of downsides to JSON mapbook configuration:</div><div>1. XML provides for "context" in the tag naming. E.g. <map-source /> tells the reader it's a map-source.<br></div><div>2. There are no comments.</div><div>3. JSON does not support multiline strings.</div><div>4. JSON parsers are not universally easy to debug.</div><div>5. JSON doesn't like recursion.</div><div><br></div><div>There are answers to all of this and the answers will boil down to: "There are tradeoffs with each, pick your poison, we picked to poison ourselves with XML"<br></div><div><br></div><div>In fact, I spent like 2 minutes of my GM 3.0 announcement presentation talking about why we stuck with XML. hahaha.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 8, 2020 at 10:42 AM Jim Klassen <<a href="mailto:klassen.js@gmail.com">klassen.js@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It looks a lot messier than I had remembered.  Theoretically, you need to dispatch the correct actions.  Defining a correct action is definitely a trip down the reading the source rabbit hole.  Ducky?<br>
<br>
<br>
On 6/7/20 10:52 AM, Brent Fraser wrote:<br>
> (I was thinking of more of a replacement of XML with JSON in GM 4.)<br>
>    <br>
>   My mapbook.xml editing angst is mostly caused be lack of doc (which I'm<br>
> trying to solve). I need to figure out:<br>
>       what is possible?       is this a bug or a misunderstanding on my part?<br>
>    <br>
>   But if I can create map-sources and catalog layers using JavaScript, then<br>
> problem solved (sort of).  As an experiment, I pared down the demo app.js<br>
> to the minimum:<br>
>    <br>
><br>
>   var app = new gm3.Application();  app.add(gm3.components.Map, 'map', {});<br>
> app.setView({     center: [-12700000, 6630000 ],     zoom: 10 });<br>
> app.loadMapbook({url: 'mapbook.xml'}).then(function() {  });<br>
><br>
>   Do you have a snippet of adding a map-source (instead of using the<br>
> loadMapbook method)?<br>
>    <br>
>   Thanks!<br>
>    <br>
>    <br>
>   -------- Original Message --------<br>
>> From: "James Klassen" <<a href="mailto:klassen.js@gmail.com" target="_blank">klassen.js@gmail.com</a>><br>
>> Sent: June 7, 2020 9:26 AM<br>
>> To: "Brent Fraser" <<a href="mailto:bfraser@geoanalytic.com" target="_blank">bfraser@geoanalytic.com</a>><br>
>> Cc: "GeoMOOSE PSC" <<a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank">geomoose-psc@lists.osgeo.org</a>><br>
>> Subject: Re: [geomoose-psc] Thoughts on a JSON mapbook?<br>
>><br>
>> It should be possible and was discussed around 3.0 planning time. The<br>
>> mapbook loader is separate from the internal representation in 3.x.<br>
> IIRC,<br>
>> a mapbook isn't needed at all in 3.x. You can make the API calls to set<br>
>> everything up directly from your app.js, the mapbook is more of a<br>
>> shortcut.<br>
>><br>
>> In GeoMoose 3, app.js (or equivalent) is yours. We provide the examples<br>
> to<br>
>> help people get started and to have something concrete to test.<br>
>><br>
>> In general, GeoMoose 3 is much more of a library than GeoMoose 2.9 was.<br>
>> The example applications are setup to make users transitioning from<br>
>> GeoMoose 2.9 comfortable, not as the only way things can be done.<br>
>> (Although saying that, in practice the example apps are all that is<br>
>> regularly tested as part of the CI and release process).<br>
>><br>
>> My concern is solely about having the human resources to maintain and<br>
> test<br>
>> two formats as I don't think we can drop the XML mapbook without causing<br>
>> massive user pain. (I say this knowing how many times as is that we've<br>
>> missed updating/fixing something in the mobile example that was fixed in<br>
>> the desktop example).<br>
>><br>
>> Personally, the mapbook format doesn't matter much because once the<br>
> mapbook<br>
>> gets to a complexity where I am worried about editing difficulty, I end<br>
> up<br>
>> generating it from a web service anyway. This lets you do things like<br>
> have<br>
>> an online form for adding layers or have different mapbooks for<br>
> different<br>
>> users (based on ACLs for layers). I also have equivalent GeoMoose 2.9<br>
> and<br>
>> GeoMoose 3 mapbooks being generated from the same database this way.<br>
>><br>
>> On Sun, Jun 7, 2020, 09:48 Brent Fraser <<a href="mailto:bfraser@geoanalytic.com" target="_blank">bfraser@geoanalytic.com</a>> wrote:<br>
>><br>
>>> Hi All,<br>
>>><br>
>>> I've been doing a lot of mapbook editing lately, and it occurred to me<br>
>>> that perhaps a JSON format for the mapbook might make editing easier.<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> Best Regards,<br>
>>> Brent Fraser<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> geomoose-psc mailing list<br>
>>> <a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank">geomoose-psc@lists.osgeo.org</a><br>
>>> <a href="https://lists.osgeo.org/mailman/listinfo/geomoose-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geomoose-psc</a><br>
><br>
<br>
_______________________________________________<br>
geomoose-psc mailing list<br>
<a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank">geomoose-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geomoose-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geomoose-psc</a></blockquote></div>