Zoom box and circle allignment

[Monefield]

Using your Italy example files I have no problem using the zoom option:

No box/circle = no problem: geoplot (area regions, discrete) /// 1 (area regions, fc(Red*.5) select(inlist(id,5)) discrete) /// 2 (area regions, fc(Red) select(inlist(id,5)) discrete), /// 3 zoom(3: 4 250 -20)

Using the box option = no problem: geoplot (area regions, discrete) /// 1 (area regions, fc(Red*.5) select(inlist(id,5)) discrete) /// 2 (area regions, fc(Red) select(inlist(id,5)) discrete), /// 3 zoom(3: 4 250 -20, box)

Using the circle option = no problem geoplot (area regions, discrete) /// 1 (area regions, fc(Red*.5) select(inlist(id,5)) discrete) /// 2 (area regions, fc(Red) select(inlist(id,5)) discrete), /// 3 zoom(3: 4 250 -20, circle)

The positioning of the zoomed in area moves around a bit when changing from box to circle but that is described in the help file, so no problem there. However when I use the Denmark shapefile I have downloaded here and I apply the same code I get something different:

No box/circle = no problem: geoplot (area komtest, discrete) /// 1 (area komtest, fc(Red*.5) select(inlist(kom,851)) discrete) /// 2 (area komtest, fc(Red) select(inlist(kom,851)) discrete), /// 3 zoom(3: 3 200 0)

Using the box option the boxes are fine, but the connecting lines don't line up with the boxes: geoplot (area komtest, discrete) /// 1 (area komtest, fc(Red*.5) select(inlist(kom,851)) discrete) /// 2 (area komtest, fc(Red) select(inlist(kom,851)) discrete), /// 3 zoom(3: 3 200 0, box)

Using the circle option is really strange: geoplot (area komtest, discrete) /// 1 (area komtest, fc(Red*.5) select(inlist(kom,851)) discrete) /// 2 (area komtest, fc(Red) select(inlist(kom,851)) discrete), /// 3 zoom(3: 3 200 0, circle)

Do you have any idea what's going on and how to fix it?

[benjann]

weird, looks like a bug, I'll try to fix this

[benjann]

Hi, I'm afraid I cannot reproduce the problem. Everything seem to work fine if I try to replicate your examples:

spshape2dta DNK_adm2, saving(DNK)
geoframe create DNK
frame DNK_shp: geo2xy _Y _X, replace
geoplot (area DNK) /// 1
    (area DNK, fc(Red*.5) select(inlist(ID_2,50))) /// 2
    (area DNK, fc(Red) select(inlist(ID_2,50))) /// 3
    , zoom(3: 3 200 0, box)

geoplot (area DNK) /// 1
    (area DNK, fc(Red*.5) select(inlist(ID_2,50))) /// 2
    (area DNK, fc(Red) select(inlist(ID_2,50))) /// 3
    , zoom(3: 3 200 0, circle)

Did you do anything specific with your data?

[Monefield]

I just downloaded the shapefile again and found the same as you - no problems. Then I remembered, that I had edited my old version a little bit using QGIS, so I opened the new shapefile in QGIS (Layer -> Add Layer -> Add Vector Layer). Then I exported the shapefile by right clicking the layer -> Export -> Save features as. And when I used this newly exported shapefile in Stata I get the same problem as I shown you. I seems like there is some problem with QGIS-generated shapefiles, but not geoplot :) I don't know what QGIS is doing, but I will try to look into it.

[benjann]

Can you provide the data you processed by QGIS (i.e. "this newly exported shapefile")? I can then try to find out what is going on; possibly, QGIS exports the data in a way that leads to confusion in geoframe/geoplot and maybe this is something I could fix.

[Monefield]

Yes, here you go DKKORT_QGIS.zip Please note that the geo2xy command now crashes. It seems like QGIS is changing the coordinates somehow. If you don't run the the geo2xy command you get what I got.

[benjann]

OK, thanks, it's a precision issue. There were a few instances in the code of zoom() where mata function strofreal() was used to store a number in a local. Unfortunately, the default format used by strofreal() is %9.0g, which is not precise enough for large numbers. I now changed this to %18.0g (which is about equivalent to double storage type) and everything works fine. The issue will be fixed in the next update.

(Of course, using locals to store numerical values is a bit sloppy programming, but sometimes it is just much more convenient than working with numerical scalars.)