The units change when buffering is done. There's only 1 supported, px. If not set to px the units are assumed to be the same as the layers projection. In that case the feature is buffered and then converted to image coords. If the units are px then the buffering happens after conversion to image coordinates. I suspect that's why you see the more complex output. The map to image conversion removes loads of unnecessary coords that are re-introduced when buffering. I suspect there may be a way to always buffer beforehand but I've not looked into that.<br>
<br>Steve<br><br>On Wednesday, September 21, 2011, Bob Basques <<a href="mailto:Bob.Basques@ci.stpaul.mn.us">Bob.Basques@ci.stpaul.mn.us</a>> wrote:<br>> All,<br>><br>> Some more info on the topic, I see now that my first question was phrased wrongly, I actaully need more information about how SHPXY works against (POLY)LINE features (vs POLYGONS):<br>
><br>> Using this slightly modified version of the SHPXY call (removed the "px" from the end of the buffer<br>><br>> coords="[shpxy cs=" " xf="," proj="image" buffer=20]"<br>
><br>> The output looks like:<br>><br>> coords="0,950 0,0 879,0 879,950" (coincidentally mapsize=880 952 for the call)<br>><br>> Much smaller list than below (but it now includes almost the complete image). I also think that an imagemaop needs to have the first and last coordinate pairs be the same in order to close the same (which is correct below)<br>
><br>> coords="[shpxy cs=" " xf="," proj="image" buffer=20px]"<br>><br>> coords="442,455 441,455 440,455 439,455 438,455 437,456 436,456 435,456 434,457 433,457 432,458 431,458 430,459 429,460 428,460 428,461 427,462 426,463 426,463 425,464 425,465 424,466 424,467 423,468 423,469 423,470 422,471 422,472 422,473 422,474 422,475 422,476 422,477 422,478 422,479 423,480 423,481 423,482 424,483 424,484 425,485 425,486 426,487 427,488 427,489 428,489 429,490 430,491 430,491 431,492 432,492 433,493 434,493 435,494 436,494 437,494 438,495 439,495 440,495 441,495 442,495 879,490 880,490 881,490 882,490 883,490 884,489 885,489 886,489 887,488 888,488 889,487 890,487 891,486 892,485 893,485 893,484 894,483 895,482 895,482 896,481 896,480 897,479 897,478 898,477 898,476 898,475 899,474 899,473 899,472 899,471 899,470 899,469 899,468 899,467 899,466 898,465 898,464 898,463 897,462 897,461 896,460 896,459 895,458 894,457 894,456 893,456 892,455 891,454 891,454 890,453 889,453 888,452 887,452 886,451 885,451 884,451 883,450 882,450 881,450 880,450 879,450 442,455"<br>
><br>> See attached for image from above examples.<br>><br>> I couldn't find any documentation anywhere about these unit options like "px". So what's the deal with this unit inclusion changing the output, and why are so many numbers required to imagemap a straight line? Is this related to incrementally going around a corner or curved object or ???<br>
><br>> Still working it . . .<br>><br>> bobb<br>><br>><br>><br>>>>> "Bob Basques" <<a href="mailto:Bob.Basques@ci.stpaul.mn.us">Bob.Basques@ci.stpaul.mn.us</a>> wrote:<br>><br>
> All,<br>><br>> Should I be using "POLY" as the type for LINE imagemaps?<br>><br>> This works most of the time:<br>><br>> class="Sewers" shape="poly" coords="[shpxy cs=" " xf="," proj="image" buffer=20px]<br>
><br>> Also, related to precision, is there a weeding option of some sort? A typical output from above looks like (really a LINE feature), notice the same points being written out:<br>><br>> class="Sewers" shape="poly" coords="816,525 816,514 815,504 814,494 812,483 810,473 807,463 803,453 799,443 795,434 790,425 785,416 779,407 773,399 766,391 759,383 751,376 743,369 735,362 727,356 718,351 708,346 699,341 689,337 680,333 670,330 659,328 649,326 639,324 628,323 618,323 607,323 597,324 587,325 576,327 566,329 556,332 546,336 536,340 527,344 518,349 509,354 500,360 492,366 484,373 476,380 469,388 462,396 455,404 449,412 444,421 439,431 434,440 430,450 426,459 423,469 421,480 419,490 417,500 416,511 416,521 415,627 415,638 416,648 417,658 419,669 421,679 424,689 428,699 432,709 436,718 441,727 446,736 452,745 458,753 465,761 472,769 480,776 488,783 496,790 504,796 513,801 523,806 532,811 542,815 551,819 561,822 572,824 582,826 592,828 603,829 613,829 624,829 634,828 644,827 655,825 665,823 675,820 685,816 695,812 704,808 713,803 722,798 731,792 739,786 747,779 755,772 762,764 769,756 776,748 782,740 787,731 792,721 797,712 801,702 805,693 808,683 810,672 812,662 814,652 815,641 815,631 816,525"<br>
><br>> . . . but not all of the time, seems to get confused from time to time in how the imagemap is drawn. The above imagemap is for a two point line feature for example.<br>><br>> bobb<br>>