[geomoose-psc] PSC meeting tomorrow

[Jim Klassen]

On 1/20/22 15:17, Jeff McKenna wrote:
> On 2022-01-20 4:48 p.m., Jeff McKenna wrote:
>> On 2022-01-20 4:42 p.m., Jim Klassen wrote:
>>>
>>>
>>> On 1/20/22 14:24, Jim Klassen wrote:
>>>>
>>>>
>>>> On 1/20/22 14:07, Jeff McKenna wrote:
>>>>> On 2022-01-20 4:04 p.m., Jim Klassen wrote:
>>>>>>
>>>>>>
>>>>>> On 1/20/22 13:33, Jeff McKenna wrote:
>>>>>>> On 2022-01-20 3:07 p.m., Jeff McKenna wrote:
>>>>>>>> On 2022-01-20 2:16 p.m., James Klassen wrote:
>>>>>>>>>
>>>>>>>>> Where are we at with MapServer 8 support?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for mentioning this.  I just checked now (loading GeoMoose demo into MS4W 5.0 beta2 / MapServer 8.0-dev), and a recent fix by Tanya removing OPACITY at the LAYER-level (it should be inside a COMPOSITE object instead) is not yet applied in either the 3.8.0 data download package on geomoose.org or also on ms4w.com  (so we both must apply this fix to the demo package as soon as possible) https://github.com/geomoose/gm3-demo-data/commit/c29e41a341a300532984a4daeb26fa14bddc156a   I will tackle this today...
>>>>>>>>
>>>>>>>
>>>>>>> Uh-oh, I think I opened a can of worms.  (I spoke to Tanya about this when I first saw these warnings)  I was hoping that, this would go away ha.  Here it goes:
>>>>>>>
>>>>>>> - use MapServer 8.0-dev (main branch) with PROJ 8 (any version) and execute on demo/statedata/basemap.map:
>>>>>>>
>>>>>>>   map2img -m basemap.map -o ttt.png -map_debug 3
>>>>>>>
>>>>>>> And you will see *many* warnings from PROJ of:
>>>>>>>
>>>>>>>   PROJ: Error: utm: Invalid latitude
>>>>>>>
>>>>>>> And the problem layers *don't draw*.
>>>>>>>
>>>>>>> I remember finding the PROJ thread where it was explained that this validity checking became mandatory as of a certain release, but I don't have that link at the moment.
>>>>>>>
>>>>>>> My point is: a good review/testing of each mapfile in the demo is required to make sure the data works with recent PROJ (we may possibly have to use more valid data)
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> -jeff
>>>>>>>
>>>>>>
>>>>>> I wonder what MapServer is hitting...
>>>>>>
>>>>>> The mapfile is only referencing muni.shp and county.shp.  Both of those are contained within Minnesota which is well within valid latitudes for UTM. It is typical of Minnesota statewide data to be stored in UTM zone 15 even though there are slivers of the state that are actually in zones 14 and 16.  But that's a longitude issue not a latitude issue.
>>>>>>
>>>>>> I'm not seeing a problem opening those shape files with QGIS or transforming them to 3857 or 4269 using ogr2ogr.  StatesDD could be trouble since it has all the US states + territories in it, and is strange since it is in NAD27, but the mapfile isn't referencing that shapefile.
>>>>>>
>>>>>> This is with proj 8.1.1/gdal 3.3.2 for QGIS 3.22 and proj 8.2.0/gdal 3.4.0 for ogr2ogr.
>>>>>>
>>>>>> Layer name: muni
>>>>>> 26915 Extent: (189783.510986, 4816314.930000) - (701353.670000, 5433610.130000)
>>>>>> 4269 Extent: (-97.239094, 43.499588) - (-90.313161, 48.977466)
>>>>>>
>>>>>> Layer name: county
>>>>>> 26915 Extent: (189783.560000, 4816309.330000) - (761653.524114, 5472346.500000)
>>>>>> 4269 Extent: (-97.239093, 43.499437) - (-89.491763, 49.383751)
>>>>>
>>>>> Are you getting the same PROJ errors that I am with map2img and those PROJ versions (and MapServer main) ?
>>>>>
>>>>> -jeff
>>>>>
>>>>
>>>> I don't have a recent MapServer build handy at the moment. But it must be doing something different than QGIS and OGR when handling those layers.
>>>>
>>> But to be clear, I am not seeing any proj errors with QGIS and OGR.
>>
>> I should also state that I have to make a change to geomoose_globals.map to add an outputformat, for these mapfile tests each time (I have now filed a PR for this at https://github.com/geomoose/gm3-demo-data/pull/12 )
>>
>> Please, others test this if you can...
>>
>
> By the way, my earlier statement of "layers are not drawn" maybe incorrect, I/we'd need to change the extents and examine more closely, someone familiar with these layers, and see if those rejected features by PROJ are causing issues.
>
> Ok that's enough from me on this for now ha!
>
> -jeff
>
I just tested with a local build of MapServer (from main 192e7cadf).

This produces the "PROJ: Error: utm: Invalid latitude" messages, but out.png is created.  It appears to have a very large extent.

~/apps/mapserver/rel-7-6-0-799-g192e7cadf/bin/map2img -m basemap.map -i PNG -o out.png


Trying mapserv directly (using parameters from the default view of the GeoMoose Demo) does not produce any errors:

~/apps/mapserver/rel-7-6-0-799-g192e7cadf/bin/mapserv QUERY_STRING="SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=city_poly%2Ccounty_borders&MAP=basemap.map&SRS=EPSG%3A3857&STYLES=&MAP_RESOLUTION=80.59701492537313&WIDTH=1024&HEIGHT=736&BBOX=-10392374.5504%2C5535248.974400001%2C-10348672.9696%2C5566659.4856" > aaa


After changing the default projection in geomoose_globals.map from 4326 to 3857 the following also works without error:

~/apps/mapserver/rel-7-6-0-799-g192e7cadf/bin/map2img -m basemap.map -i PNG -o out.png -e -10392374.5504 5535248.974400001 -10348672.9696 5566659.4856


So, I think the PROJ errors are coming from MapServer trying to draw an unrealistic map extent and not from the data.