I have previously used Mapquest Open Arial tiles without any trouble. However, after the last server change I get tiles with weird colors. Their example tile still looks fine:
http://otile1.mqcdn.com/tiles/1.0.0/sat/15/5240/12661.jpg
But, the ones I'm trying to download look like this:
http://otile1.mqcdn.com/tiles/1.0.0/sat/13/1927/3385.jpg
The most striking problem is that the vegetation is red.
Does anyone know what's causing this or perhaps how I can correct the colors (I have tried playing around with them a bit in gimp but I couldn't find a solution)?
Disclaimer: I work at MapQuest. Unfortunately there was bad data in the last round of open aerial imagery updates that caused some areas (we've noticed Texas) to be seeded with discoloration from zoom level 12 and up. We've got this on our backlog, but I don't have an estimate as to when this issue will be resolved. Thanks for your interest in our Open Tiles!
Related
I think I have found an error in GE V7.0.1.8244. I create a KML route file and display it with setAltitudeMode set to ALTITUDE_CLAMP_TO_GROUND. In GE V6.2.2.6613 it displays correctly but in V7.0.1.8244 (currently beta) it does not. Same program source, same data. See attached image here:
.
Any ideas anybody other than installing an other version of GE?
This is clearly a bug in GE 7.0. A few of the elements in the KML test file are out of order but nothing to cause this problem. Even if you drop the altitude values and change altitudeMode to relativeToGround it gets worse not better. Neither DirectX or OpenGL mode makes a difference.
You can report the issue here to get any updates on the problem:
http://code.google.com/p/earth-issues/issues/list
Might be an error in elevation data. You can also see this error in the sample line example if you zoom close to the path.
Only short-term fix is reverting back to GE 6.2.2 if want to view this KML correctly, otherwise, wait for a fix.
UPDATE: Issue in Google Earth issue tracker can be found here.
It does look like a bug, rather than down grading though you could look to use one of the Google Earth extensions - specifically the gx:altitudeOffset element. From the docs...
A KML extension, in the Google extension namespace, that modifies how
the altitude values are rendered. This offset allows you to move an
entire LinearRing up or down as a unit without modifying all the
individual coordinate values that make up the LinearRing. (Although
the LinearRing is displayed using the altitude offset value, the
original altitude values are preserved in the KML file.) Units are in
meters.
This should allow you to raise the path by a meter so that the clipping doesn't occur.
It is also worth noting that...
In Google Earth, a Polygon with an of clampToGround
follows lines of constant bearing; however, a LinearRing (by itself)
with an of clampToGround follows great circle lines.
So perhaps you need to adjust your path to account for this discrepancy?
This is my second question, and I’m hoping to resolve an issue that I haven’t found addressed, though I did search for an answer.
Links and screenshots to problem are below. Using Fireworks CS5, I have created an animated gif consisting of 3 states that loops 3 times. It is built on layers, with the 3 states sharing only a background border. They do not share the background (the background is grouped layer consisting of a red box with a clipping path of white, which seems to work in the first two states, but fails in the third state) itself, or any other element.
It is a tile ad for an html e-newsletter, and it works on some clients (gmail, for instance), but the final state does not render properly in other clients (mac mail, for instance). To add to the issue, the same file was rendering correctly in Mac Mail earlier. The gif works if I open it in a browser (usually), as well.
I thought that animated gifs were very stable across platforms except for problems with looping in Outlook 2007 and I've never had this issue before (granted my experience is limited). Has anyone else had this experience? Does anyone have advice on this issue?
Many thanks,
Andrew.
Link to the good. This is the animated gif file. It may not work in all browsers (I did test the file thoroughly, but the weird issue just seems completely sporadic), but renders correctly in latest Firefox for Mac OS 10.7x.
Link to the bad. The third state is see-through, the background layer is not rendering.
Turn Off the Alpha Transparency in the optimization panel. After carefully examining each state, I realized that I had Alpha Transparency turned ON in the export. Even though each state had a solid red back ground, and even though the other states correctly rendered the solid red background, the Alpha Transparency was messing up the last state of the animation. To correct it, I simply turned OFF the Alpha Transparency. I don't know why I didn't think about that as the solution before. I hope this answer helps someone!
Has anybody ever had any issues with transitioning the opacity of an SVG text element? I'm using both the fill-opacity style and the stroke-opacity style to fade the text elements into and out of existence. It works fine on most browsers, but doesn't transition at all in Chrome on Mac -- the text just pops in and out all at once.
I tried setting the "opacity" attribute in addition to fill-opacity and stroke-opacity and that does seem to make it work, although now I see a weird flicker effect just before and after the transition runs. It's like it's setting it to opacity=1 for a split second before it sets it to 0 and then transitions to 1.
Another interesting thing is that other shapes (circle, rect) fade in and out just fine with nearly identical code to what I'm using with text.
This does seem to be weirdness with a specific browser, but I'm wondering about other people's experiences with opacity on text elements. Are there tricks to get it to behave consistently?
What version of Chrome are you using? I noticed a bug in Chrome dev some time ago when working on the word cloud but it appears to have been fixed as of 19.0.1077.3 dev. Perhaps the fix hasn't made it into your particular version yet?
In my case, using opacity fixed the problem temporarily. The flicker effect could be due to exponent notation not being parsed for very small numbers; you can try using 1e-6 instead of 0 to get around this.
For an animation I made some months ago I toggled the style and used webkit-transition, in combination with visibility: hidden. This seems to work well. If that doesn't work, you could try transitioning to an opacity near zero.
I've placed an image on top of a div. I'm trying to blend the image into the div (The div is a solid color). In Google Chrome, it looks great! The colors blend perfectly. In IE 7, however, the colors show a hard line even though they should be the same color! After some examination (a print screen put into paint.net to check the actual RGB values), IE 7 is actually lightning up my image.
The blend has to look seamless. Google Chrome was fine with this thus far. Any ideas why IE 7 wont display the color right?
The two browsers are using different rendering engines. There are minor differences between them in how they render graphics, particularly jpegs.
The differences are minor but unavoidable.
Most of the time it goes unnoticed; it only makes an appearance in cases like yours when you try to position it against an element with a solid background colour that is supposed to be the same.
You may be able to resolve the issue by using a different image format. Try saving the image as a PNG. PNGs tend to be rendered more accurately between the browsers than jpegs, so that might be enough to solve your problem.
If that doesn't solve your problem, you could try using PNGs alpha transparency feature to produce an image with a fade to transparent at the edge, and then overlap the background colour behind it. This will definitely give you a smooth transition, but is a bit more technical, so harder to achieve. It will also give you problems with older versions of IE (IE6 for sure, I think you'll be okay with IE7), as they had some major bugs with PNG transparency. (If this is an issue for you, there are work-arounds for this; google IEPNGFix for more)
There are small lines appearing sometimes in front of words. In the pictures they are to the right of +syntax/ and swo and delmenu.vim.
Is this a bug or those lines mean something?
Do this happened to you before?
Would they get worse in the future?
PS: I'm using Microsoft Windows XP SP2 AMD
alt text http://img97.imageshack.us/img97/7673/picpd.jpg
EDIT: I change the font to Consolas and they disappeared. Is there a way to solve the problem while still using my favorite font, Monaco (and not turning off Cleartype)?
This is caused by cleartype font smoothing.
If you use a fixed font for gvim the problem goes away (.fon files). ttf files contain font smoothing information which gets messed up in gvim.
fixedsys renders well. There are a bunch of other ones that also work well.
An alternative is to turn off font smoothing altogher using the display properties, but that will have undesirable effects on all other applications.
This does indeed look like a rendering bug. You should report it to the gvim team. But you should also never use jpegs for screen shots - the compression doesn't work nearly as well as pngs, and could potentially introduce distortion in shots exactly like this one.
Just a guess, but it may be related to the font you are using. Maybe you could try to change it to see if these lines still appear, or disappear, or move to other lines ...