RE: [OSGeo-Discuss] Re: Comparison between MapServer/OpenLayers and ESRI ArcIMS
However, they (the US govt.) don’t even need a specific legal provision to spy on data that is hosted outside the US, and they’ve been doing that since forever… ;-) From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Richard Desrochers Sent: Sunday, May 31, 2009 8:34 PM To: rkgeo...@cadmaps.com; OSGeo Discussions Subject: Re: [OSGeo-Discuss] Re: Comparison between MapServer/OpenLayers and ESRI ArcIMS One thing to consider using a cloud approach with Amazon is the license agreement concerning your data. Under the Patriot Act in the US all data hosted in the US could be made available to the US government. Not all corporations are ready to live with that. Richard 2009/5/30 Randy George rkgeo...@cadmaps.commailto:rkgeo...@cadmaps.com Cloud options are looking interesting. http://aws.amazon.com/ec2/ Windows, Linux, Solaris options I imagine ESRI license entanglement with virtual servers could be a problem. But no problem at all with Open Source GIS stacks. No license to get tangled with load balancing and auto scaling where servers come and go as needed. Mostly I've seen small business interest since they tend to take overhead costs more seriously. It might be useful to include a Cloud based server solution addendum, because that would be less optimal for an ESRI vendor and could look good compared to in-house hardware. Unfortunately, medium and large organizations seem to have budget allocations already in place for the big ticket approach. But then in this economy even that could be changing. AWS now includes Load Balancing and Auto Scaling options as well as S3 Backup, multiple offsite elastic block store duplication, edge cache, and elastic IP. http://aws.amazon.com/about-aws/whats-new/2009/05/17/monitoring-auto-scaling-elastic-load-balancing/ And for the real bleeding edge http://aws.amazon.com/elasticmapreduce/ (Not a selling point to small, medium, or large organizations, unless academically oriented :-) rkgeorge -Original Message- From: discuss-boun...@lists.osgeo.orgmailto:discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.orgmailto:discuss-boun...@lists.osgeo.org] On Behalf Of Jason Birch Sent: Friday, May 29, 2009 5:49 PM To: OSGeo Discussions Subject: RE: [OSGeo-Discuss] Re: Comparision between MapServer/OpenLayers and ESRI ArcIMS I think that it's generally less fear of the unknown or job security than it is the cost of adding complexity to what is often an already over-extended support load. In many cases it just makes sense to spend $1000 for a server OS that doesn't require additional training, is easy to get qualified techs for, and just works with the existing systems. It doesn't matter how easy Linux is; it's one more thing to keep track of and one more thing to go wrong. If you want to win the open source battle at small organisations that don't already have OS operating system tendencies, focus on the application level where you can make a strong business case on a feature-by-feature level, and with additional arguments about truly open data being more sustainable and less risky. Personally I think that an open source or bust attitude is not very pragmatic. Sell open source software where it is the best tool for the job, but pick your battles. Jason -Original Message- From: Alex Mandel Sent: Friday, May 29, 2009 4:25 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] Re: Comparision between MapServer/OpenLayers and ESRI ArcIMS That would be fear of the unknown(non gui) and job security at work. Wouldn't want someone else in the org who knows more about running servers. Maybe you can get them to throw a bone to demo something on a virtual machine hosted elsewhere(Amazon) just to show how easy it is. Welcome to the land of small to medium government agencies, etc. The best thing here is showing examples from equivalent groups, of which there are plenty online now. ___ Discuss mailing list Discuss@lists.osgeo.orgmailto:Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Richard Desrochers ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] 'lossless' JPEG2000
It is not possible to *prove* a mathematical relationship by example. One would have to study the set of all possible images in the world and make sure they have no loss in order to effectively prove the claim. On the other hand you can *disprove* it by providing a single counterexample. That is why I pointed to the math of the transform, which one has hope of showing is invertible for all cases. Anyway, I'm not that much of an expert on wavelet compression so I can't do much more than point to other people's documentation. Traian From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Saturday, February 23, 2008 3:57 AM To: OSGeo Discussions Subject: RE: [OSGeo-Discuss] 'lossless' JPEG2000 IMO: Thanks for the reply Traian, I don't mean to be dismissive of this report, but I was hoping for something more definitive to prove that 'lossless' JPEG compressions did indeed protect the integrity of the data.. Perhaps its just my ignorance, but I was hoping for something along the lines of: - a study of a range of typical spatial 'imagery'. - evaluation of all spectral values for each pixel in each image before compression. - 'lossless' compression of the images - restoration of the compressed images - comparison of all spectral values for each pixel in each restored image against the original pre-compressed values. - definitive statement with reference to the study results. Bruce JPEG2K supports lossless via a reversible wavelet transform with integral coefficients (which make it reversible, and so lossless). Here is a reference: http://www.ece.uvic.ca/~mdadams/publications/pacrim2001.pdf Traian Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Re: idea for an OSGeo project -- a new, open data format
How about an OGR driver for SDF? No need to invent a new API when one already exists. Traian From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mateusz Loskot [EMAIL PROTECTED] Sent: Thursday, November 22, 2007 2:36 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] Re: idea for an OSGeo project -- a new,open data format Robert Bray wrote: Chris, I agree and will see what I can do to make it happen. If we want wider adoption it may also be beneficial to see some kind of C/C++ access library created for the format. In the past I always felt the FDO Provider was that library, but the masses seem to be telling me I am wrong about that :) Bob, Sounds like a very good idea to setup a libsdf project. This way, it could be used by FDO, OGR and others. Cheers -- Mateusz Loskot http://mateusz.loskot.net ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Re: idea for an OSGeo project -- a new, open data format
I think many people have it backwards. SDF is basically a reference implementation of the FDO API (or a significant subset thereof). It's not an independent file format that happens to have an FDO driver. Any C++ API for SDF would likely have to use FDO data structures and types underneath to get SDF data out of the file. This is because FDO data structures are directly serialized into SDF binary tables. Traian From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Christopher Schmidt [EMAIL PROTECTED] Sent: Thursday, November 22, 2007 9:23 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] Re: idea for an OSGeo project -- a new,open data format On Thu, Nov 22, 2007 at 05:17:46PM -0800, Traian Stanev wrote: How about an OGR driver for SDF? No need to invent a new API when one already exists. I think that was exactly Bob's point: There is already an FDO driver for SDF. If OGR is sufficient, I'm not entirely sure why FDO wouldn't be by the same argument. I'm with Mat, in feeling that it's not the path to the widest usage in only FDO *or* OGR, and that a reference implementation outside of either of those would result in possibly higher OEM-style integration into non OGR/FDO products, and that a single shared implementation is the best way for all developers to share a single effort when moving forward. Regards, -- Christopher Schmidt Web Developer ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] How to assess rendering quality?
Antialiasing, when done wrong is just making the edges intermediate colors. When done right it also involves subpixel positioning which improves not only the visual appearance but also the relative accuracy of lines -- i.e. visual weight is most correctly distributed over exact position of the line given the discrete sampling frequency (pixels). There is actually solid scientific basis in that (Niquist-Shannon theorem). Sharpness of detail in non-AA lines is fake accuracy. Unfortunately antialiasing is also hard to get right, because it depends on gamma correction. For example compare the antialiased output here (http://www.realtimerendering.com/gamma10.png with gamma = 1.0) and here with gamma 2.2 (http://www.realtimerendering.com/gamma22.png). They are both antialiased using the same algorithm, yet one looks better than the other. Asking people to compare smooth versus sharp will be sensitive not only to the subjective appeal of the picture, but also by the ambient lighting conditions, the gamma used by the AA algorithm versus the gamma of the monitor used for the test, and by whether or not the AA algorithm used subpixel positioning. Also, it depends on whether the image reading application honors the gamma value stored in the image. In addition, you will get fanboy bias where people will prefer the output they have seen before. This comes up with things like font glyph rasterization surveys, where people who are more familiar with Macs prefer blurry but correct glyphs while people who use predominantly Windows prefer sharp but deformed glyphs, only because that's what they are used to seeing. So you will need to have lots of questions that ask for the same thing using screenshots that do not say which product they are from. You should also include output from a third party app like Adobe Acrobat. I would also include test questions where the two images being compared are identical. Traian -Original Message- From: [EMAIL PROTECTED] [mailto:discuss- [EMAIL PROTECTED] On Behalf Of Ed McNierney Sent: Wednesday, October 10, 2007 9:02 AM To: OSGeo Discussions Subject: RE: [OSGeo-Discuss] How to assess rendering quality? Gilles - Just keep in mind that subjective metrics are, after all, subjective, and some of your metrics are mutually exclusive. Smoothness of lines is normally accomplished by antialiasing those lines, making the edges intermediate colors and a little soft. This is a good thing, but is incompatible with sharpness of details, which is best accomplished without antialiasing but with more jagged artifacts on curves and diagonal lines. - Ed Ed McNierney Chief Mapmaker Demand Media / TopoZone.com 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 Phone: 978-251-4242, Fax: 978-251-1396 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:discuss- [EMAIL PROTECTED] On Behalf Of Gilles Bassière Sent: Wednesday, October 10, 2007 8:38 AM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] How to assess rendering quality? Hi Michael, I'm more concerned with subjective metrics, I actually plan to survey some users. The questionnaire will include some map samples and gather user preference for each criteria. My problem is to identify what questions/criteria should I ask to a user. Gilles Michael P. Gerlek wrote: Gilles- Is your idea to measure the quality by having a human look at outputs (subjective metrics) or automatically via some analysis routine (objective metrics)? -mpg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gilles Bassière Sent: Wednesday, October 10, 2007 3:01 AM To: discuss@lists.osgeo.org Subject: [OSGeo-Discuss] How to assess rendering quality? Hi list, I'm doing a comparative study of OpenSource cartographic servers (Mapserver, Geoserver and Mapnik). Beside raw performance and features, I'd like to assess the rendering quality, say how pretty produced maps are. Precisely, I'm interested in the quality of the drawing work, my point is not about symbology, nor styling of maps. I have some problems to find a set of objective criteria I could benchmark my servers against. So far, I have already identified the following: - sharpness of details - smoothness of lines - uniformity of colors I'm open to any comments. Do you think these criteria are consistent regarding the purpose of my study? Does anyone have other criteria to suggest? Regards -- Gilles Bassiere MAKINA CORPUS 30 rue des Jeuneurs FR-75011 PARIS http://www.makina-corpus.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org
