Kan nogen give mig et link (eller nogle detaljer) om det faktiske forhold til “zoomniveau” for Google Maps?
f.eks Google Maps niveau 13 = 1: 20000
Kommentarer
- Baseret på de første oplysninger, jeg lavede denne funktion, kunne nogen måske bruge den! funktions sætZoomLevel (meter) {//console.log(
Zoom level set meters: ${meters}
); var zoomfaktor = 1; hvis (meter < 1128) {zoomfactor = 15; } ellers hvis ((meter > 1128) & & (meter < 2256)) {zoomfactor = 14; } ellers hvis ((meter > 2256) & & (meter < 4513)) {zoomfactor = 13; } ellers hvis ((meter > 4513) & & (meter < 9027)) {zoomfactor = 12; } ellers hvis ((meter > 9027) & & (meter < 18055)) {zoomfactor = 11; } ellers hvis ((meter > 18055) & & (meter < 36111)) {zoomfactor = 10; } ellers hvis ((meter > 36111) & & (meter < 72
Svar
Hvis du designer et kort, planlægger du at overlejre over google maps eller virtuel jord og oprette et fliseskema, så tror jeg, hvad du leder efter, er skalaerne for hvert zoomniveau, brug disse:
20 : 1128.497220 19 : 2256.994440 18 : 4513.988880 17 : 9027.977761 16 : 18055.955520 15 : 36111.911040 14 : 72223.822090 13 : 144447.644200 12 : 288895.288400 11 : 577790.576700 10 : 1155581.153000 9 : 2311162.307000 8 : 4622324.614000 7 : 9244649.227000 6 : 18489298.450000 5 : 36978596.910000 4 : 73957193.820000 3 : 147914387.600000 2 : 295828775.300000 1 : 591657550.500000
Kilde : http://webhelp.esri.com/arcgisserver/9.3/java/index.htm#designing_overlay_gm_mve.htm
Kommentarer
- @capdragon Tak. Det ‘ er en velkendt kilde (ESRI), men det lader os stadig undre os over, hvordan de kom op med disse skalaer.
- Rationelt er kritisk for hvem? Jeg kan ikke ‘ ikke se nogen omtale af rationel i spørgsmålet. Jeg mener, at han ønsker et ligetil svar på sit ligefremme spørgsmål.
- @ cap Uden grund er det ‘ svært eller umuligt at skelne et korrekt svar fra en forkert. Uden grund er man tilbage at skulle stole på besvarelsens autoritet. Jeg ‘ er ret sikker på, at årsagen til, at de andre svar i denne tråd bliver stemt op, og din ikke er ‘ t har lidt at gøre med korrekthed eller ligefremhed – din er den mest autoritative og ligefremme af flokken – men har snarere alt at gøre med ræsonnementet fra de andre. BTW Jeg har ikke ‘ t nedstemte din.
- Tak: +1. I er sandsynligvis geografer eller fjernmåler-guruer. Jeg ‘ er kun en GIS-udvikler, der ønsker at hjælpe fyren med at nå sit svar. En kollega af mig (PHD-type, dobbelt MIT-dur) går i en times forelæsning hver gang jeg stiller ham et simpelt spørgsmål og mister mig undervejs. Jeg stiller ‘ ikke flere spørgsmål til ham (jeg har en kandidatgrad inden for videnskab). Jeg forstår, at andre mennesker kan lide at komme ind i kødet af rationelt og så videre, men mange af os er for uvidende til at vide, hvad de taler om. IMHO var de forvirrende svar, der ikke ‘ t besvarede hans spørgsmål.
- Vægten blev valgt, så de kan deles jævnt med rasterfliser, der er i base 2 , (f.eks. 128, 512 …). Bing gør det på samme måde msdn.microsoft.com/en-us/library/bb259689.aspx
Svar
Jeg fandt dette svar – skrevet af en Google-medarbejder – dette ville sandsynligvis være det mest nøjagtige:
Dette vil ikke være nøjagtigt, fordi opløsningen på et kort med mercatorprojektionen (som Google maps) er afhængig af breddegraden.
Det er muligt at beregne ved hjælp af denne formel:
metersPerPx = 156543.03392 * Math.cos(latLng.lat() * Math.PI / 180) / Math.pow(2, zoom)
Dette er baseret på den antagelse, at jordens radius er 6378137m. Hvilken er den værdi, vi bruger 🙂
taget fra: https://groups.google.com/forum/#!topic/google-maps-js-api-v3/hDRO4oHVSeM
BTW – Jeg gætter på det:
"latLng.lat()" = map.getCenter().lat() "zoom" = map.getZoom()
Kommentarer
- HVAD er lig med din formel? Gør det for lat = 2.92 og zoom 13 fik jeg 19.08. Hvad er 19.08 hvad?
- @Rodrigo meter pr. Pixel
- Jeg kan vidne om, at dette svar stadig er korrekt og meget præcist tre år senere. Dette skal være det accepterede svar.
- Gælder dette kun for x eller også for y ? Bruger Google Maps via Javascript API den samme skala til begge akser?
- @OldGeezer Ja det fungerer i alle retninger. Lineær forvrængning til enhver tid i Mercator er lige i alle retninger. At ‘ er en af grundene til, at det bliver brugt til glatte kort. Når du zoomer ind, får du et rimeligt lavt forvrængningskort. når du kompenserer for skala, hvilket er hvad dette svar gør.
Svar
For at hjælpe dig med at forstå matematikken (ikke en præcis beregning, det er bare for at illustrere):
- Googles webkortflise har 256 pixels bredde
-
lad os sige din computerskærm har 100 pixels per tomme (PPI). Det betyder, at 256 pixels er ca. 6,5 cm lange. Og at “s 0,065 m .
-
på zoomniveau 0 , hele 360 grader af længdegrad er synlige i en enkelt flise . Du kan ikke observere dette i Google Maps, da det automatisk flytter til zoomniveau 1, men du kan se det på OpenStreetMap “kort (det bruger det samme fliseskema
-
360 nedgang på ækvator er lig med jordens omkreds, 40.075,16 km, hvilket er 40075160 m
-
opdele 40075160 m med 0,065 m og du får 616313361 , som er en skala for zoomniveau 0 på ækvator til en computerskærm med 100 DPI
- så pointen er, at skalaen afhænger af skærmens PPI og af breddegraden (på grund af Mercator-projektionen)
- for zoomniveau 1, skalaen er halvdelen af zoomniveauet 0
- …
- for zoomniveau N, skalaen er en hal f af zoomniveauet N-1
Kommentarer
- Skalaen er faktisk afhængig af DPI for de genererede kortbilleder. De to mest anvendte opløsninger er 96DPI (at ‘ er, hvad Google-kortfliser er) og 72DPI.
- Med 96DPI er skalaen
591657550.500000
er niveau 0 ifølge dette svar. Men ifølge @CaptDragon er niveau 1. Jeg bør overveje at starte fra niveau 1 for at beregne med Google Maps?
Svar
Ikke så let. I betragtning af projektionen afhænger størrelsen af flisepixel af bredden af det område, du er interesseret i. Derefter afhænger det af skærmen og den opløsning, dataene vises på dpi din skærm bruger.
Kommentarer
- Det er korrekt, sfærisk mercator (google projektion) ‘ t bevarer lige målestok, når du bevæger dig væk fra ækvator. For nogle fremragende referencer: Mapnik ‘ s Skala- og skaleringsnævnere artikel: trac.mapnik.org/wiki/ScaleAndPpi og OSM ‘ s Ofte stillede spørgsmål: wiki.openstreetmap.org/ wiki / …
Svar
Ligetil autoritativt rigtigt svar:
591657550.500000 / 2^(level-1)
det giver dig tabellen ovenfor ved at indtaste zoomniveauet.
Prøv det live på jsfiddle.net
Fordi spørgsmålet kun er til Google MAPS, ikke EARTH, er OP ikke ligeglad med 3D-geometri. Google maps er allerede fladtrykt, så 1 pixel er altid den samme afstand (i DEGREES, hvilket er det, der vedrører et google-kort), her og i ekuatoren som i polerne.
Forresten, gjorde du indse, at et eller andet sted inden for den første pixelrække på et verdenskort er skalaen 1: 1?
Kommentarer
- Hvad betyder tallet 591657550.500000 repræsentere?
- @Sergio hvorfor ikke bare 591657550.5?
- ” Nummeret kommer fra, at fliseopløsningen er indstillet til et multiple på 256 pixels og fra skærmopløsningen (96dpi) ” gis.stackexchange.com/a/111589/ 92997
- Virker ikke – det afhænger af Latitude, men din formel er ikke
Svar
Der er en sådan tabel i dokumentationen til Virtal Earth Tile System fra Microsoft . Men som sagt af GuillaumeC afhænger værdierne af breddegrad og videre skærmopløsningen. Tabellen giver værdier som målt ved ækvator og med en skærmopløsning på 96 dpi.
PS: Ikke sikker på det, men zoomniveauerne fra Microsoft kan forskydes med 1 i forhold til zoomniveauerne ved Google.Men de bruger definitivt den samme projektion, så værdierne forbliver korrekte for Google.
Svar
Radius @ ækvator 6.378.137 meter nøjagtig ( WGS-84)
Omkreds ved ækvator = 40.075.017 meter (2πr)
Zoomniveau 24 bruger 2 til de 32 effekt (4.294.967.296) pixels ved omkredsen.
Ækvatorial omkreds / 2 32 = .009330692 meter pr. Pixel
Enhed ved breddegrad = (Cosine af breddegrad) X (enhed ved ækvator)
Zoomniveau fordobler hvert trin.
1 fod (International) = 0,3048 meter
Rediger
Nå, det er ikke rigtig et legitimt spørgsmål til at begynde med. Skalaforhold er i forhold til trykte dokumenter, ikke computerskærme. Det, du har brug for, for at disse billeder kan bruges med en hvilken som helst nøjagtighed, er at kende dimensionen på hver pixel og derefter skalere billedet i henhold til hvad du lægger det over.
Så tilbage for 15-20 år siden tog nogen WGS- 84 som basisdata. (bemærk i et tidligere indlæg brugte nogen en værdi på 40.075.160 Jeg har set dette på Wikipedia et par steder, og det er forkert. Den korrekte værdi er 40.075.017
De tog det derefter og delte det med en fuld 32 bit heltal. Dette er et logisk valg, da det giver global nøjagtighed til ca. en centimeter, hvilket er rigeligt til luftbilleder. 32 bit heltal er også effektive til at gemme og behandle.
Hvorfor dette niveau 24 blev valgt Jeg ved det dog ikke, da en anden her udarbejdet 0 får dig ned til en 256 pixel flise til jorden.
Nu for et eksempel på, hvordan du bruger ovenstående data. Lad os sige, at jeg har et billede på zoomniveau 20 (så zoomet som de i øjeblikket giver dig mulighed) Tag 0.009330692 (Zoom 24 ved ækvator) dobbelt så for zoom 23, igen for zoom 22, igen for zoom 21 og en sidste gang for zoom 20. Du skal nu have 0.149231071 .
Lad os sige, at vores billede er på 45. breddegrad. Tag Cosine af det (0.707106781) og gang det med vores 0.149231071, og det giver dig 0.105564729 meter s. Det er længden og højden af en pixel fra et billede i breddegrad 45 på zoomniveau 20. Hvis du skærmoptager et 1000 x 1000 pixelbillede af dette område, er dimensionen 105,56 meter kvadratisk. Hvis du vil have fødder, skal du dele det 0,3048
Hvad angår kilder, vendte jeg essensielt om for ca. 5 år siden fra forskellige oplysninger og dokumentation, jeg fandt på nettet, herunder Google og MS-supportwebsteder.
Jeg har brugt hundrede af tid og lagt det med faktisk feltundersøgelsesdata, og det har altid været korrekt. Kontroller det mod en hvilken som helst af de tabeller, der er indsendt her, og tallene svarer.
Kommentarer
- I ‘ Jeg er ikke sikker på, hvordan dette besvarer spørgsmålet.
- Jeg er enig med @Devdatta, kan du give en kilde og en vis kontekst.
- Ikke sikker på, om disse kommentarer var før eller efter rediger, men jeg brugte dette svar, og det fungerer godt
Svar
Bare lavede nogle beregninger og fik følgende resultater:
Google Maps viser en 1 km lineal (nederst til venstre på kortet) med en længde på 90 pixels på zoomniveau 13. Hvilket betyder følgende:
Under forudsætning af skærmopløsningen er 96 dpi eller 36 dpcm, på zoomniveau 13 har vi 0,4 km (fra 36/90) i 1 cm, hvilket giver en kortskala på 1: 40.000 for en 96 dpi-skærm.
Til forskellige handlinger på skærmen det bedste er at tage 90 pixel som basis, da alle numre vil være runde på alle zoomniveauer, dvs.
- Zoomniveau 12: 2 km i 90px
- Zoomniveau l 11: 4 km i 90 pixel
- Zoomniveau 10: 8 km i 90 pixel
og så videre.
Bemærk at dette er en tilnærmelse, der skal arbejde mere eller mindre fint på mindre skalaer end store.
(Og Google kan lide runde tal i sidste ende …)
Kommentarer
- Hvis du ser nøje på, vil du ‘ opdage, at længden af linjen ændres afhængigt af bredden af det område, du ‘ re visning.
- Dette er kun gyldigt på en bestemt breddegrad, som @rcoup nævnte. Ikke kun længden på skalaen varierer, men også den afstand, den repræsenterer. For at fortsætte dette eksempel ved zoom 13 er afstanden repræsenteret af skalaen 2 km i North Cape (71 ° latitude), 1 km omkring 45 ° breddegrad og 500 m ved ækvator.
Svar
Baseret på alle de angivne oplysninger , Jeg har bygget en funktion, der giver den bedste z, der anvendes på et kort, når du vil have en vandret linje, der repræsenterer N% af det viste kort.
Det viste kort er kendetegnet ved sin egen pixelbredde.
function calculateZoom(WidthPixel,Ratio,Lat,Length){ // from a segment Length (km), // with size ratio of the segment expected on a map (70%), // with a map WidthPixel width in pixels (100px), // and a latitude (45°) we can get the best Zoom // assume earth is a perfect ball with radius : 6,378,137m and // circumference at the equator = 40,075,016.7 m // The full world on google map is available in tiles of 256 px; // it has a ratio of 156543.03392 (px/m). // For Z = 0; // pixel scale at the Lat_level is ( 156543,03392 * cos ( PI * (Lat/180) )) // The map scale increases at the rate of square root of Z. // Length = Length *1000; //Length is in Km var k = WidthPixel * 156543.03392 * Math.cos(Lat * Math.PI / 180); //k = circumference of the world at the Lat_level, for Z=0 var myZoom = Math.round( Math.log( (Ratio * k)/(Length*100) )/Math.LN2 ); myZoom = myZoom -1; // Z starts from 0 instead of 1 //console.log("calculateZoom: width "+WidthPixel+" Ratio "+Ratio+" Lat "+Lat+" length "+Length+" (m) calculated zoom "+ myZoom); // not used but it could be useful for some: Part of the world size at the Lat MapDim = k /Math.pow(2,myZoom); //console.log("calculateZoom: size of the map at the Lat: "+MapDim + " meters."); //console.log("calculateZoom: world circumference at the Lat: " +k+ " meters."); return(myZoom); }
Svar
Jeg kan ikke tilføje en kommentar endnu, men dette er en mulig kilde til Petes svar ovenfor: https://developers.google.com/maps/documentation/javascript/maptypes#MapCoordinates
[…] bemærk, at hvert stigende zoomniveau er dobbelt så stort i både x- og y-retningen. Derfor indeholder hvert højere zoomniveau fire gange så meget opløsning som det foregående niveau. For eksempel på zoomniveau 1 består kortet af 4 256×256 pixels fliser, hvilket resulterer i et pixelrum fra 512×512. På zoomniveau 19 kan der refereres til hver x og y-pixel på kortet ved hjælp af en værdi mellem 0 og 256 * 2 19
Svar
Jeg beregnede skalaerne for fire zoomniveauer:
Zoomniveau | Skala 20 1: 500 19 1: 1000 18 1: 2000 17 1: 4000
Det ser ud til, at skalaen fordobles, når zoomniveauet steg med et trin. Så jeg håber, at skalaen for zoomniveau 16 bliver 1: 8000 og så videre.
Kommentarer
- Velkommen til GIS.SE! Kan du venligst angive en kilde, eller hvordan blev dette beregnet?
Svar
Hej jeg tror jeg har beregnet det 1pixel = 11,627 km i lige linje; uden at tage hensyn til jordens radius. Her linket til videoen, der forklarer hvordan: https://www.youtube.com/watch?v=Y3cvTeiMJqE&feature=youtu.be . Håber at rydde dit sind.
Kommentarer
- Det gør det ikke. Værdien af en pixel afhænger af breddegrad.
- Åh jeg kan se, ikke det komplekse jeg gik ind i.