سؤال

هل يعرف أحد التمثيل الأكثر كفاءة لإحداثيات خطوط العرض/الطول؟يجب أن يكون مستوى الدقة كافيًا لأجهزة GPS الاستهلاكية.

يبدو أن معظم التطبيقات تستخدم double لكل وحدة، ولكن أنا أشك في أن أ float أو يجب أن يكون تنسيق النقطة الثابتة كافيًا.سأكون فضوليًا لسماع آراء أي شخص حاول ضغط أو تخزين صفائف كبيرة من هذه القيم.

يحرر:

بمعنى آخر، ما هو الحد الأدنى من الدقة المطلوبة لتمثيل خطوط العرض/الطول لجهاز على مستوى المستهلك؟

هل كانت مفيدة؟

المحلول

أنا شخصياً سأستخدم تمثيل النقطة العشرية الثابتة 32 بت، مقسومًا على 1,000,000 وفقًا لإجابة إيفان وتعليقاتي.

ومع ذلك، إذا كانت المساحة حقًا ذات أهمية كبيرة، فإليك بعض الأفكار الإضافية:

  • يمكنك استخدام تمثيل نقطة ثابتة 26 بت على السلك.سيتطلب ذلك تنظيم خطوط الطول والعرض وإلغاء تنظيمها في مجموعة كبيرة من البايتات، ولكنه سيوفر لك 12 بت لكل موقع عبر تمثيل القيمة 32 بت - وهو توفير بنسبة 19% تقريبًا، لذلك قد يكون الأمر مفيدًا.

  • يمكنك الاستفادة من حقيقة أن قيم خطوط الطول تحتاج إلى دقة أقل كلما اقتربت من القطبين - فهي تحتاج فقط إلى 26 بت عند خط الاستواء.لذلك يمكنك كتابة مخطط يعتمد فيه عدد البتات المستخدمة لتشفير خط الطول على قيمة خط العرض.

  • إذا كانت بياناتك تحتوي على سمات أخرى قابلة للضغط - على سبيل المثال، جميع النقاط عادة ما تكون قريبة جدًا من بعضها البعض - فيمكنك الاستفادة بشكل خاص من تلك السمات، مثل استخدام نظام ترميز دلتا (حيث يمكن تشفير كل نقطة بخلاف الأولى كدلتا من الأخيرة نقطة).

نصائح أخرى

ومحيط الأرض تقريبا. 40،000 كم أو 24900 ميل.

وتحتاج إلى متر واحد دقة (3FT) لتكون قادرة على الخروج عزم تحديد المواقع بدقة بأمر من حجمها.

لذلك تحتاج precisiton لتخزين 40.000.000 قيم مختلفة. هذا في الحد الأدنى 26 بت من المعلومات. وهناك تعويم 32 بت أو كثافة العمليات بشكل جيد.

يحرر: بإضافة بعض النقاط من التعليقات، يجب أن تكون قيم 32 بت قادرة على تقديم دقة كافية.

سأستخدم تمثيل النقطة الثابتة 32 بت.إذا كانت القيم:

42.915512,-99.521654 سأقوم بتخزين values * 100000 في int32_t (يمكن أن تكون سلبية).

int32_t lat = 42915512;
int32_t lon = -99521654;

هذا حل وسط جيد بين البسيط والدقيق (5 عادة ما تكون النقاط العشرية جيدة بما فيه الكفاية، ويمكنك دائمًا رفعها إلى ما يصل 1000000 تحصل 6 إذا لزم الأمر).

لعرضه على المستخدم، افعل ما مقهى وتقترح:

...للعرض للمستخدم - استخدم عددا صحيحا تقسيم و modulo ، على سبيل المثال printf("Lat = %d.%06d\n", lat / 1000000, abs(lat) % 1000000)

وستكون هذه أيضًا قابلة للمقارنة/الفرز بطريقة فعالة حيث سيتم الحفاظ على الترتيب النسبي.

يحرر: هناك فائدة إضافية وهي أنه يمكن إرسالها عبر الشبكة أو تخزينها على القرص بتنسيق ثنائي بطريقة محمولة.

