[geomoose-psc] PSC meeting tomorrow

[Jim Klassen]

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.