Wrong years in Multipdf

[cedricmoullet]

URL: https://map.geo.admin.ch/?topic=ech&lang=fr&bgLayer=voidLayer&layers=ch.swisstopo.zeitreihen&layers_timestamp=18641231&X=240048.59&Y=640049.86&zoom=5&time=1864 Print settings This configuration generates a PDF starting in 1873, but the first 1:100'000 layer is in 1861 (https://map.geo.admin.ch/?topic=ech&lang=fr&bgLayer=voidLayer&layers=ch.swisstopo.zeitreihen&layers_timestamp=18611231&X=240048.59&Y=640049.86&zoom=5&time=1861 http://www.alexandria.ch/primo_library/libweb/action/dlSearch.do?institution=BIG&vid=ALEX&scope=default_scope&query=lsr07,contains,bv80035830 )

[gjn]

I've analysed a bit. Last change of this was in this PR: https://github.com/geoadmin/mf-chsdi3/pull/1635 to fix https://github.com/geoadmin/mf-chsdi3/issues/1628.

I think the correct solution is between those 2. Before the above PR, the query to the db was correct (we used point to query the release years), but the model chosen for the query was wrong (because we didn't correclty calculate the resulution to be used to seleted the mode).

The PR fixed this in that the resolution is now correctly calculated and the correct model chosen, but the query itself is now down with a rectangle instead of a point.

That's if I understand this correctly, which I'm doubting a little bit. I can work on a fix.

@daguer @ltclm It would be great if you could provide some testcases. Given a a point, what results should the service return? Do you think that's possible?

[ltclm]

what's the url of the service which is collecting the years? It would be helpful to reproduce what exactly happens in the database.

[ltclm]

are you sure that the imageDisplay parameters passed to the release service are correct? The Link above is executing the following request: http://api3.geo.admin.ch/rest/services/ech/MapServer/ch.swisstopo.zeitreihen/releases?imageDisplay=11602,7667,96&mapExtent=625893.611111,230691.388889,654186.388889,249388.611

screen width: 11602
screen height: 7667

This request is executing the following query in the database

SELECT public.meta_22.gid AS public_meta_22_gid, ST_AsEWKB(public.meta_22.the_geom) AS public_meta_22_the_geom, public.meta_22.release_year AS public_meta_22_release_year, public.meta_22.bgdi_order AS public_meta_22_bgdi_order
        FROM public.meta_22
        WHERE ST_DWITHIN(public.meta_22.the_geom, ST_GeomFromWKB('\x010300000001000000050000007e8ae338cb19234106d6711c1b290c417e8ae338cb192341fa298ee364710e4182751cc7d4f62341fa298ee364710e4182751cc7d4f6234106d6711c1b290c417e8ae338cb19234106d6711c1b290c41'::bytea, 21781), 0.0) ORDER BY public.meta_22.bgdi_order

The view fruitcake_master.public.meta_22 contains the following products: lk25, ta25, ta50 there is no lk100.

When i modify the request above and enter my real screen dimension as follows: http://api3.geo.admin.ch/rest/services/ech/MapServer/ch.swisstopo.zeitreihen/releases?imageDisplay=1440,761,96&mapExtent=625893.611111,230691.388889,654186.388889,249388.611111

screen width: 1440
screen height: 761

The year list begins with 1861 and seems to be correct. The following query is executed in the database

 SELECT public.meta_15.gid AS public_meta_15_gid, ST_AsEWKB(public.meta_15.the_geom) AS public_meta_15_the_geom, public.meta_15.release_year AS public_meta_15_release_year, public.meta_15.bgdi_order AS public_meta_15_bgdi_order
        FROM public.meta_15
        WHERE ST_DWITHIN(public.meta_15.the_geom, ST_GeomFromWKB('\x010300000001000000050000007e8ae338cb19234106d6711c1b290c417e8ae338cb192341fa298ee364710e4182751cc7d4f62341fa298ee364710e4182751cc7d4f6234106d6711c1b290c417e8ae338cb19234106d6711c1b290c41'::bytea, 21781), 0.0) ORDER BY public.meta_15.bgdi_order

Are you sure that the width, height parameters have to be normalized? https://github.com/geoadmin/mf-chsdi3/blob/42d2b79684a76513d6c2c2402096ae563d46f22c/chsdi/views/printmulti.py#L76

[ltclm]

As discussed yesterday, i have fixed the meta and tooltip views in the database. https://github.com/geoadmin/db/commit/a86acee0d1dc2e4e3aa6aeed60125d837e83b841

Database has been deployed to dev.

[gjn]

In total, there were 3 problems leading to the wrong selection of years to print.

a) The meta views used to determine the years didn't contain the last data update. They needed to be adapted (see @ltclm comment above). This will require a deploy of the zeitreihen db. b) Wrong selection of meta model based on print settings. The wrong parameters were passed to the releases service. We didn't account for the correct print dpi settings. c) The results of the db query were not parsed correctly. Instead of considereing the bgdi_order to selected the years, the bgdi order was ignored.

For b) and c) a PR is upcoming.

[cedricmoullet]

Is there any chance to make tests in order to avoid regressions in future ?

2015-10-30 10:08 GMT+01:00 Gilbert Jeiziner notifications@github.com:

In total, there were 3 problems leading to the wrong selection of years to print.

a) The meta views used to determine the years didn't contain the last data update. They needed to be adapted (see @ltclm https://github.com/ltclm comment above). This will require a deploy of the zeitreihen db. b) Wrong selection of meta model based on print settings. The wrong parameters were passed to the releases service. We didn't account for the correct print dpi settings. c) The results of the db query were not parsed correctly. Instead of considereing the bgdi_order to selected the years, the bgdi order was ignored.

For b) and c) a PR is upcoming.

— Reply to this email directly or view it on GitHub https://github.com/geoadmin/mf-chsdi3/issues/1722#issuecomment-152465865 .

Twitter: http://twitter.com/cedricmoullet Linked In: http://www.linkedin.com/in/cedricmoullet

http://twitter.com/cedricmoullet

[gjn]

Yes. For the first time, we know what the shouldis and tests will be adapted accordingly.

[gjn]

It never worked correctly in RE3 before...