EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852023-10-25T09:27:33ZEDIT Project Management
Redmine feature request #10422 (New): Allow different base layers for distribution and occurrence mapshttps://dev.e-taxonomy.eu/redmine/issues/104222023-10-25T09:27:33ZAndreas Müller
<p>This is overlapping with <a class="issue tracker-5 status-1 priority-11 priority-default" title="feature request: Full implementation for showing IUCN "distribution" data separately (New)" href="https://dev.e-taxonomy.eu/redmine/issues/10343">#10343</a> (having separate maps for speparate features).</p>
<p>We could e.g. define a list of map settings instead of having only the 1 map setting as it is now. These setting will each have a name then and for each feature or each place where to show a map one may select 1 settings from the list of settings. This way the complex UI for setting the map settings can still be outsourced to a separate administration page as it is now and for the feature only 1 parameter needs to be selected.</p>
bug #10313 (New): Default color of terms is not shown correctly in dataportal mapshttps://dev.e-taxonomy.eu/redmine/issues/103132023-04-29T07:44:37ZAndreas Müller
<p>NoK:</p>
<p>fällt mir gerade mal wieder auf: Die Farben für die Status native und present sind nicht zu unterscheiden:<br>
<a href="https://cichorieae.e-taxonomy.net/portal/cdm_dataportal/taxon/55309c20-e883-4ed9-bc8b-c85f56074e72">https://cichorieae.e-taxonomy.net/portal/cdm_dataportal/taxon/55309c20-e883-4ed9-bc8b-c85f56074e72</a> (Sachalin is "present")</p>
<p>AM:</p>
<p>stimmt, die sind sehr ähnlich.<br>
Eigentlich sollte man das im TaxEditor unter Windows/Extras-Terms-Voabulary-DistributionStatus und das Auswahlt des Terms mit Color im Details View einstellen können, was die default Farbe ist für den jeweiligen Status. Ich habe das für „present“ mal zeitweise auf rot gestellt, aber ohne Erfolg (auch nach CDM Server neustart). Auch für native wird das derzeitig eingestellte gelb auf den Karten nicht angezeigt.</p>
<p>Der Wert scheint also nicht richtig ausgelesen zu werden.</p>
<p>Eine weitere Möglichkeit, die Farben der Status im Portal einzustellen ist im Admin Bereich des Portals unter <a href="https://cichorieae.e-taxonomy.net/portal/admin/config/cdm_dataportal/settings/layout/taxon">https://cichorieae.e-taxonomy.net/portal/admin/config/cdm_dataportal/settings/layout/taxon</a> und dann unter Taxon profile und dann ganz unten unter „Custom status colors“. Dort habe ich jetzt mal {"p":"#00ff00"}<br>
eingetragen. Es wird also reines grün angezeigt. Das scheint auch zu funktionieren, ist aber die weniger schöne Variante.</p>
<p>====</p>
<p>I make this a cdmlib issue for now as it is unclear if the problem is in DistributionInfo generation or on dataportal side.</p>
<p>It looks like the default color from term initialization is taken, not the one persisted with the term.<br>
The same problem also exists for the maps in the TaxEditor, so it does not seem to be a dataportal issue.</p>
<p>====</p>
<p>after fixing this ticket reset settings in dataportal settings. Also make sure that colors in all dataportals are still the same as they currently are. </p>
task #9458 (Closed): Consider lower zoom level as defaulthttps://dev.e-taxonomy.eu/redmine/issues/94582021-02-08T09:45:09ZAndreas Kohlbecker
<p>currently the default zoom level for maps is <code>15</code></p>
<p>This causes two problems with occurrence maps</p>
<ul>
<li>some maps only offer zoom levels up to 13 (e.g.: OpenTopo Map)</li>
<li>at high zoomlevel the maps often show too few context of the location if only one point is displayed. </li>
</ul>
bug #9367 (New): E+M shapefile Baltic subarea borders always visible and remove Georgian subdivis...https://dev.e-taxonomy.eu/redmine/issues/93672021-01-07T12:15:51ZAndreas Kohlbecker
<p>ERS:</p>
<p>gerade fällt mir auf, dass die Arealgrenzen innerhalb des Baltikums seltsamerweise nicht angezeigt werden, wenn es dort keine records gibt. Siehe z.B. die Karte für Canarina canariensis: <a href="http://www.europlusmed.org/cdm_dataportal/taxon/a4ec9711-a85a-4247-89d2-014d1bfcbdfb">http://www.europlusmed.org/cdm_dataportal/taxon/a4ec9711-a85a-4247-89d2-014d1bfcbdfb</a></p>
<p>Für alle anderen Unterareale (von Ex-Jugoslawien, Georgien etcetera) sind die Grenzen zu sehen, nur für Estland, Lettland und Litauen nicht.</p>
<p>Wenn es aber Records für diese Länder gibt, sind die Grenzen richtig zu sehen. Siehe <a href="http://www.europlusmed.org/cdm_dataportal/taxon/5017aedb-1c17-4085-83e3-2240a8107803">http://www.europlusmed.org/cdm_dataportal/taxon/5017aedb-1c17-4085-83e3-2240a8107803</a></p>
<p>Ist jetzt nicht soo kritisch, kann aber bei Gelegenheit mal angepasst werden.</p>
<p>====</p>
<p>Also the Georgian subdivisions should be removed: see also <a class="issue tracker-6 status-5 priority-11 priority-default closed" title="task: Remove Georgian subdivisions from Euro+Med (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/10414">#10414</a></p>
<p>=== </p>
<p>see also <a class="issue tracker-4 status-5 priority-10 priority-lowest closed" title="bug: Details page for derived unit only shows categorical data (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/10394">#10394</a> for other issues</p>
task #9161 (Rejected): E+M shapefile with Kaukasus regionshttps://dev.e-taxonomy.eu/redmine/issues/91612020-07-22T06:40:50ZAndreas Kohlbecker
<p>Wir brauchen dafür aber keine politischen, sondern pflanzengeografische Regionen. In der Kaukasus-Instanz müssten die Areale dafürschon angelegt sein (sonst hätten die Daten ja nicht eingegeben werden können), aber shapefiles gibt es dazu nicht:</p>
<p>So sieht die Karte aus:</p>
<p><a href="https://www.binran.ru/upload/caucasian/images/%D0%A0%D0%B0%D0%B9%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_html_181329b1.jpg">https://www.binran.ru/upload/caucasian/images/%D0%A0%D0%B0%D0%B9%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_html_181329b1.jpg</a></p>
<p>Map files als TIFF: <br>
<a href="https://cloud.mail.ru/stock/95zcTSRbWsjfxScVRQsg1tPn">https://cloud.mail.ru/stock/95zcTSRbWsjfxScVRQsg1tPn</a></p>
<p>und das ist die Karte mit Legende:</p>
<p><a href="https://www.binran.ru/resursy/informatsionnyye-resursy/tekuschie-proekty/caucasian-flora/contentkav/departments.php">https://www.binran.ru/resursy/informatsionnyye-resursy/tekuschie-proekty/caucasian-flora/contentkav/departments.php</a></p>
<hr>
<p><strong>Procedure to use the raster image as template for a vector layer</strong></p>
<p>(For QGIS)</p>
<ol>
<li>install the <a href="http://gvellut.github.io/FreehandRasterGeoreferencer/" class="external">FreehandRasterGeoreferencer</a> plugin via Menu: <em>Plugins > Plugin Manager</em></li>
<li>add Open Street Map or Open Topo Map as additional reference layer (The euro+med layer is a bit inaccurate in regarding costliness etc. making the arragenment of the raster image in the map difficult)</li>
<li>Add the raster image via the <code>ADD</code> function of the FreehandRasterGeoreferencer plugin.<br></li>
</ol>
<p><strong>Procedure for creating a vector layer from the raster image</strong></p>
<ul>
<li>Manually: <a href="http://www.qgistutorials.com/en/docs/digitizing_basics.html">http://www.qgistutorials.com/en/docs/digitizing_basics.html</a></li>
<li>Semi automatically:
<ul>
<li><a href="https://grass.osgeo.org/grass78/manuals/r.to.vect.html">https://grass.osgeo.org/grass78/manuals/r.to.vect.html</a> and also g.region, r.thin, v.clean for preparation </li>
<li>The tools provided by QGIS via Raster > Conversion > Polygonize</li>
</ul></li>
</ul>
task #8741 (Closed): Create test for MapServices to test if they support httpshttps://dev.e-taxonomy.eu/redmine/issues/87412019-12-04T09:12:37ZAndreas Müller
<p>This especially tests if the existing certificate is still valid.</p>
feature request #6653 (Closed): add more base maps to the data portal https://dev.e-taxonomy.eu/redmine/issues/66532017-05-19T09:05:26ZAndreas Kohlbecker
<p>Maps to be added:</p>
<ul>
<li><a href="http://maps.stamen.com/#terrain">http://maps.stamen.com/#terrain</a></li>
<li><a href="https://opentopomap.org/#map=8/37.7577/23.0109">https://opentopomap.org/#map=8/37.7577/23.0109</a></li>
</ul>
<p>Also add them to the mapproxy: <a href="http://geo.cybertaxonomy.org/mapproxy/demo/">http://geo.cybertaxonomy.org/mapproxy/demo/</a></p>
bug #6303 (Closed): distribution map is moving too fasthttps://dev.e-taxonomy.eu/redmine/issues/63032016-12-23T13:11:40ZGabriele Dröge
<p>when trying to move the distribution map with the mouse it is moving too fast so I can't drag it to the point I'm looking for. Tried with two different machines and mice.</p>
bug #6250 (New): bbox transformation for EPSG:900913 layers from the edit mapservice responses is...https://dev.e-taxonomy.eu/redmine/issues/62502016-12-06T16:24:20ZAndreas Kohlbecker
<p>symptom: EPSG:900913 maps like Google Satellite are not being zoomed to the bbox as calculated by the EDIT map service.</p>
<p>Example: <a href="http://test.e-taxonomy.eu/dataportal/preview/corvidae/cdm_dataportal/taxon/471c7f74-6590-4e29-8569-65a5ac44ab7c">http://test.e-taxonomy.eu/dataportal/preview/corvidae/cdm_dataportal/taxon/471c7f74-6590-4e29-8569-65a5ac44ab7c</a></p>
bug #5938 (Closed): distribution and specimen maps can not be used on the same pagehttps://dev.e-taxonomy.eu/redmine/issues/59382016-06-30T11:08:08ZAndreas Kohlbecker
<p>In tab-less taxon pages with distribution and georeferenced specimens the specimen map is broken. </p>
<p>test cases:</p>
<ul>
<li><a href="http://portal.cybertaxonomy.org/rubiaceae-mexico/cdm_dataportal/taxon/7d653b8c-13fe-47d4-ad6a-d54fc0259531/all">http://portal.cybertaxonomy.org/rubiaceae-mexico/cdm_dataportal/taxon/7d653b8c-13fe-47d4-ad6a-d54fc0259531/all</a></li>
<li><a href="http://caryophyllales.org/caryophyllales_spp/cdm_dataportal/taxon/425306ee-fd02-487a-9955-0bd64ba8416a">http://caryophyllales.org/caryophyllales_spp/cdm_dataportal/taxon/425306ee-fd02-487a-9955-0bd64ba8416a</a></li>
</ul>
task #5384 (New): consider update to openlayers 3.xhttps://dev.e-taxonomy.eu/redmine/issues/53842015-11-18T14:51:59ZAndreas Kohlbecker
<p>Openlayers 3 has a lot of improvements over version 2:</p>
<ul>
<li><p>high-dpi support</p></li>
<li><p>better vector rendering engine</p></li>
<li><p>Mobile support out of the box</p></li>
</ul>
<p>see <a href="http://stackoverflow.com/questions/25751069/updating-to-openlayers-3">http://stackoverflow.com/questions/25751069/updating-to-openlayers-3</a></p>
<p>related to <a class="issue tracker-5 status-5 priority-11 priority-default closed" title="feature request: responsive layout & theme (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/4837">#4837</a></p>
task #4150 (New): compile edit map service documentation of new features in version v1.4_dev and ...https://dev.e-taxonomy.eu/redmine/issues/41502014-03-19T15:56:42ZAndreas Kohlbecker
<p>compile documentation of new features in version v1.4_dev and v1.5_dev</p>
<p>the below excepts from a discussion related to #2707 ([E+M][Geo] Find shapefiles for non-tdwg E+M areas) is actually the most up-to-date documentation of v1.4_dev and v1.5_dev with the projection change</p>
<hr>
<p>Some news from the EDIT webservices…</p>
<a name="1"></a>
<h2 >1)<a href="#1" class="wiki-anchor">¶</a></h2>
<p>I’ve improved our Jenkins/ PHPUnit tests for the EDIT web service (the PHPUniy can now directly test the output of an HTTP GET request, while it was not the case before) and also worked today on the REST services.</p>
<a name="2"></a>
<h2 >2)<a href="#2" class="wiki-anchor">¶</a></h2>
<p>I managed (on a test version called v1.4_dev) to debug the problem I had 2 weeks ago when the possibility to choose 2 different indexer columns was enabled.</p>
<p>It is now possible to have different indexer columns (eg below: “emarea” for Germany and “parent” for France)</p>
<p><a href="http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?ms=500,500&as=a:76FFFF%7Cb:76FF22&ad=em_tiny_jan2003:emarea:a:Ge%7Cem_tiny_jan2003:parent:b:Ga&bbox=-31.8,30.129996,51,71.529996">http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?ms=500,500&as=a:76FFFF|b:76FF22&ad=em_tiny_jan2003:emarea:a:Ge|em_tiny_jan2003:parent:b:Ga&bbox=-31.8,30.129996,51,71.529996</a></p>
<p>This script doesn’t break the other maps like it was the case before</p>
<p><a href="http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?l=earth&ad=tdwg3:a:PHI,VAN,BOR%7Cb:BIS,SUM&as=a:8dd3c7%7E2%7Cb:e91f16,5be166%7E2_4&ms=500&label=0&recalculate=false">http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?l=earth&ad=tdwg3:a:PHI,VAN,BOR|b:BIS,SUM&as=a:8dd3c7~2|b:e91f16,5be166~2_4&ms=500&label=0&recalculate=false</a></p>
<p><a href="http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?ms=500,500&l=background_gis:y,tdwg3:x&as=a:000000%7Cy:FFFFFF%7Cz:D0D0D0,D0D0D0%7Cx:,000000%7Cx_nf:FF000000,000000%7Cw:77FFFF,FFFF77&ad=vmap0_afsa_elev_contour_ls:f_code:z:%25%7Cvmap0_afsa_hydro_inland_water_prm_only_a:nam:w:%25%7Ctdwg3:x_nf:%25&&bbox=29,-13,31,8&os=1:c/ffffff/10/noLabel&od=1:-2.5,29.25%7C-2.43333333333333,29.2333333333333%7C0.35,29.7833333333333%7C-3.05,28.4333333333333%7C-2.95,28.8166666666667%7C-2.25,28.6833333333333%7C-2.38333333333333,28.6666666666667%7C-1.4,29.6%7C-3.6,29.5%7C-3.0,29.55%7C-3.95,29.6166666666667&recalculate=true">http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?ms=500,500&l=background_gis:y,tdwg3:x&as=a:000000|y:FFFFFF|z:D0D0D0,D0D0D0|x:,000000|x_nf:FF000000,000000|w:77FFFF,FFFF77&ad=vmap0_afsa_elev_contour_ls:f_code:z:%25|vmap0_afsa_hydro_inland_water_prm_only_a:nam:w:%25|tdwg3:x_nf:%25&&bbox=29,-13,31,8&os=1:c/ffffff/10/noLabel&od=1:-2.5,29.25|-2.43333333333333,29.2333333333333|0.35,29.7833333333333|-3.05,28.4333333333333|-2.95,28.8166666666667|-2.25,28.6833333333333|-2.38333333333333,28.6666666666667|-1.4,29.6|-3.6,29.5|-3.0,29.55|-3.95,29.6166666666667&recalculate=true</a></p>
<p>Actually debugging the problem n°2 involved a substantial modification in the part of the script that generates the SLD…</p>
<p>The PHP script actually generates a first XML DOM document with the style information and, uses an intermediate XSLT field to finally write the final SLD and store it in the file system. I had to use some more intermediate DOMDocument in the PHP script (to add child XML node containing the name of the indexer columns in the first XML DOM), and also added an extra template in the XSLT file to have it running.</p>
<a name="3"></a>
<h2 >3)<a href="#3" class="wiki-anchor">¶</a></h2>
<p>Regarding the possibility to handle several projections, it is now possible in this test version to specify a reprojection, but only for the JSON output, by using the parameter “dest_projection_epsg”</p>
<p><a href="http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?ms=500,500&as=a:76FFFF%7Cb:76FF22&ad=em_tiny_jan2003:emarea:a:Ge%7Cem_tiny_jan2003:parent:b:Ga&bbox=-31.8,30.129996,51,71.529996&dest_projection_epsg=7777777&img=false">http://edit.africamuseum.be/edit_wp5/v1.4_dev/rest_gen.php?ms=500,500&as=a:76FFFF|b:76FF22&ad=em_tiny_jan2003:emarea:a:Ge|em_tiny_jan2003:parent:b:Ga&bbox=-31.8,30.129996,51,71.529996&dest_projection_epsg=7777777&img=false</a></p>
<p>The JSON reply contains an element “bbox_dest_projection” that gives the coordinates of the bbox in the destination projection and another elements “points_dest_projection” with the position of the occurrence data (if PostGIS can handle it, I couldn’t get a reply with ESPG:777777 for Africa).</p>
<p>But the reprojection is currently not implemented for the PNG output (I guess the JSON output covers most of the CDM portal needs as it rebuild the map in OpenLayers…).</p>
<p>I need to merge these development into the current v1.2_dev version.</p>
<p>Best regards,</p>
<p>Franck</p>
<hr>
<p>please continue ...</p>
feature request #3697 (New): Distinguish display of fossil and "normal" occurrence records in spe...https://dev.e-taxonomy.eu/redmine/issues/36972013-09-03T15:20:34ZGabriele Dröge
<p>Fossil records are telling a different story of distribution/occurrence of a taxon than classical occurrence records. Therefore they should be displayed in a different way in the specimen maps, otherwise a misinterpretation of the map is forseeable.</p>
<p>e.g. Cyanopica today only in Portugal/Spain and eastern Asia/China. Fossil records available for the whole area between Spain and China.</p>
<p>I suggest at least a different color/pattern for the fossil bubbles in the specimen map. In worst case different colors/patterns are required for different geological eras due to millions of years laying between them.</p>
<p>We should also think about creating a separate specimen map for the fossil records, maybe this is easier to implement and a different color/pattern could be avoided?</p>
<p>Since I am currently on the way to include a lot of fossil records to the Corvids portal I would appreciate a solution for this.</p>
feature request #3650 (Closed): allow supressing empty distribution and specimen mapshttps://dev.e-taxonomy.eu/redmine/issues/36502013-08-19T10:16:45ZAndreas Kohlbecker
<p>A new map settings option is needed to allow suppressing distribution and specimen maps in cases when no data would be shown. The behaviour in both cases must be consistent.</p>
<p>NOTE: currently the map setting for specimen_maps are also covered by the distribution map settings at the time of writing this ticket.</p>
<p>related to <a class="issue tracker-5 status-7 priority-12 priority-high14 closed" title="feature request: option to show empty distribution maps (Duplicate)" href="https://dev.e-taxonomy.eu/redmine/issues/5047">#5047</a></p>
feature request #2684 (New): Allow custom setting for style, color and size for occurrence map sy...https://dev.e-taxonomy.eu/redmine/issues/26842011-12-05T09:47:43ZAndreas Kohlbecker
<p>Provide data portal admins with setting for style, color and size occurrence map symbols.</p>