[enviroCar-discuss] Bug in BBOX API?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[enviroCar-discuss] Bug in BBOX API?

Carsten Keßler
Hi guys,

I just tried to query the API for tracks in the NYC area by bounding box. The example given at http://envirocar.github.io/enviroCar-server/api/tracks works fine:

https://envirocar.org/api/stable/tracks?bbox=7.0,51.1,7.3,52.0

If I replace the coordinates with my bounding box, I get an error, though:

https://envirocar.org/api/stable/tracks?bbox=-75.0,40.0,-73.0,41.0

Am I missing some obvious error in my request, or is the API choking on negative longitudes?

Best,
Carsten

---
Carsten Kessler – http://carsten.io
Center for Advanced Research of Spatial Information – http://carsilab.org
Department of Geography
Hunter College – CUNY

695 Park Avenue
New York, NY-10065

+1 (212) 560-3591

_______________________________________________
enviroCar-discuss mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/envirocar-discuss
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines
Reply | Threaded
Open this post in threaded view
|

Re: Bug in BBOX API?

Christian Autermann-3
On Tue, Nov 18, 2014 at 12:56 AM, Carsten Keßler
<[hidden email]> wrote:

> Hi guys,
>
> I just tried to query the API for tracks in the NYC area by bounding box.
> The example given at http://envirocar.github.io/enviroCar-server/api/tracks
> works fine:
>
> https://envirocar.org/api/stable/tracks?bbox=7.0,51.1,7.3,52.0
>
> If I replace the coordinates with my bounding box, I get an error, though:
>
> https://envirocar.org/api/stable/tracks?bbox=-75.0,40.0,-73.0,41.0
>
> Am I missing some obvious error in my request, or is the API choking on
> negative longitudes?
>

It does. Shame on me, I've fixed it[1].

[1] https://github.com/enviroCar/enviroCar-server/pull/216

--
Christian Autermann
52°North GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
Fon: +49 251 396371 - 38
Fax: +49 251 396371 - 11
Web: http://52north.org

General Managers:
Albert Remke, Andreas Wytzisk
Local Court Münster HRB 10849
_______________________________________________
enviroCar-discuss mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/envirocar-discuss
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines
Reply | Threaded
Open this post in threaded view
|

Re: Bug in BBOX API?

Carsten Keßler
Thanks a lot for the quick fix!

Btw, here’s what you get when you take a track as returned by the API and throw it into CartoDB: https://carsten.cartodb.com/viz/4d2e796c-6ec7-11e4-9c39-0e853d047bba/embed_map 

Unfortunately, the attributes of the attributes are not recognized by CartoDB,  because they are wrapped in the ‘phenomenons’ object. Have you discussed on optional GeoJSON-compliant output, that would get rid of the objects and directly attach key:value pairs for all properties to the points? This would mean getting rid of the units for the different measurements, but I guess this wouldn’t really matter for an alternative format.

Cheers,
Carsten

On Tuesday, November 18, 2014 at 04:25, Christian Autermann wrote:

On Tue, Nov 18, 2014 at 12:56 AM, Carsten Keßler
Hi guys,

I just tried to query the API for tracks in the NYC area by bounding box.
works fine:


If I replace the coordinates with my bounding box, I get an error, though:


Am I missing some obvious error in my request, or is the API choking on
negative longitudes?

It does. Shame on me, I've fixed it[1].


--
Christian Autermann
52°North GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
Fon: +49 251 396371 - 38
Fax: +49 251 396371 - 11

General Managers:
Albert Remke, Andreas Wytzisk
Local Court Münster HRB 10849


_______________________________________________
enviroCar-discuss mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/envirocar-discuss
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines
Reply | Threaded
Open this post in threaded view
|

Re: Bug in BBOX API?

Edzer Pebesma


On 11/18/2014 02:52 PM, Carsten Keßler wrote:
> Thanks a lot for the quick fix!
>
> Btw, here’s what you get when you take a track as returned by the API
> and throw it into
> CartoDB: https://carsten.cartodb.com/viz/4d2e796c-6ec7-11e4-9c39-0e853d047bba/embed_map 
>

Cool, nice, thanks!

> Unfortunately, the attributes of the attributes are not recognized by
> CartoDB,  because they are wrapped in the ‘phenomenons’ object. Have you
> discussed on optional GeoJSON-compliant output, that would get rid of
> the objects and directly attach key:value pairs for all properties to
> the points? This would mean getting rid of the units for the different
> measurements, but I guess this wouldn’t really matter for an alternative
> format.

