Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong years in Multipdf #1722

Closed
cedricmoullet opened this issue Oct 27, 2015 · 8 comments
Closed

Wrong years in Multipdf #1722

cedricmoullet opened this issue Oct 27, 2015 · 8 comments
Assignees
Labels

Comments

@gjn
Copy link
Contributor

gjn commented Oct 27, 2015

I've analysed a bit. Last change of this was in this PR: #1635 to fix #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
Copy link
Contributor

ltclm commented Oct 28, 2015

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
Copy link
Contributor

ltclm commented Oct 28, 2015

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?

def _normalize_imageDisplay(mapExtent, display):

@ltclm
Copy link
Contributor

ltclm commented Oct 30, 2015

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
Copy link
Contributor

gjn commented Oct 30, 2015

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
Copy link
Contributor Author

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
#1722 (comment)
.

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

http://twitter.com/cedricmoullet

@gjn
Copy link
Contributor

gjn commented Oct 30, 2015

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

@gjn
Copy link
Contributor

gjn commented Oct 30, 2015

It never worked correctly in RE3 before...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants