maptiler / epsg.io Goto Github PK

Update the readme.md with sections:

• Installation of ready to use index (download from GitHub)
• Creating a custom index - dependencies

For world coverage (such as in /4326 or /3857) we need to display the coordinates differently.

In the image link
http://maps.googleapis.com/maps/api/staticmap?size=265x215&scale=2&sensor=false&visual_refresh=true&center=0.0,0.0&path=color:0xff0000ff|fillcolor:0xff000022|weight:2|-90.0,-180.0|90.0,-180.0|90.0,180.0|-90.0,180.0|-90.0,-180.0
the
-90.0,-180.0|90.0,-180.0|90.0,180.0|-90.0,180.0|-90.0,-180.0
must be replaced by
-85,-179.9|85,-179.9|85,0|85,179.9|-85,179.9|-85,0|-85,-179.9

To be tested on 180,90 in the bounds.

Let's prepare in a subdirectory webapp of the repository the manifest and icon.

https://developers.google.com/chrome/web-store/docs/publish#step2

https://googledrive.com/host/0BwUe1kqIRJWSMW56OTZjekg2dG8/

Import SR WKT definitions and codes into epsg.io index

Germany has in EPSG.io mentioned also the individual states - so the GeoIP should query better "Bayern" or "Nordrhein-Westfalen" as "Germany". We will get more relevant results then.

Similarly we could create a list of locations which are satellites for other countries - such as "Corsica" or "Reunion".

This may be useful in suggesting relevant coordinate systems from full postal address via reverse geocoding on the /map application.

Proper solution SQLite database with all ESRI WKT codes - including the hierarchy.

Better head title on the web.

Front page:
title:"EPSG.io: Coordinate systems worldwide"
description: TODO

Results page
H1/title: Coordinate systems for "Czech Republic"
Vertical coordinate systems for "Czech Republic"
Geodetic datums for "Czech Republic"
Transformations for "Czech Republic"
where "Czech republic" is the query - and prefix is adjusted by the type.
description: TODO

Detail page
title: EPSG:5514 - S-JTSK / Krovak East North - Alternative title
description: "Projected coordinate systems for Czech Republic, Slovakia. Greenwwich based- altenrative to ... "

Map page
title: "WGS84 and S-JTSK / Krovak East North - transform coordinates for position on a map - converting latitude / longitude degrees"
description: Transform coordinates ...
h1: EPSG:5514 S-JTSK / Krovak ...

Basis on:
http://epsg.io/?q=czech&format=json&trans=1&callback=asdf

A basic documentation to be done

Import codes from ESRI into the epsg.io index.

We will use Disqus for now:

    <div id="disqus_thread"></div>
    <script type="text/javascript">
        /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
        var disqus_shortname = 'epsg'; // required: replace example with your forum shortname

        /* * * DON'T EDIT BELOW THIS LINE * * */
        (function() {
            var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
            dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
        })();
    </script>
    <noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
    <a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>

this will also make #26 (proj4js can't handle gml projections)

We will use CDN for caching - but we shall explore options for speeding up the server as well (multiple processes, memcached, improved HTTP headers)

.. a set of dropdowns adjusting the query for UTM - dropdowns for ellipsoids, and zones - similar to MapTiler - placed on the top of result list in case the query contains "utm" string.

Now transformation of typed coordinates is triggered only by hitting Enter key (submit on the form).
It should be also done on loosing focus on the input.

This may be a problem of other from Proj4 ESRI derived systems in the EPSG.io database. May be solved properly by #24

Reported by:
[Dr.Sharad Lele, Senior Fellow, ATREE www.atree.org]
[email protected]

EPSG 37203 (or ESRI 37203) corresponds to GCS Everest India Nepal, which refers to Everest 1956 spheroid and India_nepal datum. This spheroid-datum combination is used in Survey of India toposheets of the 1960-2000 period.

The problem is that the proj.4 specification of 37203 is incomplete. It only specifies:

+proj=longlat +a=6377301.243 +b=6356100.230165384 +no_defs ...........................[1]

This implies there is no displacement of the datum with respect to the WGS84 centre of earth. But in fact, the India-Nepal datum is displaced significantly w.r.t WGS84. The displacement values are given in various documents (one such document is attached--search for Nepal). Accordingly, the correct proj.4 specification of this spheroid-datum combination would be:

+proj=longlat +a=6377301.243 +b=6356100.2284 +towgs84=295.00,736.00,257.00,0,0,0,0 +no_defs ...................... [2]

[PERHAPS a more accurate representation would be

+proj=longlat +a=6377301.243 +b=6356100.2284 +towgs84=295.00,736.00,257.00,12.00,10.00,15.00,7.00 +no_defs ............. .[3]

I am not sure about this].

As you know, QGIS software uses the proj.4 definitions directly. I have experimented in QGIS with using just 37203 as it is to geo-rectify scanned toposheets. But this results in the geo-rectified toposheet being displaced from its correct position by about 200meters. When i use my 'corrected proj.4 specification' [2], the geo-rectified toposheet sits perfectly in position. I have tested this with several toposheets and the same thing happens.

I hope I am making my point clear. I am not an expert on projections or GIS software as such, but I have over many years figured out how to correctly geo-rectify Indian toposheets. When I was using ERDAS Imagine to do this, I was explicitly defining the 'reference projection system' as "Geographic lat-long with Everest 1956 spheroid and India-Nepal datum", and things worked just fine. When I shifted to QGIS, I noticed this problem (because QGIS uses the proj.4 definitions), and so I thought of bringing it to your notice.

I would be happy to correspond further if any clarifications are required.

Instead of loading the data into PostGIS we could rewrite the create_index.py to directly process the official GML dump from http://www.epsg-registry.org/

There is a bug in the JSON API when trans=1 is set.

For example query:
http://epsg.io/?q=czech&format=json&trans=1

returns Pulkovovo on the first place and wrong WKT and name.

Results should be similar to:
http://epsg.io/?q=czech&format=json

but with added transformations.

For example this link: http://epsg.io/28992.js, which is linked from http://epsg.io/28992 gives this message:

Something went wrong.

500: Internal Server Error

Can we try to move the button "Get coordinates on the map" down under Attributes line, in case there are no transformations to chose from - and it is otherwise alone above in the div?

I hope it may look better then - but did not discuss it yet with designer. What do you think?

If the query contains word "nad" we should on the top of the result list suggest:

Did you mean "NAD83" or "NAD27"?

where these two are are links replacing word "nad" by "nad83" or "nad27" in the query and triggering new result list.

A transparent Flash needs to be overlayed.

ZeroClipboard or others.

Example: EPSG:5514 and EPSG:5513 should have a different axis orientation.

The EPSG.io website shows the same coordinates, which is wrong.

Proj4 supports now +axis:
http://osgeo-org.1560.x6.nabble.com/axis-switch-to-control-axis-orientation-td3841902.html

An initial testing is required:

• http://lucene.apache.org/solr/ !!!
• http://www.elasticsearch.org/ !
• http://sphinxsearch.com/
• http://xapian.org/
• ...?

It may be practical to select alternative transformation for the selected coordinate system on the map page.

Selection similar to this: http://jsfiddle.net/klokantech/3cfnA/1/ probably - under the name of the system.

People type into search box often an address.
We could detect this with Google Geocoder in JavaScript.

In case the address is detected, and we have no results, then we can show coordinate system for the country (state for USA or Germany) from detected address and suggest "coordinates on a map" at given location.

Switching does not run now.

... when possible.

Get the elevation for position with:
https://developers.google.com/maps/documentation/javascript/elevation

Display it in the main window next to the coordinates.

And possibly use it in conversions.

Inspired by:
http://www.staremapy.cz/press/oznameni-prvniho-pilotu/
and
http://www.staremapy.cz/press/

We need a list of all values from EPSG database GML export stored and displayed, not indexed by fulltext.

Let's import the GML epsg-registry.org exports into an SQLite database with structure:

urn = 'urn:ogc:def:deprecation:EPSG::833'
id = 'epsg-deprecation-833'
xml = valid XML as in #18

#18

This will be displayed as "OGC GML" for all EPSG codes - especially for transformations, datums, etc.

New redirects:
http://epsg.io/urn:ogc:def:deprecation:EPSG::833 -> http://epsg.io/833-deprecation
http://epsg.io/epsg-deprecation-833 -> http://epsg.io/833-deprecation

Show the version of the EPSG database in the footer on every page

The Map page (e.g. /4326/coordinates) should display bounds of transformation - and zoom the these by default. (now the zoom is fixed :-().

The bounds should be passed instead of the center lon/lat from the HTML to JavaScript.

For displaying the bounds on the map we may use the trick similar to http://www.kartenportal.ch/kartensammlungen/ - as it is described at:

http://stackoverflow.com/questions/2956355/highlight-polygon-and-tint-rest-of-map-using-google-maps

This is also retrievable via Google Maps API reverse geocoding.

We may need it for suggesting alternative "coordinate systems" anyway - as mentioned in #4.

http://epsg.io/8905-primem

It tells:

Degree from Greenwich: -3.411658

and later in the GML:

 <gml:greenwichLongitude uom="urn:ogc:def:uom:EPSG::9102">3.687938888889</gml:greenwichLongitude>

together with

          <epsg:sexagesimalValue uom="urn:ogc:def:uom:EPSG::9110">
           <epsg:degrees>3</epsg:degrees>
           <epsg:minutes>41</epsg:minutes>
           <epsg:seconds>16.58</epsg:seconds>
           <epsg:hemisphere>W</epsg:hemisphere>

so the first value is probably wrong?

To be done already with a new update script directly from GML file (#22)

Tracking code to be added

Until OGR/GDAL supports the export of EPSG:3857 to expected ESRI WKT (http://trac.osgeo.org/gdal/ticket/3962)

we implement a hack returning for code 3857 the ESRI definition:

PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0],AUTHORITY["EPSG",3857]]

Improve handling of Not found page

Integrate (after discussion with designer) the share buttons.

The Map (/coordinate) page should probably include the static maps API request as well - or expose it in the meta headers at least - for facebook and pinterest.

Inspiration for the code:
http://dev.klokantech.com/klokan/share.html

Let's add Google AdSense to earn some money to cover costs of the hosting:

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- EPSG.io -->
<ins class="adsbygoogle"
     style="display:inline-block;width:728px;height:90px"
     data-ad-client="ca-pub-0328423815528922"
     data-ad-slot="6564733120"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

Try:
http://epsg.io/?q=3857&format=json&trans=1

The Yukon Albers CSRS projection, http://epsg.io/3579, has a longitudinal central meridian of 132.5W, yet the WGS84 bounds[1] extends 141W all the way to 40W. I would expect the central meridian to be, you know, central.

What does the extent rectangle actually represent?

.. allow people to switch between degrees, minutes, seconds and float representation of the latitude / longitude.

Input in these coordinates should be possible as well.

as of 2.0.0 we do proj4.defs('name', 'projString'); not proj4js.defs['name'] = 'projString';

We may switch the the faster GeoIP service from Google and fallback to FreeGeoIP service (which is now used as primary).

Details: http://blog.klokantech.com/2008/08/google-ip-geolocation.html

JSON export is going to be a conversion of XML (OGC GML) to JSON.

Use: https://github.com/hay/xml2json

like:
python xml2json.py --strip_newlines --strip_text --pretty ~/Downloads/5514.xml
on XML with removed namespaces (e.g. xlink:, epsg: lowercase!, xmlns:.*", gml:)

Example:

{
    "ProjectedCRS": {
        "@id": "ogp-crs-5514",
        "baseGeodeticCRS": {
            "@href": "urn:ogc:def:crs::4156"
        },
        "cartesianCS": {
            "@href": "urn:ogc:def:cs::4499"
        },
        "conversion": {
            "@href": "urn:ogc:def:coordinateOperation::5510"
        },
        "domainOfValidity": {
            "@href": "urn:ogc:def:area::1306"
        },
        "identifier": {
            "#text": "urn:ogc:def:crs::5514",
            "@codeSpace": "OGP"
        },
        "metaDataProperty": {
            "CommonMetaData": {
                "alias": {
                    "@alias": "S-JTSK / Krovak EN (G)",
                    "@code": "17802",
                    "@codeSpace": "urn:ogc:def:naming-system::7302",
                    "remarks": "Uses Greenwich meridian."
                },
                "changes": {
                    "changeID": {
                        "@href": "urn:ogc:def:change-request::2011.039"
                    }
                },
                "informationSource": "Land Survey Office (ZU), Prague. www.cuzk.cz/zu",
                "isDeprecated": "false",
                "revisionDate": "2011-05-09",
                "show": "true",
                "type": "projected"
            }
        },
        "name": "S-JTSK / Krovak East North",
        "remarks": "Greenwich-based alternative to S-JTSK (Ferro) / Krovak East North, CRS code 5221.",
        "scope": "GIS. Due to distortions in survey network introduced after the initial realisation the projection has an inaccuracy of several decimetres."
    }
}

for

<?xml version="1.0" encoding="UTF-8"?>
<gml:ProjectedCRS xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset"
                  xmlns:gml="http://www.opengis.net/gml/3.2"
                  xmlns:xlink="http://www.w3.org/1999/xlink"
                  gml:id="ogp-crs-5514">
   <gml:metaDataProperty>
      <epsg:CommonMetaData>
         <epsg:type>projected</epsg:type>
         <epsg:alias code="17802" codeSpace="urn:ogc:def:naming-system:EPSG::7302"
                     alias="S-JTSK / Krovak EN (G)">
            <epsg:remarks>Uses Greenwich meridian.</epsg:remarks>
         </epsg:alias>
         <epsg:informationSource>Land Survey Office (ZU), Prague. www.cuzk.cz/zu</epsg:informationSource>
         <epsg:revisionDate>2011-05-09</epsg:revisionDate>
         <epsg:changes>
            <epsg:changeID xlink:href="urn:ogc:def:change-request:EPSG::2011.039"/>
         </epsg:changes>
         <epsg:show>true</epsg:show>
         <epsg:isDeprecated>false</epsg:isDeprecated>
      </epsg:CommonMetaData>
   </gml:metaDataProperty>
   <gml:identifier codeSpace="OGP">urn:ogc:def:crs:EPSG::5514</gml:identifier>
   <gml:name>S-JTSK / Krovak East North</gml:name>
   <gml:remarks>Greenwich-based alternative to S-JTSK (Ferro) / Krovak East North, CRS code 5221.</gml:remarks>
   <gml:domainOfValidity xlink:href="urn:ogc:def:area:EPSG::1306"/>
   <gml:scope>GIS. Due to distortions in survey network introduced after the initial realisation the projection has an inaccuracy of several decimetres.</gml:scope>
   <gml:conversion xlink:href="urn:ogc:def:coordinateOperation:EPSG::5510"/>
   <gml:baseGeodeticCRS xlink:href="urn:ogc:def:crs:EPSG::4156"/>
   <gml:cartesianCS xlink:href="urn:ogc:def:cs:EPSG::4499"/>
</gml:ProjectedCRS>

.. missing.

Links to GitHub Issues & Project page - open-source project.

Credits to:

• Klokan Technologies GmbH, Switzerland
• Moravian Library in Brno (research project TEMAP.cz)
• Petr Pridal (KlokanTech + MZK, PhD candidate at Czech Technical University of Technology - Geodesy and Cartography)
• Tomas Pohanka (Internship at KlokanTech, Master degree candiate at Palacky University Olomouc - Geoinformatics)
• Radim Kacer (designer)

In the list of transformations please add behind the code" [3]", "[7]" or " [grid]".

Under the Name of the transformation, Accuracy and Code in the middle column please add "Grid shift:" and one of "3 parameters" / "7 parameters" / "Grid file" / (maybe "Other"?)

For Czech Republic, Switzerland, France and New Zealand are available grid files which would be cool to list under transformations.

These do not have records in official EPSG database.

Czech: http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid
Swiss CHENyx06: http://www.swisstopo.admin.ch/internet/swisstopo/en/home/products/software/products/chenyx06.html
New Zealand: nzgd2kgrid0005.gsb: http://help.maptiler.org/coordinates/australasia/new-zealand
France, ntf_r93: ..
Canada, ...
UK, ostn02: http://www.ordnancesurvey.co.uk/business-and-government/help-and-support/navigation-technology/os-net/ostn02-ntv2-format.html

more at http://trac.osgeo.org/proj/

It would be very useful to have the ability to do multiple transformations in one API request.

Parameters would be similar to https://github.com/klokantech/epsg.io#api-for-trans, but instead of passing x,y and z, maybe a single array could be passed (with semi-colon separating records and comma separating individual components ?:
?data=x1,y1,z1;x2,y2,z2;x3,y3;x4,y4,z5;... (with z being optional)).

This would highly optimize efficiency of certain application on both client-side (less requests) and even server-side (less requests + maybe lower overhead (shared transformation instance for multiple points))