[geomoose-psc] PSC meeting tomorrow

[Jeff McKenna]

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...

thanks,

-jeff



-- 
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/