I couldn't agree more -- this also makes reading these things in R, or
otherwise with GDAL/OGR, very cumbersome. Seems the decision is O&M
inspired, and quite un-GeoJSON-like.

It would be nice to be able to get hold of the measurement units, but a
bit over the top to give it for every single measured value. There is
also not a CRS specified for every single geometry, or a time zone for
every single time (they seem to be not specified at all), so this all is
quite inconsistent, IMO.

>
> Cheers,
> Carsten
>
> On Tuesday, November 18, 2014 at 04:25, Christian Autermann wrote:
>
>> On Tue, Nov 18, 2014 at 12:56 AM, Carsten Keßler
>> <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>> Hi guys,
>>>
>>> I just tried to query the API for tracks in the NYC area by bounding box.
>>> The example given at
>>> http://envirocar.github.io/enviroCar-server/api/tracks
>>> works fine:
>>>
>>> https://envirocar.org/api/stable/tracks?bbox=7.0,51.1,7.3,52.0
>>>
>>> If I replace the coordinates with my bounding box, I get an error,
>>> though:
>>>
>>> https://envirocar.org/api/stable/tracks?bbox=-75.0,40.0,-73.0,41.0
>>>
>>> Am I missing some obvious error in my request, or is the API choking on
>>> negative longitudes?
>>
>> It does. Shame on me, I've fixed it[1].
>>
>> [1] https://github.com/enviroCar/enviroCar-server/pull/216
>>
>> --
>> Christian Autermann
>> 52°North GmbH
>> Martin-Luther-King-Weg 24
>> 48155 Münster, Germany
>> Fon: +49 251 396371 - 38
>> Fax: +49 251 396371 - 11
>> Web: http://52north.org
>>
>> General Managers:
>> Albert Remke, Andreas Wytzisk
>> Local Court Münster HRB 10849
>
>
>
> _______________________________________________
> enviroCar-discuss mailing list
> [hidden email]
> http://list.52north.org/mailman/listinfo/envirocar-discuss
> Please respect our mailing list guidelines:
> http://52north.org/resources/mailing-lists-and-forums/guidelines
>
--
Edzer Pebesma,  Co-Editor-in-Chief Computers & Geosciences
Institute for Geoinformatics (ifgi), University of Münster
Heisenbergstraße 2, 48149 Münster, Germany. Phone: +49 251
83 33081 http://ifgi.uni-muenster.de GPG key ID 0xAC227795


_______________________________________________
enviroCar-discuss mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/envirocar-discuss
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in BBOX API?

Christian Autermann-3
On Tue, Nov 18, 2014 at 3:38 PM, Edzer Pebesma
<[hidden email]> wrote:

> On 11/18/2014 02:52 PM, Carsten Keßler wrote:
>>
>> Unfortunately, the attributes of the attributes are not recognized by
>> CartoDB,  because they are wrapped in the ‘phenomenons’ object. Have you
>> discussed on optional GeoJSON-compliant output, that would get rid of
>> the objects and directly attach key:value pairs for all properties to
>> the points? This would mean getting rid of the units for the different
>> measurements, but I guess this wouldn’t really matter for an alternative
>> format.
>
> I couldn't agree more -- this also makes reading these things in R, or
> otherwise with GDAL/OGR, very cumbersome. Seems the decision is O&M
> inspired, and quite un-GeoJSON-like.
>

Its really redundant to include the UOM. During the course there was a
request to include them [2], because it was more 'convenient' for the
website to get them directly from the tracks and measurements, instead
of requesting the /phenomenons resource…

Besides GeoJSON does not enforce any rules on the structure of the
properties object [1]. It's perfectly legal GeoJSON, most tools just
do not support it. That said, I'm still in strong favor to encapsulate
the values in a phenomenons object, else the properties become quite
messy due to user-defined and system properties intermixed. But that's
just my opinion and we can discuss that for a possible v2 encoding…

>
> It would be nice to be able to get hold of the measurement units, but a
> bit over the top to give it for every single measured value. There is
> also not a CRS specified for every single geometry, or a time zone for
> every single time (they seem to be not specified at all), so this all is
> quite inconsistent, IMO.
>

The GeoJSON spec does not require a CRS for coordinates if they are in
the default EPSG:4326 [3]. It's common practice to omit it in this
case. Also, a time zone is included for every single time stamp: they
are all in UTC (expressed as a 'Z').

