Why are all the pushpins in the SDK demos misplaced?

Why are all the pushpins in the SDK demos misplaced?

• Andris Bartha

  Ah my fault, I didn't realize you weren't really curious as to why the pins were displaced...but rather just making a point about the current SDK documentation. I agree that at zoom level 2 where the pushpin is the size of Kansas itself, then yes the tip of the default tack is not geographically over the lat/long the pusphin object is purporting to represent. The SDK owners should acknowledge this in the documentation as the default pin does indicate that the center of the bottom edge of the icon is the represented geocoded area. Perhaps even the VE team themselves would consider a top/center/bottom/left/right anchoring property for a given pin so that icons, default or otherwise, will be properly displayed at all zoom levels and we as developers would be responsible for correctly orienting the location indicators, and have more flexibility when designing our own pins.

  That said, I do not think it reflects "very badly" on the SDK; I do think it reflects on a poor choice for the default pin indicator. All the mapping API's display this behavior to varying degrees when, relative to the current zoom level, a "pin" icon is several hundred square miles in area. Google's green arrow indicator is much more accurate in this respect, but still shows movement within a few hundred yards as zooming occurs. Yahoo's red star is slightly better, but more ambiguous because of the limited selection of zooming levels AND the fact that it is not a pointer or flag standard.

  
  

• Dentreader

  No, I am really curious why the pins are displaced. Not technically what is making them displaced, but why in a demo of how to use an SDK, it is not implemented correctly.
  
  The placement of the pushpin is fundamental functionality for any application that chooses to display them. Unless your pushpin just happens to have its "pointer" right in the center of the image, you must do something to make it correct. Particularly if you choose to use the default pushpin that the SDK is showing. It is wrong as implemented, plain and simple. Why bother documenting that it is wrong when you can just fix it and make it right Isn't the point of the sample code to show how it should be done "Keeping it simple" makes no sense if it's wrong.
  
  The pointer of the pushpin should be pointing to the same location regardless of the zoom level. It doesn't matter if the pushpin is the size of Kansas. It should still be correct. And no, Google maps does not have this same problem. Go to maps.google.com and check for yourself. They just happen to have an example search of Kansas City on the left. Click on it and zoom out as far as you want. You can zoom out until the pushpin is nearly the size of North America, and the pushpin is still pointing to Kansas City. This is correct behavior. Any movement you may see more than one pixel is not due to this type of issue, but is a problem with lining up the graphical map with the geocoded points, and making it consistent at all zoom levels. That is a completely different issue, and from what I have seen, Virtual Earth is just as good if not better than Google, assuming you don't do it like the SDK shows you how to do it.
  
  The choice of the default pin indicator is not a bad choice (although I don't like the looks of it). It is actually a good choice, because it doesn't have its pointer in the center, and it is a good opportunity to show developers how to properly position a pushpin when they use their own custom pushpin that also does not have its pointer in the center. The Virtual Earth developers either:
  

  1. intended the pushpin to be properly positioned with CSS, or
  2. it was a gross oversight on their part to leave it out of the SDK because a pushpin that points to the wrong location is completely useless, and even the default doesn't work!
     

  I don't know which it is, but I am assuming (1), which is why I was wondering why it wasn't in the demo. You are assuming (2), but even if it were true, it is not necessary to be in the SDK because it can be handled with CSS. An anchoring property is not necessary. Someone put the CSS class name for the pushpin in the constructor for a reason.
  
  This is not advanced functionality, or fancy CSS. It is basic functionality necessary for a correct implementation. All that has to be done is to add the following lines to the example:
  Put this above the first <script> element:
  
  <style type="text/css">
.defaultPin { position:relative; top:-15px; }
</style>
  
  And supply the missing argument ('defaultPin' in this case to match the CSS class above) to the VEPushpin constructor like this:
  
  var pin = new VEPushpin(
pinID,
map.GetCenter(),
null,
'My pushpin',
'This is pushpin number '+pinID,
'defaultPin'
);
  
  With this simple addition, the demo works great and the pushpin points to the correct location at all zoom levels, but a very different location than before.
  
  The bottom line is that any application that was implemented as shown in the SDK sample code would be grossly incorrect, and that would reflect very badly on Virtual Earth.
  
  

• Dipesh A.

  I'm not sure what your on about - currently you set an icon and an iconstyle, in the css you provide the offset that tells VE the exact "anchoring" point for the icon. What could be simplier then css Isn't that abstracting the positioning
  The issues of this thread was the iconstyle was not included in the SDK demos.
  Under any circumstance if the icon changes your probably going to have to modify its css, buts whats new Graphic design changes and css go hand in hand, lets not put design into javascript.
  John.
  
  
  

• Bulldog.NET

  So what happens when a Virtual Earth UI specialist decides they are going to change the dimensions and/or core image of the default pin You all want to babysit the CSS files and figure out your custom x/y offsets -- after complaints come filing in from customers -- go right ahead. Personally, I'd prefer an anchoring property that would abstract the positioning so I wouldn't have to worry about it everytime a customer wanted an icon changed. That said, Chris, I totally agree with you both on principle, AND implementation, about the current V3 API build, and the current interactive SDK as documenting how to accurately position the default pins. It should be fixed, or otherwise annotated as to the displacement.

  
  

• kiril.stanoev

  Hello there,

  Is it possible to apply this css "fix" when adding pushpins using a VELayerSpecification and GeoRSS xml file

  It says in the SDK you can specify a URL of an icon to use, but no mention of using CSS with it

  Cheers
  Mike

  
  

• Lucky_Adam

  Yep, pushpin displacement to center the icon image and or the pin's "point" directly on a specific lat/lon will be a function of both icon size and zoom level.  For individual pins, a generic javascript math function will get it done, and for collections you could look at multiple style definitions that would be set individually based on the map zoom level value.
  

• GroZZleR

  I fully understand why the thumbtack appears to be moving. My point is, why would the SDK demonstrate this wrong behavior Isn't the point of the SDK to demonstrate how you would implement the code in your own application I would guess that most people using a mapping application would assume that a thumbtack is pointing to the point at the tip of the thumbtack, not in the center of the image. It is clearly wrong in the SDK because the thumbtack is pointing to the wrong location. Anybody implementing it this way would be showing the wrong locations to their clients. I think this reflects very badly on the SDK because it makes it look like the developers of the application can't even get it to work correctly. If showing things "as they are" is wrong, then maybe it makes more sense to show things "as they should be".
  
  

• gokce

  If you are using the identical image for the GeoRSS pins, then one possible solution would be to apply and XSLT transform to the source file and simply offset the lat and lon of each coordinate to compensate for the default pin positioning behavior of the API. The transform would allow you to abstract that step apart from the realtiy of the coordinates in your source file.
  

• Vyatsek

  Good suggestion (in blue). I'll pass it on to the team.

  And thanks also for the concise summary of the problem. I agree (but I am a bit biased) that this isn't so much a problem with the SDK as with the default pushpin behavior and/or the APIs.

  The general philosophy with SDKs is that they exist to document the APIs as they are. I've created a bit of a new world for SDKs with the interactive SDK in that it not only documents the API, but demos it at the same time. So that leaves us in a new space: do we continue to just show how the API works, or do we show how to "tweak" it to do everything you could want

  In this case, I had to make the conscious decision not to go too far down the second path. Why

  1. At what level do we draw the line Do we teach basic HTML stuff Show fancy CSS tricks Javascript tricks ASP.NET integration AJAX
  2. There are plenty of sites on the Web that show #1 in general, and there are lots of clever people lurking on the forums and posting amazing mashups that show #1 specifically with regard to VE. I hope that the gallery and this forum will continue to grow and provide this level of education for those who want it.
  3. It is more than enough work to document the API, keep up with the frequent updates, and maintain the site without trying to teach all of the other cool stuff that goes in to building a mashup.

  That being said, and to address the initial concerns in this post: What do you think of an "advanced mashup" type of page Or a Frequent Requested Hacks page What would it look like I'm seeing something totally community-run, where you (for example) would put something like: "I hate how the default pushpin is centered on the center of the icon, rather than the pin itself! So here's how you can easily fix it in CSS: ".

  Ideas Thoughts Comments As always, I love to hear them (even the "bad" ones )!

  Cheers,

  Caleb

  
  

• voevoda

  Sorry to have to bump this thread, but this is important to my project.

  I can fix individual puspins with the css fix, but I am adding a number of pushpins from a GroRSS file and they are all misplaced.

  How can I fix this

  
  

• Prasanna_Iyer_d76ea7

  I agree, for people who simple cut and paste the examples and then add their own data it is going to be wrong. For the sake of 3 lines of code and an extra parameter you get it working perfectly. I would add this to all basic examples that use the "default" pin.
  An advanced SDK would be great, maybe we can help you Caleb Examples would require to be complete with a single html document, reference the SDK etc . The best example I can think of would be the nice draw a circle code submitted. How easy would that be to add Maybe you can devise a format for submission and we can help build things for you. Maybe even some of "features" of WLL could make it into the advanced page ;)
  John.
  
  
  

• Devan47

  I've had no problems getting the icons image or the pin's "point" directly on a lat/lon for all zoom levels using a css style as in my blog. What issues have you faced Jared that required a js function

  John.

  
  
  

• mfradkov

  This is the nature of how the VE product defines the "center" of the pushpin icon. The pin doesn't actually change position; it just appears to: if the pushpin icon were something less like a thumbtack, it wouldn't be a problem. It just appears to move because you are looking at the very end of the pin, which is not pointing to the location specified. I agree it is a bit ugly and confusing...but it makes sense that the center of the pushpin points to the specified location. Otherwise, a custom pushpin will look off-kilter.

  And, yes, as you point out, I could override the CSS to "fix it", but the point of the SDK is to show things "as they are".

  
  

• GRiNSER

  and for all those that want to know how to do it:

  http://www.soulsolutions.com.au/Blog/tabid/73/EntryID/31/Default.aspx

  John.

  
  
  
• Why are all the pushpins in the SDK demos misplaced?