ستكون العوامات أكثر من كافية لتخزين إحداثيات نظام تحديد المواقع العالمي (GPS)، حتى لو كانت أجهزة نظام تحديد المواقع العالمي (GPS) على مستوى المستهلك قريبة من الدقة المطالب بها.إذا كنت لا تصدق أن هذا صحيح، جرب هاتين التجربتين البسيطتين:

  1. خذ جهازين أو أكثر من أجهزة نظام تحديد المواقع العالمي (GPS) إلى مكان واحد في حقل ما في مكان ما، وقم بتدوين الإحداثيات التي يقيسها كل جهاز.ارجع إلى الداخل وقم برسم النقاط من كل جهاز على الخريطة (أعتقد أن Google لديها شيء يفعل ذلك من أجلك).ستتفاجأ بمدى تباعد النقاط (على الرغم من أنه من المفترض أن تقيس جميعها نفس النقطة بالضبط).
  2. خذ جهازك (المزعوم) الأكثر دقة، وضعه في مكان حيث يمكن إصلاحه عبر القمر الصناعي ولكن دون أن تمطر عليه، وقم بتسجيل سلسلة من القياسات التي تم إجراؤها على مدار يومين.ارسم جميع القراءات (كما في رقم 1).مرة أخرى، ستفاجأ بكيفية تجول النقاط (التي يجب أن تكون متماثلة أو متشابهة تقريبًا) في جميع أنحاء الخريطة، وأحيانًا بما يصل إلى بضع مئات من الأقدام.

لقد قمت بكتابة طلبات لأجهزة المساعد الرقمي الشخصي التي تدعم نظام تحديد المواقع العالمي (GPS) لسنوات، ولقد تحققت من ذلك للعملاء المشكوك فيهم مرارًا وتكرارًا (حتى أنني فزت بالرهانات بهذه الطريقة).هناك أجهزة GPS عالية الجودة تحقق دقة أفضل من ذلك، ولكن يتم تحقيق الدقة الأفضل باستخدام شرائح أكثر تكلفة، ويتم ترك الأجهزة في مكان واحد لعدة أيام أو حتى أسابيع، مع متوسط ​​القراءات بمرور الوقت.

يعد التعويم ذو الأربعة بايت أكثر دقة بكثير من الأجهزة نفسها.بالطبع لن يؤذيك على الإطلاق استخدام عامل مزدوج بدلاً من ذلك، طالما أن العامل 2X لا يمثل مشكلة بالنسبة لك.

و23 بت من الدقة في 179 درجة من خط الطول يعطي دقة تحت 10 مترا، وهو أفضل ما تعطي أجهزة GPS العادية. عند خط الاستواء:

% gps distance "0.0, 179.0" "0.0, $((179 * (1 + 2**-23)))"
From 0.0, 179.0 to 0.0, 179.00002133846283 is 7.79 feet E
From 0.0, 179.0 to 0.0, 179.00002133846283 is 2.38 meters E

وهكذا وIEEE 754 واحدة الدقة عدد الفاصلة العائمة، والمعروف أن مترجم C الخاص بك كما float، فيل يكون مجرد الكافي للتمثيل. حذار من استخدام عوامات لحسابات بمد! التقريب خطأ قد تناول الغداء الخاص بك. استشارة المحلل العددي.

في تنسيق خريطة IMG الخاص بـ Garmin، يقومون بتخزين الإحداثيات داخل المربعات المحيطة باستخدام العوامات لتعيين حواف المربعات.يتم تعريف الإحداثيات داخل المربعات باستخدام عدد متغير من البتات التي تكون خطية فقط بين قيم الحد الأدنى والحد الأقصى اعتمادًا على الدقة المطلوبة.

على سبيل المثال: مينلات=49.0، ماكسلات=50.0، مينلون=122.0، ماكسلون=123.0، عدد البتات=16

لذلك قيمة:
سيتم تحويل 32768,32768 إلى 49.5، 122.5
16384,0 سيكون 49.25، 122.0

إذا كنت بحاجة إلى دقة أقل، فيمكن إنشاء نفس الإخراج بعدد البتات = 4
سيتم تحويل 8,8 إلى 49.5، 122.5
4,0 سيكون 49.25، 122.0

إذا كنت تخزين صفائف كبيرة من هذه القيم، وهناك بعض الحيل البسيطة إذا كنت تفعل ضغط دلتا، ودلتا مخزن، يمكنك يقلل كثيرا من حجم تدفق البيانات. يمكنك أن تفعل دلتا من "النقطة الرئيسية"

وK D D D D D D D D D D D D D K D ...

ك + د تحصل على أي نقطة د

وودلتا عن مرجع K السابق، وذلك لإعادة أي لحظة، كنت في حاجة الى K وD

وأو يمكنك القيام دلتا incrimental

وK I I I I I I I I I I K

وهذا قد يستغرق مبالغ متعددة للوصول إلى الموضع المطلوب. ولكن البيانات أصغر بشكل عام. SO لreconsturct

ك + أنا + أنا + أنا للوصول الى نقطة 4TH

وأخيرا يمكنك الجمع بين كلا

وK D I I I I I I D D I I I K

وهذا هو مثل MPEG-2 مع إطارات الشخصي، ولكن هذه الطريقة أنت أبدا أكثر من 4 المبالغ إلى أي موقف، وتحصل على بعض الفوائد من الدلتا وIncrimental ضغط.

يمكنك حزم كل من خط العرض وخط الطول القيم في أ عدد صحيح واحد 32 بت بدقة تصل في أسوأ الأحوال إلى 2.4 متر/بكسل (عند خط الاستواء) إذا كنت تستخدم نظام تبليط متكرر.باستخدام بتتين لكل مستوى، يمكنك تخزين 16 مستوى في 32 بت.يمكنك الحصول على فكرة عن كيفية عمل ذلك من خلال الاطلاع على هذه المقالة نظام تبليط الأرض الافتراضية.هذا يستخدم مركاتور، لذلك سوف يسبب لك مشاكل للأعمدة.يمكنك بدلاً من ذلك استخدام إسقاط مختلف والحصول على نتائج مشابهة جدًا.

يمكن استخدام هذا أيضًا لـ مرشح خشن للعثور على أي نقاط داخل التجانب الأصلي المحدد نظرًا لأن البتات N الأولى ستكون هي نفسها (وبالتالي يصبح البحث إخفاء البتات).

وعلى افتراض أن الأرض هي المجال الأمثل (لم يكن، ولكنه قريب بما فيه الكفاية) مع دائرة نصف قطرها 'R' من 3959 ميلا (أو × 5280 قدم / ميل = 20903520 قدم)، ومحيط هو 131340690 قدم (باستخدام 2 × PI × R).

360 درجة من خط الطول تغطي 131340690 القدمين. 180 درجة من خط العرض يغطي 65670345 قدم.

إذا كنت تريد تخزين خطوط الطول / العرض للغاز الطبيعي المسال وصولا الى دقة 3 أقدام، عليك أن تكون قادرا على تخزين 43780230 قيمة (131340690/3) خطوط الطول و21890115 (65670345/3) القيم خطوط العرض. 43780230 يتطلب 25.38 بت (السجل (43780230) / السجل (2)) لتخزين و21890115 يتطلب 24.38 بت (السجل (21890115) / السجل (2)) لتخزين - أو ما يقل قليلا عن 50 بت (أو 6.25 بايت)

وهكذا يصبح السؤال الذي يطرح نفسه، إذا كنت تريد تخزين خطوط الطول والعرض في بايت فقط 6، ماذا ستكون الدقة؟ حسنا، 6 بايت هو 48 بت. وهذا يعني أن 23.5 بت لخطوط الطول والعرض 24.5 بت ل(خط الطول ديه ضعف العديد من القيم، الذي هو مجرد حرف واحد و24،5-23،5 = 1 بت). حتى 23.5 بت يسمح لك لتمثيل عدد 0-11٬863٬282 (11863283 القيم). وقدم 65670345 11863283 مقسوما القيم هي 5.53 قدم (ونفس قيمة دقة عن العرض).

