Written in perl, MHonArc has some pretty nifty features I forgot to mention including support for MIME (smtp attachments) that you want to include in your archives allowing you to include images, audio, video, etc., that can be accessed via a browser. In our case, sendmail was typically the stmp server and if I recall correctly it can be configured relatively easily to archive with MHonArc right from within the sendmail.cfg.
I don't know if MHonArc is still being actively developed, but ListServ (my fav) has a decent web managment interface and MHonArc does a nice job of archiving posts in any number of methods. We implemented this in the day at Bell Labs for any number of internal mail lists (Bell Labs 'had' a lot of internal mail list activity).
OGC is a bit more than Refractions. Paul was a relative late comer to the party. When OGC first started in '94 there were very few of us. Dave Schell, Fred Limp, John Davidson (I was @Genasys) and a few others.. I don't believe Refractions was even formed until '98 and Postgis, their first entry into the open geospatial world wasn't released until 2001. Today, OGC has about 490 members, most of them companies, though a few individuals.
After digging a bit deeper, now I see what you're saying, HOWEVER, this small scale development effort (1 developer, 12 followers) is apparently only available for SQL 2005 because only 2005 supports.NET CLR integration.
As someone that has been building spatial apps for 20 years, that means run away as fast as you can. Additionally, there is zero support for this implementation and OGC still doesn't recognize it. If I had a bunch of extra time and SQL Server '05 hanging around I might try it sometime, but in a production environment...? Why bother? Refractions offers great support and PostGIS is so widely used, there is a large user base to draw from.
I suspect your one of the developers for this project and commend you for the effort, but I have to ask "why" build an open source implementation on a closed platform?
According to OGC's list of compliant products, no Microsoft products comply with the Simple Features: Types and Functions v.1.1 specification... http://www.opengeospatial.org/resource/products/byspec...regardless what codeplex says. OGC has a fairly rigorous specifications test.
MS SQL does not adhere to the OGC's (Open Geospatial Consortium) Types & Features v. 1.1 specification. If you're serious about storing spatial data in an RDBMS it should adhere to that standard. Highly recommend staying away from SQL Server unless you're willing to invest in ESRI's SDE app server, and with PostgreSQL/PostGIS why even bother?
I've been doing geospatial development since 1992 when Genasys (defunct) released the worlds first web mapping server, Web Broker (ESRI's IMS wasn't released until 5 years later). At the time the only COTS option for managing spatial data within an RDBMS was Sybase's Spatial Query Server, which provided slightly more geometry options inherent within MySQL today. MySQL geometry features should be considered primitive at best, far from a full-featured implementation. On the other hand, PostGIS, is full featured and the only open source implementation I know of that adheres to the Open Geospatial Consortium's 'Simple Features: Types and Functions 1.1' specification. It is very robust, scales well (in contrast to MS SQL) and you can't beat the price or ease-of-mind that comes with being licensed under v.2 of the GPL. Additionally, on comparable hardware, in terms of reliability, performance, and cost effectiveness, there is no comparison, regardless whether your using Oracle w/Spatial or MS SQL and ESRI's SDE.
Your developers, as good of guys at heart as they may be, should stay away from the kool aid for awhile
What ever became of this tablet? It was so hyped this time last year and would still seem to be the most feature-rich of all the tablets with its transflective display, 185 degree swivel camera, full HDMI, etc.
As is UMN's MapServer, with a fully open source (GPL-like) license. http://mapserver.org/
For a nice and robust GPL'd mapping client that can pull data from MapServer, as well as many other sources, see QGis. http://www.qgis.org/
For a full-featured GIS agent with GPL'd license that can also pull date from MapServer see GRASS. http://grass.osgeo.org/
Another cool open source geographical application is PostGIS, a spatial data server for PostgreSQL that interfaces with all of the above. http://postgis.refractions.net/
Assuming you're referring to ESRI, (Environment Systems Research Institute), labeling them the 'top GIS company' is highly subjective. There are IMO many better platforms out there, open source included (see GRASS and/or QGIS). They just were lucky enough to secure some significant clients early on (USGS, USFS, USFWS, USDoI, DoD, NGS, etc.), which it turn forced all their subcontractors to adopt the same platform. Their software is bloated, cumbersome, about a decade behind emerging technologies, i.e., like Google Earth, and has a very closed architecture when it comes to integration.
And yet China continues to be a preferred trade partner to the "free" world. What the hell does this even mean anymore? They poison our children with first lead, then cadmium laced jewellery, they hack our networks an infest them with malware/spyware, force labor upon their own children, yet they are our "friends" because we can buy their crap for cheap and sell it at Walmart.
Isn't it time to reevaluate our trade partner status with this country that is set on deceiving us with every opportunity they get?
It is far past time to stop free trade agreements with countries of repressive governments. They are destroying the economies of the rest of the world.
One of the most spiritually uplifting documentaries I have ever seen, The Wild Parrots of Telegraph Hill, by Judy Irving, shows in great hilarity one of the films stars, Connor, a Red Crown Conure, dancing to the music of Mark Bitner, the main character and un-official steward of Telegraph Hill's wild parrot population. An absolute must see film, at least if you like movies that leave you feeling good.
LL is selling a 'gaming experience', not photos and particularly not of photos of TM products. 2nd, I would think some element of 'fair use' would come into play here. At what point will park bench designers, fashion designers, civil engineers, etc., not want a piece of LL's profits? I see a USSC ruling all over this one. Perhaps even a constitutional amendment addressing virtual worlds.
Since many folks use their usb devices as backup media, it should be noted since fat32 has a file size limitation of about 4gb, fat32 is not an option if you wish to use MS Backup utility to create backup images larger than that.
The problem with this is the "so many standards to chose from" scenario. There are numerous applications available, many of them open source, (OpeNDAP, GDAL, PostGIS, DODS, etc.), that can read from and write to the plethora of geospatial data interfaces available. GE appears to be written to do just that from some limited finite number of these data interfaces, albeit, if one of the above posts is correct, using Frank Warmerdam's Geographic Data Abstraction Layer (GDAL) library. Gaia was obviously written specifically to query and retrieve data just from GE. Not much point in writing an API that does exactly what GDAL does.
I've worked for both imaging vendors identified in this thread, specifically on the technical aspects of their imaging servers, and I understand their need to protect their investment(s). As a consumer of, and general hobbyist in the use of geospatial information, I'm also appreciative of Google for having done the incredible job they have with Google Earth, which is what prompted me to post the story originally. However, denying a third party API access to the same information that the Google API provides seems to border on what is fair use and what isn't. Either the data is available for free to the world via TCP or it isn't. Google, and the data vendors had a choice to NOT make the data available to the world for free. They chose to make it free. The fact that Google entered into an agreement to lease data from the vendors so they could push it to the world without charge doesn't change the fact that they did. If in fact the restrictions for reusing the imagery is written into the Google API, than they same caveat needs to be included in the GPL's API.
As far as I understand the GPL, it only protects the source code of the application, not the data it uses. Just because GIMP can manipulate proprietary imagery, doesn't put GIMP at risk of violating some proprietary license agreement. That accountability comes at the risk of the user of the software, not the GIMP developers. The same premise should hold true here.
Watermarking is a process that happens when imagery is pulled from the image server, likely JPEG 2000, and occurs regardless whether the imagery was requested with the Google Earth application, the Google Earth API, or any other API that knows how to request imagery from the image server. The imaging server application is likely either written using ER Mapper's ECW JPEG 2000 SDK (a GPL-like open source license for images under 500mb - i.e., Google Earth images) or LizardTech's MrSID proprietary server. I'm guessing unless Google wrote their own imaging server, they chose ER Mapper's (I would), it's more flexible and written to JPEG 2000 standards.
RIAA and MPAA don't have proprietary API offerings to access their (owned, leased or otherwise) data. Google does. An oss API is competing for users of the proprietary Google API.
On the other hand, not having seen the Google API EULA, I'm guessing it explicitly defines what is fair re-use of the 3rd party vendor's data. Couldn't an oss API have the same type of vernacular in its EULA? I suppose this might be contstrued as extending the GPL (or whatever license Gaia was using), but this component/extension would be explicitly limited to the reuse of the data (not the API), indemnifying Gaia from improper use of 3rd party data from anyone that were to use the Gaia API. I'm fairly confident this is similar to what Google says in their EULA.
It would be interesting to read the Google Earth API EULA.
Slashdot Mirror
Microsoft Linux
Written in perl, MHonArc has some pretty nifty features I forgot to mention including support for MIME (smtp attachments) that you want to include in your archives allowing you to include images, audio, video, etc., that can be accessed via a browser. In our case, sendmail was typically the stmp server and if I recall correctly it can be configured relatively easily to archive with MHonArc right from within the sendmail.cfg.
I don't know if MHonArc is still being actively developed, but ListServ (my fav) has a decent web managment interface and MHonArc does a nice job of archiving posts in any number of methods. We implemented this in the day at Bell Labs for any number of internal mail lists (Bell Labs 'had' a lot of internal mail list activity).
http://www.mhonarc.org/
This also works really well for server processes that send automated email notifications with exit statuses, results, etc.
OGC is a bit more than Refractions. Paul was a relative late comer to the party. When OGC first started in '94 there were very few of us. Dave Schell, Fred Limp, John Davidson (I was @Genasys) and a few others.. I don't believe Refractions was even formed until '98 and Postgis, their first entry into the open geospatial world wasn't released until 2001. Today, OGC has about 490 members, most of them companies, though a few individuals.
Good to know, thanks.
After digging a bit deeper, now I see what you're saying, HOWEVER, this small scale development effort (1 developer, 12 followers) is apparently only available for SQL 2005 because only 2005 supports .NET CLR integration.
As someone that has been building spatial apps for 20 years, that means run away as fast as you can. Additionally, there is zero support for this implementation and OGC still doesn't recognize it. If I had a bunch of extra time and SQL Server '05 hanging around I might try it sometime, but in a production environment...? Why bother? Refractions offers great support and PostGIS is so widely used, there is a large user base to draw from.
I suspect your one of the developers for this project and commend you for the effort, but I have to ask "why" build an open source implementation on a closed platform?
According to OGC's list of compliant products, no Microsoft products comply with the Simple Features: Types and Functions v.1.1 specification... ...regardless what codeplex says. OGC has a fairly rigorous specifications test.
http://www.opengeospatial.org/resource/products/byspec
MS SQL does not adhere to the OGC's (Open Geospatial Consortium) Types & Features v. 1.1 specification. If you're serious about storing spatial data in an RDBMS it should adhere to that standard. Highly recommend staying away from SQL Server unless you're willing to invest in ESRI's SDE app server, and with PostgreSQL/PostGIS why even bother?
I've been doing geospatial development since 1992 when Genasys (defunct) released the worlds first web mapping server, Web Broker (ESRI's IMS wasn't released until 5 years later). At the time the only COTS option for managing spatial data within an RDBMS was Sybase's Spatial Query Server, which provided slightly more geometry options inherent within MySQL today. MySQL geometry features should be considered primitive at best, far from a full-featured implementation. On the other hand, PostGIS, is full featured and the only open source implementation I know of that adheres to the Open Geospatial Consortium's 'Simple Features: Types and Functions 1.1' specification. It is very robust, scales well (in contrast to MS SQL) and you can't beat the price or ease-of-mind that comes with being licensed under v.2 of the GPL. Additionally, on comparable hardware, in terms of reliability, performance, and cost effectiveness, there is no comparison, regardless whether your using Oracle w/Spatial or MS SQL and ESRI's SDE.
Your developers, as good of guys at heart as they may be, should stay away from the kool aid for awhile
What ever became of this tablet? It was so hyped this time last year and would still seem to be the most feature-rich of all the tablets with its transflective display, 185 degree swivel camera, full HDMI, etc.
Denver PD has been having their share of publicity problems lately but this is ridiculous. What's next, detonating the toy department at Walmart?
As is UMN's MapServer, with a fully open source (GPL-like) license. http://mapserver.org/
For a nice and robust GPL'd mapping client that can pull data from MapServer, as well as many other sources, see QGis. http://www.qgis.org/
For a full-featured GIS agent with GPL'd license that can also pull date from MapServer see GRASS. http://grass.osgeo.org/
Another cool open source geographical application is PostGIS, a spatial data server for PostgreSQL that interfaces with all of the above. http://postgis.refractions.net/
Assuming you're referring to ESRI, (Environment Systems Research Institute), labeling them the 'top GIS company' is highly subjective. There are IMO many better platforms out there, open source included (see GRASS and/or QGIS). They just were lucky enough to secure some significant clients early on (USGS, USFS, USFWS, USDoI, DoD, NGS, etc.), which it turn forced all their subcontractors to adopt the same platform. Their software is bloated, cumbersome, about a decade behind emerging technologies, i.e., like Google Earth, and has a very closed architecture when it comes to integration.
And yet China continues to be a preferred trade partner to the "free" world. What the hell does this even mean anymore? They poison our children with first lead, then cadmium laced jewellery, they hack our networks an infest them with malware/spyware, force labor upon their own children, yet they are our "friends" because we can buy their crap for cheap and sell it at Walmart.
Isn't it time to reevaluate our trade partner status with this country that is set on deceiving us with every opportunity they get?
It is far past time to stop free trade agreements with countries of repressive governments. They are destroying the economies of the rest of the world.
One of the most spiritually uplifting documentaries I have ever seen, The Wild Parrots of Telegraph Hill, by Judy Irving, shows in great hilarity one of the films stars, Connor, a Red Crown Conure, dancing to the music of Mark Bitner, the main character and un-official steward of Telegraph Hill's wild parrot population. An absolute must see film, at least if you like movies that leave you feeling good.
http://www.youtube.com/watch?v=ZBDqwkgjW6g
http://www.wildparrotsfilm.com/
LL is selling a 'gaming experience', not photos and particularly not of photos of TM products. 2nd, I would think some element of 'fair use' would come into play here. At what point will park bench designers, fashion designers, civil engineers, etc., not want a piece of LL's profits? I see a USSC ruling all over this one. Perhaps even a constitutional amendment addressing virtual worlds.
Since many folks use their usb devices as backup media, it should be noted since fat32 has a file size limitation of about 4gb, fat32 is not an option if you wish to use MS Backup utility to create backup images larger than that.
"Google's GeoEye-1" is misleading. I thought GeoEye was a division of Orbital Sciences, not Google.
Dear Mike,
Good luck with your new job search.
Dreben
The problem with this is the "so many standards to chose from" scenario. There are numerous applications available, many of them open source, (OpeNDAP, GDAL, PostGIS, DODS, etc.), that can read from and write to the plethora of geospatial data interfaces available. GE appears to be written to do just that from some limited finite number of these data interfaces, albeit, if one of the above posts is correct, using Frank Warmerdam's Geographic Data Abstraction Layer (GDAL) library. Gaia was obviously written specifically to query and retrieve data just from GE. Not much point in writing an API that does exactly what GDAL does.
I've worked for both imaging vendors identified in this thread, specifically on the technical aspects of their imaging servers, and I understand their need to protect their investment(s). As a consumer of, and general hobbyist in the use of geospatial information, I'm also appreciative of Google for having done the incredible job they have with Google Earth, which is what prompted me to post the story originally. However, denying a third party API access to the same information that the Google API provides seems to border on what is fair use and what isn't. Either the data is available for free to the world via TCP or it isn't. Google, and the data vendors had a choice to NOT make the data available to the world for free. They chose to make it free. The fact that Google entered into an agreement to lease data from the vendors so they could push it to the world without charge doesn't change the fact that they did. If in fact the restrictions for reusing the imagery is written into the Google API, than they same caveat needs to be included in the GPL's API.
As far as I understand the GPL, it only protects the source code of the application, not the data it uses. Just because GIMP can manipulate proprietary imagery, doesn't put GIMP at risk of violating some proprietary license agreement. That accountability comes at the risk of the user of the software, not the GIMP developers. The same premise should hold true here.
Watermarking is a process that happens when imagery is pulled from the image server, likely JPEG 2000, and occurs regardless whether the imagery was requested with the Google Earth application, the Google Earth API, or any other API that knows how to request imagery from the image server. The imaging server application is likely either written using ER Mapper's ECW JPEG 2000 SDK (a GPL-like open source license for images under 500mb - i.e., Google Earth images) or LizardTech's MrSID proprietary server. I'm guessing unless Google wrote their own imaging server, they chose ER Mapper's (I would), it's more flexible and written to JPEG 2000 standards.
RIAA and MPAA don't have proprietary API offerings to access their (owned, leased or otherwise) data. Google does. An oss API is competing for users of the proprietary Google API.
On the other hand, not having seen the Google API EULA, I'm guessing it explicitly defines what is fair re-use of the 3rd party vendor's data. Couldn't an oss API have the same type of vernacular in its EULA? I suppose this might be contstrued as extending the GPL (or whatever license Gaia was using), but this component/extension would be explicitly limited to the reuse of the data (not the API), indemnifying Gaia from improper use of 3rd party data from anyone that were to use the Gaia API. I'm fairly confident this is similar to what Google says in their EULA.
It would be interesting to read the Google Earth API EULA.
How does/will this affect closed/proprietary applications written in Java? Must they now also be distributed under the rules of GPL?