Bir CBS geliştiricisi olarak en büyük zorluklarınız neler?

GIS yazılımı geliştirirken en büyük zorluklarınız nelerdir?

Kodlama mı? Haritacılık / coğrafya / etc kavramlarını (projeksiyonlar gibi) anlıyor mu? Veya diğer zorluklar?

Neredeyse 5 yıl önce ESRI / GIS gelişim sahnesine giren bir geliştirici olarak deneyimlerime dayanarak:

1. Ne yapmak istediğinizi yapacak tek bir API yok. Yalnızca amaçlarınız için çalışabilecek veya çalışmayabilecek karıştırılmış bir API karmaşası: ArcObjects, Python, REST, SOAP, ADF, ST_Geometry operatörleri?
2. Tüm API'ler, uygulamanızın özüne yerleştirmeyi tercih etmeyeceğiniz bazı pahalı, pahalı yazılımlara bağlanır.
3. Gerçekten yaratıcı tasarım için çok az fırsat. Nesneye yönelik coğrafi veri yapıları? Unut gitsin. "Nesneler" ve "özellik sınıfları" hakkındaki tüm konuşmaya rağmen, hala kaprisli yazılım aracılığındaki aptal masalarla çalışıyorsunuz.
4. Yazılım bozuk, hata mesajları yanıltıcı ve dokümantasyon eksik. Sorun giderme hemen hemen her zaman deneme yanılmadır. Alışmak.
5. İlişkisel veritabanı yöntemlerini kullanarak coğrafi verileri yönetmek neredeyse imkansızdır. Herhangi bir SQL / DDL'den vazgeçmek zorunda kaldım çünkü ara katman yazılımları ile başımı derde sokuyorlar (evet, ArcSDE hakkında konuşuyorum). Yeteneğin tamamını atmak utanç verici. Sadece ArcCatalog'u açın, işaretleyin, tıklayın.

Anlatabileceğiniz gibi, ESRI geliştirme sahnesinde oldukça olumsuz bir bakış açısına sahibim. Coğrafya geçmişinden gelenler için olasılıkların oldukça heyecan verici olduğundan eminim. Ancak ilişkisel veritabanlarını, nesne yönelimli programlamayı ve yaratıcı çözümler için geniş açık fırsatı seven benim gibi biri için, ESRI ile GIS gelişimi çok kısıtlayıcı ve tatmin edici değil. Bu utanç verici çünkü eski okul kalabalığı Microsoft'a uyumdan önce üstün bir ortam olduğunu söyledi. Umarım açık kaynak topluluğunun yeniliklere devam edeceğini umuyorum.

Büyük miktarda veri. Web teknolojisini kullanarak büyük miktarda veri ayıklamanın doğru yolunu bulmak zor oldu. Çok fazla veriye ve düşük performansa sahip olabiliriz veya çok daha az veri görüntüleniyor olabilir, ancak potansiyel olarak yanlış bilgileri de iletebiliriz.

Ben bir CBS geliştiricisi değilim; Ancak, ben bir CBS modelleri:

Zorluklar:

• Veri toplama, toplama, ayrıştırma, birleştirme ve bölme: Farklı projeler için çeşitli kaynaklardan veri alıyorum; En büyük sorun genellikle aynı coğrafi parsel / alan için tüm verileri elde etmektir. Proje için tutarlı bir örnek almak için genellikle her veri setinde yukarıda belirtilen tekniklerden birkaçını kullanmam gerekir. Bu hata olasılığını artırır ve hassasiyetimizi azaltıyor.

• Ben bir geliştirici değilim; Ben bir geliştirici değilim tekrar ediyorum: Siz sevimli insanlar SOAP, SHAMPOO, REST, GIS-T Endeksleri, vb. Hakkında konuştuğunuzda bu sizin için çok önemli. Bana göre çoğunlukla bu jargon. Genelde basit bir şeyler yapmak için büyük bir öğrenme eğrisi veya dik bir tırmanışım var.

• FOSS ve Tescilli Yazılımlar arasındaki boşluk: QGIS'i seviyorum ve ölümüne postgis yapıyorum; tam anlamıyla onları her makineye kurduk; Bununla birlikte, taşımayı temel alan bir analiz yapmak istediğimde TransCAD veya EMME2 / 3'e başvurmak zorundayım. Her çan ve ıslık ile birlikte yaklaşık 15.000 dolar. Adalet, shp dosyaları için bir ağ paketi varsa, tüm bu sorunlar çözülebilir.

• Çoklu disiplin sorunu: Ulaştırma modelleme tekniklerinde çok iyi bilgiliyim; ancak demografik modellemeyi emmek ve söyleyebileceğim kadarıyla, verilerimi elde etmek için karmaşık R araçları kullanmam gerekiyor. Dolayısıyla GIS Problemi, GIS'in kendi başınıza hayatta kalmak zor, multidisipliner bir alan olmasıdır.

• Görüntü arazi kullanımından vektör arazi kullanımına geçmek için iyi kurulmuş araç ve yazılımların bulunmaması: Bir aracın GEOEYE uydu görüntüsünü analiz edeceği ve içindeki toprak kullanımlarını bir vektörle (yerleşik olarak) veritabanıyla karşılaştıracağı bir gelecek öngörüyorum

• Bazen Excel'de işler yapmak daha hızlıdır / "fav spread sheet programınız buraya gelir: Bazen transit analizi yapmak isterim, daha iyi hale getirmek, formülleri çalıştırmak, sonra verileri boşaltmak, daha sonra verileri boşaltmak için çok daha hızlıdır. Bir csv dosyası olarak postgis'e dönüştürülür ve haritayı yeniden oluşturur.Özellikle OpenSource dünyasında böyle bir bölünme daha iyi ele alınmalıdır.

Neyse, sana doğru cevap vermemiş olabilirim; GIS programlamasına gelince iyi dilek tutmayı dilerdim, böylece CBS modellemesinde başarılı olabilirim.

En önemli şeyler ve genellikle benim deneyimimdeki en zor şeyler:

1. iş için doğru verileri almak
2. uygun projeksiyonda gösterilmesini sağlamak (ve tüm katmanların aynı fikirde olmasını sağlamak). Özellikle farklı kaynaklardan geldiklerinde
3. kullanışlı bir uygulama tasarlar. Sadece kullanıcıları şaşırtacak çok sayıda zil ve ıslık koymak kolay ve caziptir

Sanırım bu nokta 1 gelişmiş ülkelerde daha kolay olacak, ama bu benim deneyimim değil.

Bana göre en büyük zorluk, belirli bir proje için hangi araçların kullanılacağına karar vermektir. Açık kaynak mı yoksa tescilli mi? Python veya .NET? Web tabanlı veya masaüstü? Bu soruları farklı projeler için farklı şekillerde cevaplıyorum ve insanların bu sitede hepsini soracaklarından eminim. Birçoğu kişisel tercihlere dayanıyor ve gelecekte ESRI ve Microsoft'un destekleyeceği ilahi olmaya çalışıyor.

Benim meselem tamamen at ve su ile ilgili. Pek çok durumda, müşterilerimiz için gerçekten iyi çözümler geliştirir ve sunarız, ancak çözüm ne kadar zarif olursa olsun, hiç kimsenin zaman harcamasına gerek kalmaması kesinlikle işe yaramaz. Bazı durumlarda, iş kullanıcılarımızı temel alarak (sorunları araştırmak, geliştirmeden önce çözümler hakkında konuşmak) bu durumu hafifletebildik, ancak bazı durumlarda bu hala yeterli değil.

Bence en zor iş, CBS'yi anlamak için yönetimi almak ve bazı kullanıcıları da anlamadı. Algı, CBS'nin bir harita yapmakla ilgili olduğu; Bir haritanın, herhangi bir CBS endüstrisinin tek sonucudur. Bunu ne kadar sinir bozucu bulduğumu söyleyemem - dışarıdaki cehalet seviyesi çok büyük ve kilit karar vericiler tarafından tutulur.

Nihayetinde - biz öncü GIS uzmanlarından ve programcılarından biriyiz - sonunda yönetim olacak ve sonunda nezih GIS projeleri gerçekleştirebiliriz!

Bir CBS programcısı olarak diğer zor şey - birçok farklı teknolojiyi, Java'yı, .NET'i, veritabanlarını, ESRI yazılımını veya diğer satıcıları, yani MapInfo, ağları, güvenliği, web tekniğini, vb. Anlamanız gerekir. Bazen, neredeyse imkansız bir iş!

Profesyonel yazılım geliştirme tekniklerini ve metodolojilerini anlamayan, ancak kendilerine cadde / VB'yi nasıl kodlayacaklarını öğrettiği için anket altyapısından insanlarla çalışmak.

Vinko'nun cevabından # 3 :

kullanışlı bir uygulama tasarlar. Sadece kullanıcıları şaşırtacak çok sayıda zil ve ıslık koymak kolay ve caziptir.

Tüm cevaba oy verirdim, ancak kullanılabilirliğin listesindeki yalnızca üçüncü madde olduğu ve ilk ikisinin bu kadar zor olduğunu sanmıyorum.

Kullanılabilirlik, sorunların çoğunun olduğu ve tasarım / geliştirme süresinin çoğunu nerede harcadığım, akıllı ve etkili bir kullanıcı arayüzü tasarlamanın nasıl olduğunu bularak, ancak kullanıcıların onun kafasını karıştırmaması için sezgisel olmasını sağlar, örneğin:

• İlgili bilgileri göstermek ve etkileşimli bir haritanın stilini ayarlamak (ve katmanları seçmek) ve çok fazla veri göstererek ortaya çıkan karışıklığı önlemek (örneğin, nokta özelliklerinin otomatik toplanmasını kullanarak); kartografinin uzun zamandır çözmeye çalıştığı şeyin bu olduğunu biliyorum, ancak sorun yalnızca dijital / etkileşimli haritalarda daha da kötüye gidiyor

• Harita görünümü otomatik olarak kullanıcının sorgu / özellik seçimine göre nasıl yapılır

• 'Seçili' özelliklerin vurgulanması - vurguyu kısaca gösterir misiniz, bir özelliğin seçildiği süre boyunca vurgulu mu seçtiniz, seçim tablosu (veya liste) odağı kaybettiğinde vurgulamıyor musunuz? bir tablodan ve o tablodaki seçili satırdan (çok fazla geçiş düğmesi olmadan) sonuçları

• Katman veya özellik listelerinde ek bilgi gösteriliyor, örneğin katmanın görünürlüğü / uygulamalı stil / geometri türü, özelliğin durumu / sınıfı ... Aynı listede görüntülenen farklı özellik türlerinin olması durumunda daha da karmaşıklaşıyor (sanırım bu yüzden Google ve Bing Haritalar, arama sonuçlarına oldukça fazla filtre uygular)

• Verimli düzenleme: çok sayıda araç çubuğu düğmesi olmadan yakalama, çokgenlerin kapanması, noktaların eklenmesi / taşınması / silinmesi.

• Geometri sorguları için kullanıcı dostu bir sorgulama arayüzü tasarlama (ve gerçekleştirme) ve hem nitelikler hem de geometri içeren sorgular için bir arayüz oluşturma; kullanıcı türünü SQL'e benzeyen bir şey yapmadan.

• Sorgularda, düzenlemelerde kullanılmak üzere haritadaki bir özelliği sürekli 'seçmekten' kaçınmak için özellikler / geometriler için pano gibi bir şey nasıl tasarlanır?

Benim düşüncem, GIS'in kullanılabilirlik açısından özellikle zorlu bir alan olduğu, çünkü:

• Konum evrenseldir ve genellikle herhangi bir bilgi için en doğal içeriktir, bu nedenle görüntülemek için her zaman çok fazla bilgi bulunur.

• Harita üzerinde görüntülenen bilgilerin bulunması, kullanıcı arayüzünün GIS dışı bölümlerinin önemini hafife almak için kolayca teşvik edilebilir.

• Endüstri geleneksel olarak GIS yazılımının kullanılabilirliğini ihmal etmiştir ve dijital haritalama yavaş öğrenme eğrisi ile teknik bir ticaret olarak görüldüğü ve bunun nasıl kullanılacağından çok daha zor kavramlar olduğu için bundan kaçınmıştır. Bu, uzman olmayanlar için bir GIS arayüzü tasarlamaya çalışan herkesin kafa karıştırmaya mahkum olan kendi ilkelerini icat etmesi gerektiği anlamına gelir (güzel bir örnek Google'ın 'Haritalarım' veya Bing Haritaları '' Yerlerim 'olur)

Web tabanlı GIS geliştirmesinin önündeki en büyük zorluklardan biri verilerin nasıl iletildiği ve verileri belirli bir şekilde sunmaktan ne kadar verimlilik elde edebileceğimdir. En büyük engel, bir insanın ince ayar yapmasını gerektiren bir şey için kod yazmanın çok zor olmasıdır. Çok nadiren büyük ölçeklerde kullanılan vektör verileri için genelleme teknikleri görüyorsunuz. Çoğu zaman katmanları açmak ve kapatmak için ölçek aralıklarını ayarlamanız gerekir.

Bu soru Google’da CBS’de karşılaştığım zorlukları araştırdı ve burada katkıda bulunmak istediğimi hissediyorum.

İlgili olduğumu düşündüğüm bir başka link ise bu yazıydı.

Orada söylenenleri ve kendi görüşlerimi özetleyerek, en büyük zorlukların (belirli bir düzende olmadığını) düşünüyorum:

• Kullanıcı Arabirimi: Ana bilgisayar kullanıcı arabirimi seçenekleriyle, geliştiricinin teklifi tüm cihazlara uyacak şekilde optimize etmesi zordur. Giyilebilir vs masaüstü tabanlı vs dokunun. Ekranlı bir giyilebilir kulaklık, yön kontrolü ve eldiven tanıma özellikli eldivenler sunan Gore tarafından sunulan DE fikri, süslü bir gelecek.
• Standardizasyon: Veri depolama ve geri alma standartlarıyla, bulutta kalan ve kaçak bilginin toplanmasına izin veren jeo-veritabanlarına sahip olabiliriz, böylece bir CBS taraması ve kullanımı sorunsuz hale getirilebilir.
• Veri Kullanımı: Karar vericilere daima zaman basılmaktadır. Eğer bir araç onlara yardım etmekse, pürüzsüz, kolay ve hızlı bir şekilde yapmalıdır. CBS bu cephede teslim gibi görünmüyor ve bunun hala bir terim olmadığının nedenlerinden biri.
• Veri: Veriler çeşitli, dağınık ve gürültülüdür. Gerçek zamanlı bir CBS konusunda net bir şekilde teşvik edilen kuruluşlar için bile, verilerin toplanması, giriş yapılmasını öngören büyük bir engeldir.
• Koordineli Çaba: CBS çok disiplinlidir. Her çocuk bunu bilir. Yönetim ilk slaytta bunun farkında olarak yapılır. Her ne kadar çok disiplinli olsa da, çok bölümlü projeler nadirdir.

Kodlamaya gelince, geçici çözümlere çok fazla zaman harcadığımı hissediyorum. Projeksiyonlar için süreçleri ve matematiği anlamam birkaç ay sürdü, bence bu konuda bence yayınlanmış bir materyal değildi. Konuyla ilgili EPSG ve OGC belgeleri birkaç okuduktan sonra kafamı dolaştırmamda bana yardımcı oldu, bazen birbirlerinin kopyaları gibi görünüyorlar. Bağımsız bir geliştirici olarak yaşadığım en büyük sorun, yardım edememem ama tıbbi, endüstriyel ve hatta basit bir web uygulaması geliştirme için özel çalışmaya ihtiyaç duyan insanları gezmek. GIS endüstrisi ile pazara girmenin bir yolunu bulmak neredeyse imkansız görünüyor.

GIS teknolojilerinde tam bir acemiyim, her şeyi olduğu gibi çözerek çözüyorum. Ve param sınırlı olduğundan, ESRI ürünlerini kullanmaktan kaçınmaya çalışıyorum ve tamamen açık kaynak kodlu araçlarla şeyler yapmaya çalışıyorum.

Öyle ki, benim için en zor şeylerin hepsi veri toplama ile ilgiliydi. Verileri yönetmek ve görüntülemekle ilgili birçok makale ve hayatınızı kolaylaştırmak için birçok araç bulunmaktadır. Ama veri toplama konusunda karanlıkta yürüyeceğim eşiğindeyim.

Profesyonellerin veri bulmak ve toplamak için ne yaptığı hakkında hiçbir fikrim yok. Bir şeyler bana veri almanın data.gov ve google’tan daha kolay bir yol olduğunu söylüyor.

Yazılım geliştiricilere dönüştürülmüş GIS analistleriyle çalışmak zorunda kalmak talihsiz olabilir.

Yetkili bir yazılım geliştiriciden GIS kavramlarını almalarını ve API'leri gözden geçirmelerini ve genellikle fazla yardım almadan işleri çözmelerini beklemek kolaydır. Aynı şey, bir GIS analistini alma ve onlardan yazılım geliştirmeyi almalarını beklemez.

En iyi sonuçlar utanç verici . Kötü geliştiricilerle çalışma konusunda deneyiminiz varsa , bunun en kötü programcının geliştirdiğinden daha kötü bir kod olduğunu hayal edin.

Bunun için çalışabileceğin bazı şirketler var.

CBS dünyası, CBS'in yalnızca mühendisler, mimarlar veya bilim topluluğu tarafından tedavi edildiği ilk yıllar olmadıkça, genel kullanıcıya doğru genişletiliyor. Ortak kullanıcı için GIS uygulaması yapıldığında, zorluk, CBS'nin daha çok bir teknoloji olarak değerlendirildiği teknolojilerin uygun şekilde karıştırılmasıdır (bu durumda, GIS teknolojisini biraz anlayan bir geliştirici yeterlidir). Bununla birlikte, uygulamanın uzman topluluk için yapılması durumunda, zorluk daha karmaşık olmakla birlikte, teknolojilerin birleştirilmesinin yanı sıra, gereklilikleri yerine getirmek için mevcut algoritmaları aramak için gerekli olması, aksi takdirde bu algoritmaları geliştirmek zorunda kalmamızın daha da kötü olması gerekir. Bu durumda, mühendis ve geliştirici karışımı çalışan işçidir.