highsource

    public int hashCode() {
        int currentHashCode = 1;
        {
            currentHashCode = (currentHashCode* 31);
            USAddress theShipTo;
            theShipTo = this.getShipTo();
            if (theShipTo!= null) {
                currentHashCode += theShipTo.hashCode();
            }
        }

highsource

<?xml version="1.0" encoding="UTF-8"?><WMS_Capabilities version="1.3.0" updateSequence="163" xmlns="http://www.opengis.net/wms" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wms http://demo.opengeo.org:80/geoserver/schemas/wms/1.3.0/capabilities_1_3_0.xsd">
  <Service>
    <Name>WMS</Name>
    <Title>OpenGeo Demo Web Map Service</Title>
    <Abstract/>
    <KeywordList>
      <Keyword>geoserver</Keyword>
      <Keyword>wms</Keyword>
    </KeywordList>

highsource

Can you talk to OGC Web Services in JSON instead of XML? You can - with Jsonix, a powerful JavaScript tool for XML <-> JSON conversion.

JSON has probably already replaced XML as a "lingua franca". JSON is much lighter and easier to use than XML, especially in JavaScript-based web apps. In the context of GIS, web mapping is dominated by JavaScript libraries like OpenLayers and Leaflet, which speak JSON natively.

But what about standards? Open Geospatial Consortium defines more than 50 specifications with more than 100 individual versions. Technically almost all of them are XML-based and defined by XML schemas. These are de jure and de facto standards, widely used and well supported. So you still need XML processing in JS web mapping apps.

Processing XML is no rocket science, but it's seldom a pleasure to implement. The OL3 KML parser is about 2.5KLoc of dense XML parsing. Even a very simple WMS GetCapabilities format is almost 1 KLOC. From this code around 90% is pure XML parsing and only 10% is the process

highsource

Feedback on Lufthansa Public API

• I liked the dev portal pretty much. Fast und pretty. API console is good for playing.
• Good API, had a lot of fun to work with. Would be glad to have such an API for DB.
• Provide OpenAPI/Swagger specifications. Otherwise it takes too much time to build a client.
• Operations are not so difficult to model, but what takes a lot of time is formulating the schema/definitions.
• Schema is pretty good, was easy to work with, not problems understanding
• The API suffers from "XML-to-JSON" conversion issues:
  • Cardinality is lost in a few places (item array vs. single item) depending on how many items we get.
    The structure is not deterministic this way.

highsource

highsource

highsource

DB OpenData

DB OpenData Portal:

• http://data.deutschebahn.com/

DB OpenData on GitHub:

• https://github.com/dbopendata/

highsource

    public boolean equals(Object object) {
        if (!(object instanceof PurchaseOrderType)) {
            return false;
        }
        if (this == object) {
            return true;
        }
        final PurchaseOrderType that = ((PurchaseOrderType) object);
        {
            USAddress leftShipTo;

highsource

<?xml version="1.0" encoding="UTF-8" standalone="no" ?><gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" creator="Graphhopper version 0.13.0" version="1.1" xmlns:gh="https://graphhopper.com/public/schema/gpx/1.1">
<metadata><copyright author="OpenStreetMap contributors"/><link href="http://graphhopper.com"><text>GraphHopper GPX</text></link><time>2019-04-25T20:00:32Z</time></metadata>
<trk><name>GraphHopper Track</name><trkseg>
<trkpt lat="52.437361" lon="13.796524"><ele>45.67</ele><time>2019-04-25T20:00:32Z</time></trkpt>
<trkpt lat="52.435749" lon="13.795112"><ele>45.4</ele><time>2019-04-25T20:00:42Z</time></trkpt>
<trkpt lat="52.435537" lon="13.795084"><ele>45.6</ele><time>2019-04-25T20:00:43Z</time></trkpt>
<trkpt lat="52.434839" lon="13.794596"><ele>46.2</ele><time>2019-04-25T20:00:48Z</time></trkpt>
<trkpt lat="52.429537" lon="13.789757"><ele>49.4</ele><time>2019-04-25T20:01:22Z</time></trkpt>
<trkpt lat="52.428229" lon="13.788665"><ele>45.8</ele><time>

highsource

Fahrplandaten unter anerkannten Open Data Lizenzen

SWU

SWU Stadtwerke Ulm/Neu-Ulm GmbH

• GTFS - offiziell, Lizenz ODbL 1.0, Zugriff muss beantragt werden

RNV