Re: [zeta-dev] Proposal: Location component
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 wrote: > On Tue, Nov 30, 2010 at 5:08 PM, Henri Bergius wrote: >> Hi, >> >> On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans 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
On Tue, Nov 30, 2010 at 5:08 PM, Henri Bergius wrote: > Hi, > > On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans 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
On Fri, Nov 26, 2010 at 4:08 PM, Derick Rethans 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
Hi, On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans 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
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
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-=9ddms0zvn...@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
Hi, On Fri, Nov 26, 2010 at 7:45 AM, Christian Grobmeier 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
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 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-=9ddms0zvn...@mail.gmail.com%3e > 2: https://github.com/bergie/midgardmvc_helper_location > -- http://www.grobmeier.de
Re: [zeta-dev] Proposal: Location component
Hi, On Thu, Nov 25, 2010 at 7:32 PM, Tobias Schlitt 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
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 Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn