[geomoose-psc] PSC meeting tomorrow

[Jeff McKenna]

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




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