[1] http://geojson.org/geojson-spec.html#feature-objects
[2] https://github.com/enviroCar/enviroCar-server/issues/27
[3] http://geojson.org/geojson-spec.html#coordinate-reference-system-objects

--
Christian Autermann
52°North GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
Fon: +49 251 396371 - 38
Fax: +49 251 396371 - 11
Web: http://52north.org

General Managers:
Albert Remke, Andreas Wytzisk
Local Court Münster HRB 10849
_______________________________________________
enviroCar-discuss mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/envirocar-discuss
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines
Reply | Threaded
Open this post in threaded view
|

Re: Bug in BBOX API?

Edzer Pebesma
Thank you for pointing me to the meaning of the "Z" in the time stamp!

I don't think anyone argued the GeoJSON was invalid, we only argued it
is quite useless: another example where there is the formal standard on
one hand, and there is what people do and software supports on the
other. I suggest to make a useful one into the default encoding, and
provide the other (current) one as "v0" (old, mistake) for back
compatibility. Envirocar has much more future ahead of it than it has
past behind it!

On 11/18/2014 05:35 PM, Christian Autermann wrote:

> On Tue, Nov 18, 2014 at 3:38 PM, Edzer Pebesma
> <[hidden email]> wrote:
>> On 11/18/2014 02:52 PM, Carsten Keßler wrote:
>>>
>>> Unfortunately, the attributes of the attributes are not recognized by
>>> CartoDB,  because they are wrapped in the ‘phenomenons’ object. Have you
>>> discussed on optional GeoJSON-compliant output, that would get rid of
>>> the objects and directly attach key:value pairs for all properties to
>>> the points? This would mean getting rid of the units for the different
>>> measurements, but I guess this wouldn’t really matter for an alternative
>>> format.
>>
>> I couldn't agree more -- this also makes reading these things in R, or
>> otherwise with GDAL/OGR, very cumbersome. Seems the decision is O&M
>> inspired, and quite un-GeoJSON-like.
>>
>
> Its really redundant to include the UOM. During the course there was a
> request to include them [2], because it was more 'convenient' for the
> website to get them directly from the tracks and measurements, instead
> of requesting the /phenomenons resource…
>
> Besides GeoJSON does not enforce any rules on the structure of the
> properties object [1]. It's perfectly legal GeoJSON, most tools just
> do not support it. That said, I'm still in strong favor to encapsulate
> the values in a phenomenons object, else the properties become quite
> messy due to user-defined and system properties intermixed. But that's
> just my opinion and we can discuss that for a possible v2 encoding…
>
>>
>> It would be nice to be able to get hold of the measurement units, but a
>> bit over the top to give it for every single measured value. There is
>> also not a CRS specified for every single geometry, or a time zone for
>> every single time (they seem to be not specified at all), so this all is
>> quite inconsistent, IMO.
>>
>
> The GeoJSON spec does not require a CRS for coordinates if they are in
> the default EPSG:4326 [3]. It's common practice to omit it in this
> case. Also, a time zone is included for every single time stamp: they
> are all in UTC (expressed as a 'Z').
>
> [1] http://geojson.org/geojson-spec.html#feature-objects
> [2] https://github.com/enviroCar/enviroCar-server/issues/27
> [3] http://geojson.org/geojson-spec.html#coordinate-reference-system-objects
>
> --
> Christian Autermann
> 52°North GmbH
> Martin-Luther-King-Weg 24
> 48155 Münster, Germany
> Fon: +49 251 396371 - 38
> Fax: +49 251 396371 - 11
> Web: http://52north.org
>
> General Managers:
> Albert Remke, Andreas Wytzisk
> Local Court Münster HRB 10849
> _______________________________________________
> enviroCar-discuss mailing list
> [hidden email]
> http://list.52north.org/mailman/listinfo/envirocar-discuss
> Please respect our mailing list guidelines:
> http://52north.org/resources/mailing-lists-and-forums/guidelines
>
--
Edzer Pebesma,  Co-Editor-in-Chief Computers & Geosciences
Institute for Geoinformatics (ifgi), University of Münster
Heisenbergstraße 2, 48149 Münster, Germany. Phone: +49 251
83 33081 http://ifgi.uni-muenster.de GPG key ID 0xAC227795


_______________________________________________
enviroCar-discuss mailing list
[hidden email]
http://list.52north.org/mailman/listinfo/envirocar-discuss
Please respect our mailing list guidelines:
http://52north.org/resources/mailing-lists-and-forums/guidelines

signature.asc (501 bytes) Download Attachment