You are viewing a plain text version of this content. The canonical link for it is here.
Posted to zeta-dev@incubator.apache.org by Henri Bergius <be...@apache.org> on 2010/11/24 12:03:28 UTC
[zeta-dev] Proposal: Location component
Hi,
As discussed in my introduction thread[1], I'd like to propose for the
Midgard MVC location library[2] to be contributed to the Zeta
Components stack as a new components. As a first step, here are the
initial requirements for a location library.
Introduction
============
The purpose of this library is to make it easier for PHP developers to
work with geolocation. Geolocation is one of the emerging trends in
web development, with new possibilities rising from browser
geolocation support. This library focuses on dealing with actual
real-world locations and relations between them, not with map
visualization.
Requirements
============
In the initial version the location library should only deal with
geolocated points. To build full geoinformation systems there will be
need for lines, connections and areas, but these can be added in later
iterations of the library. The library should provide the following
services:
Spot
----
A spot is an actual location on a map. This consists of WGS-84
latitude and longitude. Optionally spots may have an altitude,
timestamp, accuracy and a human-readable description.
Spot should also be able to calculate distance and direction to other
spots, and to provide a bounding box around them at a given radius.
For display purposes spots also need to provide a way to convert them
to pretty-printed human-readable coordinates.
Geocoding
---------
Geocoding is a service for converting human-readable locations to
actual coordinates (spots). There should be an interface for geocoding
utilizing various online geocoding services like GeoNames and
OpenStreetMap Nominatim. Users of the component should be able to
create their own geocoding service implementations.
Reverse geocoding
-----------------
Reverse geocoding is a service for converting actual coordinates
(spots) into human-readable locations. There should be an interface
for reverse geocoding utilizing various online geocoding services like
GeoNames and OpenStreetMap Nominatim. Users of the component should be
able to create their own reverse geocoding service implementations.
IP geocoding
------------
IP geocoding is a service for converting an IP address to an
approximate geographical location of the network. This can be used to
locate users of a website for instance, in cases where browser
geolocationing is not possible. The IP geocoding interface should be
able to talk to at least HostIP web service to perform geocoding.
1: http://mail-archives.apache.org/mod_mbox/incubator-zeta-dev/201011.mbox/%3CAANLkTi=2J_VHBrmc3x55eKkJOJwTuq-=9dDMs0zvnX-K@mail.gmail.com%3E
2: https://github.com/bergie/midgardmvc_helper_location
Re: [zeta-dev] Proposal: Location component
Posted by Martin Holzhauer <ma...@holzhauer.eu>.
are there any news about the geo stuff?
i would really love to use this
On Wed, Dec 1, 2010 at 9:32 PM, Martin Holzhauer <ma...@holzhauer.eu> wrote:
> On Tue, Nov 30, 2010 at 5:08 PM, Henri Bergius <be...@apache.org> wrote:
>> Hi,
>>
>> On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans <de...@apache.org> wrote:
>>> You surely would like to call this a "point" instead? Also, are you
>>> thinking of only doing WGS-84 here?
>>
>> WGS-84 only for now. But agreed, Point makes more sense.
>
> maybe reference systems should be added as own area
> but a given reference system could be used internally and
> recalculated on getting and setting
>
> i would prefer UTM as this "internal" reference system
>
>>
>>> "Bounding box at a radius" ... that doesn't make sense. A box is not a
>>> circle :P
>>
>> True, not the best wording there. The edges of the bbox are at the end
>> of the radius.
>>
>>> All of those services provide information in a slightly different way
>>> though. Especially with admin-levels. There ought to be an abstraction
>>> for this.
>>
>> Certainly.
>>
>>> - Obtaining the location through Google's geolocation services:
>>> http://talks.php.net/show/maps-afup10/18 and
>>> http://talks.php.net/show/maps-ipc10/22 (by providing ssid/mac
>>> addresses).
>>> - Skyhook also provides an interface.
>>
>> Sure, why not. Maybe not in the initial version but would make sense
>> to add. There are some special scenarios where talking to GeoClue
>> would also make sense.
>>
>>> Derick
>>
>> /Henri
>>
>
> my other ideas for this component would be
>
> - Create a Point with all 3 axes latitude, longiutude and altitude and
> a reference
> system. EPSG Codes should be used for this
> - Create Lines based on Points
> - Create Shapes based on Points
> - Wotking with differnet reference systems (support for EPSG Codes ,
> Proj4 Support)
> - Convert Points between differnt reference systems
> - Working with formats like GeoRSS, GeoJSON, GPX and KML
> - Tiein for Databases with GIS Support
> - Tiein for Databases without GIS Support
>
>
>
> Links:
> http://trac.osgeo.org/proj/
> http://spatialreference.org/
> http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system
> http://proj4js.org/
> http://www.openlayers.org/
> http://www.epsg-registry.org/
>
>
> --
> Mit freundlichen Grüßen,
>
> Martin Holzhauer
> https://www.xing.com/profile/Martin_Holzhauer
> http://de.linkedin.com/in/martinholzhauer
> System-Entwickler
>
> Diese Mail ist weder Vertraulich noch Geheim, auf ihrem Weg zu ihnen
> wurde sie von der NSA, dem FBI,
> der CIA und dem BND gescannt, auf verbrecherischen Inhalt überprüft
> und an sie weitergeleitet.
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS d-- s:+ a- C++ UL++ P--- L++ E---- W+++ N o K- w
> O---- M-- V- PS+ PE Y PGP t+++ 5+ X R tv++ b+ DI+ D-
> G e h r+ y+
> ------END GEEK CODE BLOCK------
>
--
Mit freundlichen Grüßen,
Martin Holzhauer
https://www.xing.com/profile/Martin_Holzhauer
http://de.linkedin.com/in/martinholzhauer
System-Entwickler
Diese Mail ist weder Vertraulich noch Geheim, auf ihrem Weg zu ihnen
wurde sie von der NSA, dem FBI,
der CIA und dem BND gescannt, auf verbrecherischen Inhalt überprüft
und an sie weitergeleitet.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d-- s:+ a- C++ UL++ P--- L++ E---- W+++ N o K- w
O---- M-- V- PS+ PE Y PGP t+++ 5+ X R tv++ b+ DI+ D-
G e h r+ y+
------END GEEK CODE BLOCK------
Re: [zeta-dev] Proposal: Location component
Posted by Martin Holzhauer <ma...@holzhauer.eu>.
On Tue, Nov 30, 2010 at 5:08 PM, Henri Bergius <be...@apache.org> wrote:
> Hi,
>
> On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans <de...@apache.org> wrote:
>> You surely would like to call this a "point" instead? Also, are you
>> thinking of only doing WGS-84 here?
>
> WGS-84 only for now. But agreed, Point makes more sense.
maybe reference systems should be added as own area
but a given reference system could be used internally and
recalculated on getting and setting
i would prefer UTM as this "internal" reference system
>
>> "Bounding box at a radius" ... that doesn't make sense. A box is not a
>> circle :P
>
> True, not the best wording there. The edges of the bbox are at the end
> of the radius.
>
>> All of those services provide information in a slightly different way
>> though. Especially with admin-levels. There ought to be an abstraction
>> for this.
>
> Certainly.
>
>> - Obtaining the location through Google's geolocation services:
>> http://talks.php.net/show/maps-afup10/18 and
>> http://talks.php.net/show/maps-ipc10/22 (by providing ssid/mac
>> addresses).
>> - Skyhook also provides an interface.
>
> Sure, why not. Maybe not in the initial version but would make sense
> to add. There are some special scenarios where talking to GeoClue
> would also make sense.
>
>> Derick
>
> /Henri
>
my other ideas for this component would be
- Create a Point with all 3 axes latitude, longiutude and altitude and
a reference
system. EPSG Codes should be used for this
- Create Lines based on Points
- Create Shapes based on Points
- Wotking with differnet reference systems (support for EPSG Codes ,
Proj4 Support)
- Convert Points between differnt reference systems
- Working with formats like GeoRSS, GeoJSON, GPX and KML
- Tiein for Databases with GIS Support
- Tiein for Databases without GIS Support
Links:
http://trac.osgeo.org/proj/
http://spatialreference.org/
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system
http://proj4js.org/
http://www.openlayers.org/
http://www.epsg-registry.org/
--
Mit freundlichen Grüßen,
Martin Holzhauer
https://www.xing.com/profile/Martin_Holzhauer
http://de.linkedin.com/in/martinholzhauer
System-Entwickler
Diese Mail ist weder Vertraulich noch Geheim, auf ihrem Weg zu ihnen
wurde sie von der NSA, dem FBI,
der CIA und dem BND gescannt, auf verbrecherischen Inhalt überprüft
und an sie weitergeleitet.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d-- s:+ a- C++ UL++ P--- L++ E---- W+++ N o K- w
O---- M-- V- PS+ PE Y PGP t+++ 5+ X R tv++ b+ DI+ D-
G e h r+ y+
------END GEEK CODE BLOCK------
Re: [zeta-dev] Proposal: Location component
Posted by Henri Bergius <be...@apache.org>.
Hi,
On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans <de...@apache.org> wrote:
> You surely would like to call this a "point" instead? Also, are you
> thinking of only doing WGS-84 here?
WGS-84 only for now. But agreed, Point makes more sense.
> "Bounding box at a radius" ... that doesn't make sense. A box is not a
> circle :P
True, not the best wording there. The edges of the bbox are at the end
of the radius.
> All of those services provide information in a slightly different way
> though. Especially with admin-levels. There ought to be an abstraction
> for this.
Certainly.
> - Obtaining the location through Google's geolocation services:
> http://talks.php.net/show/maps-afup10/18 and
> http://talks.php.net/show/maps-ipc10/22 (by providing ssid/mac
> addresses).
> - Skyhook also provides an interface.
Sure, why not. Maybe not in the initial version but would make sense
to add. There are some special scenarios where talking to GeoClue
would also make sense.
> Derick
/Henri
Re: [zeta-dev] Proposal: Location component
Posted by Derick Rethans <de...@apache.org>.
On Wed, 24 Nov 2010, Henri Bergius wrote:
> Spot
> ----
> A spot is an actual location on a map. This consists of WGS-84
> latitude and longitude. Optionally spots may have an altitude,
> timestamp, accuracy and a human-readable description.
You surely would like to call this a "point" instead? Also, are you
thinking of only doing WGS-84 here?
> Spot should also be able to calculate distance and direction to other
> spots, and to provide a bounding box around them at a given radius.
"Bounding box at a radius" ... that doesn't make sense. A box is not a
circle :P
> Geocoding
> ---------
> Geocoding is a service for converting human-readable locations to
> actual coordinates (spots). There should be an interface for geocoding
> utilizing various online geocoding services like GeoNames and
> OpenStreetMap Nominatim. Users of the component should be able to
> create their own geocoding service implementations.
>
> Reverse geocoding
> -----------------
> Reverse geocoding is a service for converting actual coordinates
> (spots) into human-readable locations. There should be an interface
> for reverse geocoding utilizing various online geocoding services like
> GeoNames and OpenStreetMap Nominatim. Users of the component should be
> able to create their own reverse geocoding service implementations.
All of those services provide information in a slightly different way
though. Especially with admin-levels. There ought to be an abstraction
for this.
> IP geocoding
> ------------
> IP geocoding is a service for converting an IP address to an
> approximate geographical location of the network. This can be used to
> locate users of a website for instance, in cases where browser
> geolocationing is not possible. The IP geocoding interface should be
> able to talk to at least HostIP web service to perform geocoding.
>
> 1: http://mail-archives.apache.org/mod_mbox/incubator-zeta-dev/201011.mbox/%3CAANLkTi=2J_VHBrmc3x55eKkJOJwTuq-=9dDMs0zvnX-K@mail.gmail.com%3E
> 2: https://github.com/bergie/midgardmvc_helper_location
I am missing a few other location things that would also make sense:
- Obtaining the location through Google's geolocation services:
http://talks.php.net/show/maps-afup10/18 and
http://talks.php.net/show/maps-ipc10/22 (by providing ssid/mac
addresses).
- Skyhook also provides an interface.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Location component
Posted by Henri Bergius <be...@apache.org>.
Hi,
On Thu, Nov 25, 2010 at 7:32 PM, Tobias Schlitt <to...@schlitt.info> wrote:
> I'm not sure if it is a good thing to couple additional data to a spot
> from scratch. Wouldn't it be better to keep this part open to the user,
> so that he can extend it to fit his needs?
User can of course implement another way to represent locations, but
there is a quite standard DMS representation that I feel should be
provided by the library. Internally the library keeps all coordinates
in DD system. Third thing we should probably support is DM. All
coordinates we handle are in WGS-84.
http://www.sunearthtools.com/dp/tools/conversion.php
>> Geocoding is a service for converting human-readable locations to
>> actual coordinates (spots).
> I'm not sure, if the service based stuff fits into a base component,
> depending on its focus. I would imagine that the pure Location component
> should only deal with mathematical representations of geo-data and maybe
> leave the geo coding parts to a tiein.
Geocoding could be a tiein, but generally it is quite a common part of
geolocation services on other platforms. I'm sort of following GeoClue
as the "reference implementation" here:
http://en.wikipedia.org/wiki/GeoClue
I would draw parallels between different geocoding services supported
in this component and for example different feed modules in the Feed
component.
> AFAIK Derick has also experience in the geo location area from his
> latest work with OSM. So I CC him explicitly to get involved here.
Great! Additional contributions and ideas are certainly welcome here.
That is after all the whole point of moving the geolocation
functionality from Midgard to the wider PHP ecosystem :-)
> Toby
/Henri
Re: [zeta-dev] Proposal: Location component
Posted by Henri Bergius <be...@apache.org>.
On Fri, Nov 26, 2010 at 4:08 PM, Derick Rethans <de...@apache.org> wrote:
> Additional data in OSM land are called "tags". Which can be on: nodes
> (points), ways/areas as well as on relations. I think it'd be a good
> idea to try to follow their data model, so that the points we have can
> be easily used with (or extracted from) OSM data.
Agreed, again.
> If you want to the maths, things get a lot more complicated. THen you
> need to deal with different projections and coordinate systems and
> conversions as well. I would like to see something like that, but I'd
> rather have that in an extension as it can be quite slow.
This area can be expanded quite a bit, but I'd propose starting with
functionality that practically any web application dealing with
geolocation needs.
> Derick
/Henri
Re: [zeta-dev] Proposal: Location component
Posted by Derick Rethans <de...@apache.org>.
On Thu, 25 Nov 2010, Tobias Schlitt wrote:
> On 11/24/2010 01:03 PM, Henri Bergius wrote:
> > Spot
> > ----
> > A spot is an actual location on a map. This consists of WGS-84
> > latitude and longitude. Optionally spots may have an altitude,
> > timestamp, accuracy and a human-readable description.
> >
> > Spot should also be able to calculate distance and direction to other
> > spots, and to provide a bounding box around them at a given radius.
> >
> > For display purposes spots also need to provide a way to convert them
> > to pretty-printed human-readable coordinates.
>
> I'm not sure if it is a good thing to couple additional data to a spot
> from scratch. Wouldn't it be better to keep this part open to the user,
> so that he can extend it to fit his needs?
Additional data in OSM land are called "tags". Which can be on: nodes
(points), ways/areas as well as on relations. I think it'd be a good
idea to try to follow their data model, so that the points we have can
be easily used with (or extracted from) OSM data.
> I'm not sure, if the service based stuff fits into a base component,
> depending on its focus. I would imagine that the pure Location component
> should only deal with mathematical representations of geo-data and maybe
> leave the geo coding parts to a tiein.
If you want to the maths, things get a lot more complicated. THen you
need to deal with different projections and coordinate systems and
conversions as well. I would like to see something like that, but I'd
rather have that in an extension as it can be quite slow.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Location component
Posted by Tobias Schlitt <to...@schlitt.info>.
Hi Henri,
thanks for your proposal.
On 11/24/2010 01:03 PM, Henri Bergius wrote:
> Introduction
> ============
> The purpose of this library is to make it easier for PHP developers to
> work with geolocation. Geolocation is one of the emerging trends in
> web development, with new possibilities rising from browser
> geolocation support. This library focuses on dealing with actual
> real-world locations and relations between them, not with map
> visualization.
> Requirements
> ============
> In the initial version the location library should only deal with
> geolocated points. To build full geoinformation systems there will be
> need for lines, connections and areas, but these can be added in later
> iterations of the library. The library should provide the following
> services:
> Spot
> ----
> A spot is an actual location on a map. This consists of WGS-84
> latitude and longitude. Optionally spots may have an altitude,
> timestamp, accuracy and a human-readable description.
>
> Spot should also be able to calculate distance and direction to other
> spots, and to provide a bounding box around them at a given radius.
>
> For display purposes spots also need to provide a way to convert them
> to pretty-printed human-readable coordinates.
I'm not sure if it is a good thing to couple additional data to a spot
from scratch. Wouldn't it be better to keep this part open to the user,
so that he can extend it to fit his needs?
> Geocoding
> ---------
> Geocoding is a service for converting human-readable locations to
> actual coordinates (spots). There should be an interface for geocoding
> utilizing various online geocoding services like GeoNames and
> OpenStreetMap Nominatim. Users of the component should be able to
> create their own geocoding service implementations.
> Reverse geocoding
> -----------------
> Reverse geocoding is a service for converting actual coordinates
> (spots) into human-readable locations. There should be an interface
> for reverse geocoding utilizing various online geocoding services like
> GeoNames and OpenStreetMap Nominatim. Users of the component should be
> able to create their own reverse geocoding service implementations.
> IP geocoding
> ------------
> IP geocoding is a service for converting an IP address to an
> approximate geographical location of the network. This can be used to
> locate users of a website for instance, in cases where browser
> geolocationing is not possible. The IP geocoding interface should be
> able to talk to at least HostIP web service to perform geocoding.
I'm not sure, if the service based stuff fits into a base component,
depending on its focus. I would imagine that the pure Location component
should only deal with mathematical representations of geo-data and maybe
leave the geo coding parts to a tiein.
What do you and the others think?
AFAIK Derick has also experience in the geo location area from his
latest work with OSM. So I CC him explicitly to get involved here.
Regards,
Toby
--
Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14
Want to hire me? Need quality assurance? http://qafoo.com
eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Location component
Posted by Henri Bergius <be...@apache.org>.
Hi,
On Fri, Nov 26, 2010 at 7:45 AM, Christian Grobmeier
<gr...@gmail.com> wrote:
> this component is currently GPL code. This is not compatible with the
> AL. Will this change?
> Are you the sole copyright holder for this component?
Any code we submit to Zeta will of course have its copyrights
transferred to ASF, and licensing changed to ASL. In cases where I'm
not the sole owner we will handle the necessary CLAs with the other
participants.
> Christian
/Henri
Re: [zeta-dev] Proposal: Location component
Posted by Christian Grobmeier <gr...@gmail.com>.
Hello,
this component is currently GPL code. This is not compatible with the
AL. Will this change?
Are you the sole copyright holder for this component?
Cheers
Christian
On Wed, Nov 24, 2010 at 1:03 PM, Henri Bergius <be...@apache.org> wrote:
> Hi,
>
> As discussed in my introduction thread[1], I'd like to propose for the
> Midgard MVC location library[2] to be contributed to the Zeta
> Components stack as a new components. As a first step, here are the
> initial requirements for a location library.
>
> Introduction
> ============
> The purpose of this library is to make it easier for PHP developers to
> work with geolocation. Geolocation is one of the emerging trends in
> web development, with new possibilities rising from browser
> geolocation support. This library focuses on dealing with actual
> real-world locations and relations between them, not with map
> visualization.
>
> Requirements
> ============
> In the initial version the location library should only deal with
> geolocated points. To build full geoinformation systems there will be
> need for lines, connections and areas, but these can be added in later
> iterations of the library. The library should provide the following
> services:
>
> Spot
> ----
> A spot is an actual location on a map. This consists of WGS-84
> latitude and longitude. Optionally spots may have an altitude,
> timestamp, accuracy and a human-readable description.
>
> Spot should also be able to calculate distance and direction to other
> spots, and to provide a bounding box around them at a given radius.
>
> For display purposes spots also need to provide a way to convert them
> to pretty-printed human-readable coordinates.
>
> Geocoding
> ---------
> Geocoding is a service for converting human-readable locations to
> actual coordinates (spots). There should be an interface for geocoding
> utilizing various online geocoding services like GeoNames and
> OpenStreetMap Nominatim. Users of the component should be able to
> create their own geocoding service implementations.
>
> Reverse geocoding
> -----------------
> Reverse geocoding is a service for converting actual coordinates
> (spots) into human-readable locations. There should be an interface
> for reverse geocoding utilizing various online geocoding services like
> GeoNames and OpenStreetMap Nominatim. Users of the component should be
> able to create their own reverse geocoding service implementations.
>
> IP geocoding
> ------------
> IP geocoding is a service for converting an IP address to an
> approximate geographical location of the network. This can be used to
> locate users of a website for instance, in cases where browser
> geolocationing is not possible. The IP geocoding interface should be
> able to talk to at least HostIP web service to perform geocoding.
>
> 1: http://mail-archives.apache.org/mod_mbox/incubator-zeta-dev/201011.mbox/%3CAANLkTi=2J_VHBrmc3x55eKkJOJwTuq-=9dDMs0zvnX-K@mail.gmail.com%3E
> 2: https://github.com/bergie/midgardmvc_helper_location
>
--
http://www.grobmeier.de