THE BOTTOM LINE:. لذا، إذا كنت تستطيع العيش مع 5.5 أقدام دقة لكل من خطوط الطول والعرض، يمكنك حزمة كلا القيم في بايت ستة فقط

و* A SIDE ملاحظة: بخصوص التعليقات التي خط العرض والطول هي الرهيبة لتخزين المعلومات الموضعية حول المجال (لعدم وجود معلومات أقل لتخزين في القطبين) - حسنا، هذه التعليقات لا تصمد إلى الرياضيات! دعونا الرقم بها. دعونا نقول أننا نريد لتصميم نظام مثالي الجديدة التي يمكن أن تسجل ووضع حصة في الأرض في وسط كل قدم مربع من الأرض. وتبلغ مساحة الأرض (مع R من 3959 ميلا، صيغة لمساحة سطح الكرة) هي 5490965469267303 SQ FT - أن العديد من المخاطر تتطلب 52.29 بت لتمثيل. الآن نظام خطوط الطول والعرض الحالي يستخدم نظام مستطيلة. عرض المستطيل هو محيط الأرض وارتفاع المستطيل 1/2 محيط) - وهو 131340690 * 65670345 (انظر أعلى بكثير)، أو 8625188424838050 SQ FT - الذي يتطلب 52.94 بت لتمثيل (هذه الأماكن نظام المخاطر "عدد كبير جدا" في جميع أنحاء الأرض على أعمدة). لذا، فإن الإجابة الصادمة هي أن كلا من نظام مثالي جديد، ونظام للغاز الطبيعي المسال / اللات القديم، فإن كلا تتطلب 53 بت الفعلية لتخزين موقع واحد على وجه الأرض، وصولا الى دقة 1 قدم!

وأنا مندهش أن أحدا لم تنشر حقيقة طويل / خطوط الطول هو وسيلة رهيبة لتخزين البيانات على المجال (شخص ما لم أذكر أن العرض يتطلب أقل دقة بالقرب من القطبين).

وأساسا يمكنك تخزين الموقف البيانات وX و Y المشارك ords بالأمتار. تخيل مكعب في جميع أنحاء الأرض أن exactally نوبات (هاها طيب <م> تقريبا يناسب ذلك). ما عليك سوى مخزن X و Y الموقف، وليس كل زملاء ords 3، لأن 3-RD المشارك أورد يمكن أن تأتي من redius الأرض، ص = الجذر التربيعي [س ^ 2 + ص ^ 2 + Z ^ 2] .

وهكذا تحويل الخاص بك خطوط الطول / العرض لس / ص بالأمتار. وسوف تحتاج فقط ما مجموعه 12756200m في المشترك أورد (أن يكون أقطار الأرض). لذلك القيمة الإجمالية الخاصة بك وسوف لا تملك إلا أن تمتد 0 إلى 25512400 (شخص آخر ادعى 40،000،000 لأنهم كانوا يستخدمون طويل / اللات) أن تكون دقيقة إلى +/- 0.5M.

وهذا سيؤدي إلى بت فقط 25 في الموقف. إذا كنت أنت وأود أن مجرد القيام الدقة لفي 2M واستخدام 24 بت لكل موقف، وهذا هو مرتبة 3 بايت.

وأيضا إذا كنت تخزين المعلومات إحداثية على مسار، يمكنك تخزين كل إحداثية كما إزاحة من إحداثية الماضي. مثل تبدأ مع 24bit س / ص ك-أورد. ومن ثم يكون لها 16BIT 'تحديث' أن يعدل الموقف من خلال إضافة / الطرح س / متر ذ. سوف 16bit وسماح تحديث إحداثية ليكون أكثر 400M بعيدا. حتى إذا كنت تعرف وليس المقصود الجهاز للطائرات والتحديثات في كثير من الأحيان كل ذلك، وهذا قد يكون مقبولا للغاية.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top