e-BELEDİYENİN CBS TABANLI KURGULANMASININ GEREKLİLİĞİ

ÖZET

     Bu çalışmada Devlet Planlama Teşkilatının Bilgi Toplumu Eylem Planı 66-75 gereği ilgili kurum olan Belediyelerin gerekli entegrasyon sürecinde karşılaşılabilecek sorunlar ve bu sorunların çözüm yolları bu rapora konu edilmiştir.Çalışmada E-Belediye çalışmalarının CBS tabanlı bir veri tabanı üzerine kurgulanması gereği anlatılmış bu doğrultuda nedensellikler ortaya konulmuş coğrafya olmaksızın kurgulanacak çalışmaların neredeyse işlerinin tamamı mekana dayalı  olan Belediyelerde sorunlara çözüm olmayacağı bir belediyecinin gözü ile anlatılmaya çalışılmıştır.

     E--Belediyenin dayanması gereken ana unsurunun Mekan bilgisi  TAKBİS(Tapu ve Kadastro Bilgi Sistemi)   İnsan bilgisi ADNKS(Adrese dayalı Nüfus Kayıt Sistemi) olması gerektiği ,uygulamada  Vergilerinin düzenli bir kayıt sistemine kavuşturularak adaletli bir vergi toplama sistemi oluşturma çalışmaları(Emlak vb. Emlak veri tabanında yıllara sari bulunana beyan bilgilerinin tapu ,kadastro,adres ilişkilerinin düzeltilerek var olan doğru bir envanter ile  karşılaştırılması ve bu işin bir sistem haline getirilmesi)ilgili yaşanılan tecrübeler ve  Ulusal Adres Veri Tabanı ve Adrese Bağlı Nüfus Kayıt Sistemi veri tabanı kayıt deseninde veri alanı başlıklarının güzel modellendiği ancak uygulamadaki ihtiyaçlar ve işlemlerin nasıl yapıldığının çok da analiz etmeden kurgulandığı , coğrafyaya ihtiyaç duyulmamasına yönelik yapılan veri başlıklarının hiçbir şekilde ADNKS nin güncelliğinin muhafaza edilmesi ,TAKBİS ile entegrasyon noktasında çözüm oluşturmayacağına değinilmiştir.e-belediye çalışmalarında belediye bünyesinde olan tüm verilerin ihmal edilmemesi oluşturulacak sistemde daha önceki verileri sisteme entegre edemediğimiz takdirde uygulamada daha büyük sorunlarla karşılaşılacağı ve geçiş aşamasında vatandaşa rahatlık yerine sıkıntı vereceği unutulmaması gerektiğine değinilmiştir. ADNKS nin CBS tabanına çevrilmemesi halinde TEXT tabanlı yapıdan bir gün geri adım atılacağı bunun da kaynak israfına yol açacağı uyarısında bulunulmuştur. Belediyelerin geliştirdikleri Numarataj sistemleri ile Ulusal Adres Veri Tabanı (UAVT) nı hakkında mevcut sorunlarımız, birleştirme ihtiyacımız ve bu iki sistemin entegrasyonu önündeki sorunlar ve çözüm önerileri dile getirilmiştir.

GİRİŞ

 CBS TEMELLİ BİR ULUSAL VERİ TABANININ GEREKLİLİĞİ

      Ülkemizde Yerel Yönetimler kendilerine verilen yasal yetkiler gereğince  imar planlarının yapımı ve uygulanması,yolların yapım bakım ve onarımı,temiz içme suyu temini,her türlü atık suyun uzaklaştırılması ve arıtılması,itfaiye hizmetleri,emlak ,çevre,ilan ve reklam  vergilerinin toplanması sosyal ve kültürel hizmetlerin sağlanması gibi insan hayatını doğrudan ilgilendiren bir çok konuda hizmet yükümlülüğünde olan birimlerdir.

     Değişen dünya koşullarında özellikle iletişim teknolojilerinin ön plana çıktığı göz önüne alındığında Belediyelerin hizmetlerini daha hızlı,daha doğru ve daha adaletli bir şekilde sağlaması için hizmetlerini verir iken maksimum oranda fizibilite ve planlamaya dayanan,kaynak israfı ve popülist   politikalarla yatırımlar yapmaması ,gelir gider dengelerini gözetmesi,gelirlerini doğru ve adaletli bir şekilde tahsil edebilmesi,sadece devlet den gelen veya kanun gereği toplaması gereken vergiler ile değil öz kaynaklar ve projeler üreterek gelir elde etmesi , gelirlerini de hizmete döndürmesi gerekmektedir.Bu durum kent de yaşayan insanların yaşam düzeylerinin yükselmesini sağlayan en önemli etken durumundadır.

    Bu nedenledir ki Türkiye Cumhuriyeti Devleti 5216 sayılı Büyükşehir Belediyesi Kanunun 7/h maddesi ,5393 sayılı yasanın 14.maddesi gereğince  Belediyeleri  Kent Bilgi Sistemi ve Coğrafi Bilgi Sistemi Kurma ile görevlendirmiş,Devlet Planlama Teşkilatı Bilgi Toplumu Eylem Planı ile stratejik hedefler ortaya koyarak bir dönüşüm süreci başlatmıştır.Eylem Planının da E-Belediye hedef olarak konan bir uygulamadır bu yazılım ve sistemlerin birinci temel dayanağı Mekana dayalı işlemlerdir.İkinci temel dayanağı ise ADNKS olmalıdır.Mekana dayalı işlemler kadastro ve tapuyu esas almaktadır.

    Kadastro ve Tapu ayrılmaz bir bütündür.Bu ikilinin  ayrı ayrı değerlendirilmesi başka başka sorunlar oluşturacağından mekan temelli çalışmada kadastronun esas alınması gerekmektedir.Kadastro koordinatla ifade edilen bir unsurdur.Kadastronun sadece ada ve parsel numarası şeklinde ifade edilmesi ,TEXT tabanlı ADNKS de zaten mevcuttur.Ancak Ada ve Parsel bilgileri parselin geometrik yapısının değişmesi ile (mevzuat gereği değişmektedir) İmar uygulamasına giren parsellerin numaraları,maliklerin arsa payları ,maliklerin isimleri,parselin alanı vb ki uygulamada bu durum sadece uygulama hiç girmemiş parsellerde değil aynı zamanda müteahhit ve mimarların daha fazla bağımsız bölüm çıkarmak veya inşaat yapılacak arsa sahipleri ile yapılan karşılıklı menfaat olgusuna göre   uygulama görmüş  parsellerde bazen tevhit(birleşme) ve ifraz(ayırma) işlemlerine tabi tutulmaktadır bu durumda da ADNKS de ada ve parsel numarasının manüel  olarak değişikliğe uğratlarak buna bağlı bir ediğer unsurlar ile entegrasyon yapılması  uygulamada bu işlemleri yapan birimlerin ayrı ayrı olması nedeni ile mümkün değildir.

   Uygulamada bir parselin değişikliğe uğradığı bilgisi nihayetinde  kadastro müdürlüklerinin kontrolünde bir olgudur. Parsele veya bir inşaata numara verilmesi ise Belediyenin sorumluluğundadır.Numara veren kişi elinden geldiğince arazideki duruma ,güncel olarak varsa kadastro parsellerine bakarak numara verir.Bir parselde sonrasında yapılan bir değişiklik numara veren numarataj birimindekiler tarafından bilinmesi mümkün olmamaktadır.Kimi zaman aynı belediye içinde bu değişiklikten sadece inşaat ruhsatı veren birim haberdar olmakta onlarda genel uygulama sıkıntılarında olduğu gibi sadece kendi işine odaklanmakta böyle bir değişiklik olduğunu numara veren birime iletmemektedir. ADNKS de de diğer sistemlerde en büyük sorun kişi dirençleridir.Yeni sistemlere her zaman bir direnç olmaktadır. Türkiye Cumhuriyeti Devletinde tüm bürokrasi en önemli işin kendisinin işi olarak görmekte yaptığı işin başka birisini-kurumu ilgilendiren unsurlarına önem vermemektedir.Örneğin inşaat ruhsatı veren bir  imar birimi kendini binanın imara uygun yapılıp yapılmadığına odaklamakta adres veya kendisinden talep edilen başka bir hususa tabiri caiz ise lüzumsuz iş olarak bakmaktadır.Biz ilçe belediyelerine “her adrese bir ruhsat keseceksiniz” dediğimizde –doğrusu da budur-itiraz etmektedirler..Çünkü bir parsele 50 bina var ise eskiden bir ruhsat ile iş bitiyordu ,şimdi her binaya 50 ayrı ruhsat kesince bir de kullandıkları sistem yeni ve  doğal olarak lokale göre daha yavaş olunca   itiraz sesleri artmaktadır.

    Ayrıca bir yere ,bir bölgeye adres numaraları verildiğinde, ADNKS de adresi ifade  eden her satırda  ada ve parsel numarasını da ilgili numaranın karşısına yazdığınız bir durum olsun.Daha sonra bu bölgede (örneğin 1000 tane parsel olsun)bir imar uygulaması olduğunda parseller hem ada ve parsel  numarası olarak hem de geometrik olarak değişikliğe uğramaktadır.Böyle bir değişikliği takip etmek ise ancak numaratajın geometrik olarak ifade edilen  tabaka mantığına göre altta bulunan kadastro ve tapu bilgisi ile “grafik key “ vasıtası ile bağlantı kurması ile mümkün olabilir(Kimse oturup adreslerdeki ada ve parsel numarasını manüel olarak güncellemez veya bu iki ayrı unsuru ilişkilendirecek coğrafya dışında da  bir KEY yoktur)Yani parselin malikleri ,ada ve parsel numarası alanı vb her türlü unsuru ne şeklide değişirse değişsin.Numarataj grafik obje olarak tutulduğu için Numarataj objesinin isabet ettiği alandaki tüm değişiklikler topolojik key den dolayı Numarataj objesini ve dolayısı ile de Numarataj database ini değiştirmektedir.Bugün Spatial Data Objects (SDO) yapısı, bize bu imkanı doğrudan verebilmektedir. E-Belediye nin veri tabanı Spatial  olmalıdır.

   ADNKS de değişen unsurlar kişilerin %100 inisiyatifine bırakılmıştır.Böyle önemli bir sistemin Belediyelerin işine yaraması için TAKBİS ile entegreli olması elzemdir.TAKBİS tarafında ise data işin doğası gereği obje olarak tutulmaktadır.TAKBİS te yapılan değişiklik ADNKS yi değiştirmesi halinde E-Belediye unsurları tam anlamı ile işlevsel olabilecektir.

   Mülkiyet ile Adresin ilişkilendirilmesin de Mernis in Tapu kütüklerinde temsil edilmesi ile çözme düşüncesi tapu kütüklerindeki bilgilerden TC kimlik üretebilme başarısına bağlıdır Haddi zatında geçmişten beri yapılması gerekli olan ama daha yeni yeni başlayan bir süreçtir. Meram Belediyesi ile ortak yaptığımız Emlak Vergisi kaçaklarını takip etme yönteminde mevcut tapu kütüklerinde sağlıklı  Mernis elde edilebilecek data   konusunda sorunların olduğu görülmüştür.Bunu yapmak ile geçmişe bağlı T.C si olmayan kayıtların tamamının  ilişkinin sağlandığını ve T.C lerin elde edilebildiğini  buradan Adres ile ilişki sağlanarak Entegrasyonun Ana unsurunun tamamlandığını düşünsek bile ;
uygulama da bize gerekli olan kişinin tebligat adresi olduğu kadar parselin konumu (yani taşınmazın adresi)hangi rayiç bedelden beyan vereceği geniş caddeden mi  arka sokakdan mı cephe aldığı vb  konumu, içeriğinde bir bina olup olmadığı (Bir çok kat irtifasına geçmiş bina kat mülkiyeti olmadığından,tapudaki taşınmazın üzerinde bina resmi olarak gözükmediğinden arsa vergisi vermektedir-bu vergilendirme açısından oldukça ciddi bir kayıptır***)gibi bilgiler geometrik olarak tasarlanması gereken bir olgunun mecburiyetini ortaya koymaktadır.Geometrik yapı dışındaki kurulabilecek TEXT tabanlı sistemlerde(şu andaki ADNKS de olduğu gibi) bir çok çalışmanın temelini oluşturan mülkiyet olgusunu güncel tutmak ,ilinti kurmak mülkiyetin doğal yapısı gereğince mümkün değildir.

Şu anda ADNKS de veritabanında özellikle geometriye ihtiyaç duyulmasın diye koyulan alanlar  uygulamalada ki işlemlerin yeterince  bilinmeden yapılan bir unsurdur, tüm hususlarda ileride belediyelerin ihtiyaçları analiz edilince geometrik yapıya ihtiyaç duyulacağı gün gibi ortaya çıkacaktır. Çünkü Belediyelerin işlerinin neredeyse tamamı mekana dayalı işlemlerdir. Dolayısı ile hem insanı hem de taşınmazı(mekanı) sicil  esasını taşıyan   CBS tabanlı bir  veri tabanı kurgulanmalıdır.

ADNKS de bina kayıt deseni içinde gördüğüm,TUİK e veri aktarımını Web ara yüzleri ile değil   CBS veritabanından  doğrudan UAVT ye gönderdiğimiz için aslında bazı alanlarda istenen verileri bir kereye topolojik ilişkiler nedeni ile çok rahat bir şekilde doldurabilecek iken ,TUİK in Bina Kayıt Deseninde CBS  den bağımsız bir yapı kurulduğunu gördüğümüzden Ada ve Parsel ,BASKASOKAK_ADI, BASKASOKAK_NO, BASKASOKAK_TANITIMNO şeklinde verilen alanları bilerek doldurulmamıştır,ADNKS deki şu andaki yapı CBS olmadan da bir entegrasyonun sağlanabileceği tezini ortaya koymaktadır.

TEMEL SORUNLAR VE ÇÖZÜM ÖNERİLERİ

CBS temeli, kadastro , harita,konum ,koordinat gibi unsurlar  vurgulandığında  başka meslek disiplininde bulunan kişiler bundan Haritacılık mesleğini  ön plana çıkardığımız gibi bir zanna kapılmaktadır.Ancak bilim taassupların değil gerçeklerin üzerine kurulu ise “aklın yolu birdir” deyimine burada söylenmesi gerekmektedir,harita sadece Harita Mühendislerine ait bir olgu değildir.Bu tabana ihtiyaç duyulması gayet doğal ve gereksinimlere bağlıdır.Bu nedenle başka meslek gurubunda bulunan insanların harita ortamını gördüklerinde anlamadıkları veya yorumlayamadıkları hususların bir kısmı lise eğitimi ile elde edilen bir bilgiye dayanmaktadır.Harita ortamından ürkmenin veya CBS yi Harita Mühendislerinin mesleklerini ön plana çıkarmak için vurguladıkları bir husus olarak değerlendirmek çok yanlıştır.

Bu hususta bir özeleştiri yapmak gerekirse mevcutta CBS ile analize dayalı işlemlere temel teşkil eden obje verisinin ölçüme dayalı ve  Büyük Ölçekli Harita Yönetmeliği uyarınca istenen hassasiyette olması temelde biz harita mühendislerinin hassasiyet kavramının CBS ye geçiş sürecindeki ülkemizde sistem ile elde edilebilecek getirilerin önündeki en büyük engel olarak görüyorum.Bu konuda işe göre grafik obje koordinat hassasiyeti fikrinin yarar sağlayacağını düşünmekteyim.Çünkü CBS de grafik obje(harita) her ne kadar asli unsur olsa da ülke politikalarını belirleme,makro ölçekte planlama yapma ,tarım ,sanayi  vb her tür sektörde CBS ile elde edilecek maksimum faydanın kimi unsurlarda koordinat hassasiyetini gerektirmediği kanısındayım.Bu doğrultuda ülke genelinde CBS nin temelinde olan halihazır ,kadastro gibi unsurlarda maliyet &yarar unsurları düşünülerek bazı unsurlardaki olmaz ise olmaz  şeklindeki koordinat hassasiyeti varsayımlarımızın hem ülkede kurgulanması gereken Ulusal CBS veri tabanı fikrine hem de CBS de aktif yer alan Meslek gurubumuza zarar vermektedir.

Bunun dışında teknik konulara devam edersek;

ADNKS de Cadde Sokakların Tanıtım Numaralarının her mahalle içinde ayrı ayrı numaralandırılması, numaralandırılır iken şehir merkezine en yakın yerden başlayarak( buradan emlak beyanı rayicini hesaplamak için kurgulanmış diye düşünüyorum, ancak bir parselin şehir merkezine uzaklığı veya yakınlığı rayiç bedeli etkileyen tek unsur olamaz ,parselin hangi yola cephe aldığı ,(bazen  şehrin başka yönlerinde  de şehir merkezinden daha fazla rayiç bedel olabilir),coğrafya olmadan sokağa yakınlık kriteri gibi veri girilmesi sadece arazide bu sıralamaya göre verilen bir listeye göre gezilim yapılmasını kolaylaştıran bir unsur olarak düşünülmüştür.”Bize göre yanlıştır”. Mahalle tanıtım numaralandırmasında ilçeyi esas alan büyükşehir olgusunu düşünmeden yapılan bir mahalle tanıtım numaralandırması ve şehir merkezine yakınlığına göre numara verilmesi de bizce  uygun değildir

Esas sorun yeni bir mahalle oluştuğunda ,  bir mahalle iptal olduğunda ,  bir mahallenin sınırı değiştiğinde Yeni bir sokak açıldığında ne olacağıdır. Numarataj yönetmeliği bu kısımda konum bilgisini nasıl olurda TEXT tabanında ifade ederim diye çok düşünülmüş. Ama komik olmuş doğrusu. Bana göre Adres ve Numaralama dair yönetmelik “Noktalı” bir yönetmeliktir.

Örneğin   yeni bir sokak oluştu bu sokak daha önce tanıtım numarasını 102 vermiş olduğunuz sokağa en yakın olduğunu düşünüyorsunuz! Ve oluşan yeni sokağın tanıtım numarasına 102 nin sonuna bir adet “.”  Nokta koyuyorsunuz. Yine yönetmelikte bu husus yeni oluşan sokağın 10 dan fazla olması 10 dan az olmasına göre bir şekil değişikliği getirmektedir.Bir veri tabanı modelinde böyle bir kural(kuralsızlık) olmamalıdır. Ayrıca bir yerleşim yerinde aynı sokak adının bir kere daha tekrar etmemesi şeklinde getirilen kural masa başında alınan bir karar olup esnafın faturası,esnafın sicili vb adres değişince maliyetle yeniden resmi işlem yapılması gereken ülkemizde oldukça sıkıntılara yol açmıştır:Bir sistem açısından (kullanım açısından değil)sokağın adı TEXT bir bilgidir.Onun adının ne olduğunun  hiçbir önemi yoktur.İsterse 10 kere tekrar etsin.Önemli olan tanıtım no(sokakkodu)  farklı ise sorun yok.Bundan sonraki süreçte de aynı isimler verilmesini yönetmelikle engellenmesi daha uygun olacaktı.Konya KBS de bir mahalle içinde aynı ismin olmamasına dikkat edildi(kulanım açısından),yönetmeliğe uyarak hepsini değiştirse idik çok tepki alırdık.

KONYA KBS de  mahalledeki tüm sokaklara kod numarası verildi arkasından da imar planına bakılarak(dikkat edin konumsal bilgi devreye girdi) o mahallede ki açılabilecek sokak sayısı  görüldü örneğin bu sokak sayısı 50 olsun sizde 1 den başlayıp fiili açılmış sokaklara 30 a kadar numara vermiş olun.Bu durumda aralığı biraz geniş alarak bu mahalleye 1-100 arası revize sokak numarası ayırıp ikinci bir mahalledeki sokağı 101 den başlattık.Yine sokak ve cadde numaralandırmasında bir sokak birden fazla mahalleden geçiyorsa(veya mahalle sınırında ise) farklı farklı tanıtım numarası almasına da bizce gerek yoktur.Bir sokağın hangi mahallede olursa olsun bir tane Tanıtım numarası alması uygun olanıdır. Grafikte sokağın objesel(yol orta çizgileri ile) olarak tuttuğumuz için ayrılmasını gerektirecek unsurlar konumsal ilişkiler ile bulunacağından bu yöntem de bence doğru değildir.

Bir mahallenin iptalinde veya ilgasında sınırının değişmesinde ise Numarataj yönetmeliğinin çaresizliğine değinir isek.Mahallenin sınırının değişmesi geometrik bir olgudur.SDO yapısında olan bir mahalle sınırını istediğiniz gibi değiştirin obje tabanı içine giren ve grafiksel anlamda KEY oluşturan her unsurun mahalle ilişkisi hemen değişecektir.Örneğin mevcut ADNKS nin TEXT tabanlı olmasının sıkıntısını bizi nasıl zorlayacak bakın…  .292 mahallemiz var bunların bir düzene sokulması gerekiyor  ilçe belediyeleri yasal yetkileri ile mahalle sınırlarını değiştirdiler ve mahalle sayısı 210 düşürüldü.ilçe belediyesi sınırı değiştirince bizim Adres Bileşenlerinden Mahalle unsuru değişti, Numarataj ile ilgili yaptığımız bir çok husus etkilemekte kendi sistemimizde tek işlemle bu mümkün  ama  TEXT tabanlı bir ADNKS de bunu bina bina yapmak zorunda kalınacaktır.  5272 sayılı yasa gereğince İlk yerel seçimlerden önce bu işi ADNKS de yapıp seçimlerin ilgili yeni mahallere göre yapılmasını gerekmektedir.Yaklaşık 20000 bina başka mahallelere taşınacak olduğundan zaman ve emek verilecektir. ADNKS Tabanın grafik tabanlı olarak yapılması için bir gerekçede budur.

Mahalle sınır değişikleri sadece ilçe belediyelerinin inisiyatifine bırakılmamalı Büyükşehir Belediye Meclisinin onayı da aranmalıdır.Tıpkı planlama yetkisinde olduğu gibi.Şu anda Belediye kanununa göre  Büyükşehir Belediyesi sınırları içindeki bir ilçe belediyesi mahalle sınırını kendi meclis kararına göre geçirmekte oradan kaymakamlığın uygun görüşü  ve valiliğin kararı ile sınır değişmektedir.Numarataj yetkisi 5216 sayılı yasa ile Büyükşehir e bırakılmıştır ki bize göre doğrusu ve özelikle güncelleme ve merkezileşme  açısından olması gerekende  budur.Dolayısı ile mahalle sınırı değiştirme yetkisinin de sadece ilçe belediyesine bırakılması Numarataj sorumlusu olan tarafı zorlamaktadır ,sorunlar oluşturmaktadır.

Mahalle sınırları ile Tapudaki mahalle sınırlarının aynı olması sorunu var bu durum özellikle TEXT tabanlı olarak kurgulanmış mahalle ilişkisi de string bir adres key ine bağlanmış ,bir  taşınmazın elde doğru olduğuna inandığınız ada ve parsel şeklinde var olan bir tapu ve kadastro verisi ile kıyasladığınızda fiyaskolar oluşturmaktadır.Vergilendirme beyana göre yapılmaktadır.Beyanda ise vatandaşın ödeyeceği vergiye esas teşkil eden rayiç unsurlardan birisi  arsa veya binanın tapudaki mahallesi değil belediyenin belirlediği idari mahalle sınırlarına göredir.Tapudaki Ada ve Parsel bilgisi aynı numaranın birden fazla tekrar etmesi veya ada numarası olmadan sadece parsel numarası faktörü olan yerlerde SQL tablolarının kıyaslamasında mahalle faktörünü devreye sokulması elzem duruma gelmektedir.

 “Örneğin Belediyenin elinde yıllara sari bağlı kalmak zorunda olduğu bir emlak vergisi verisi var bu verileri mevcut a kıyaslayıp nerelerden nasıl vergi alınıyor veya alınmıyor u görmek istiyorsunuz Tapu verisine bakıyorsunuz aynı ada ve parsel numarası birden fazla tekrar etmiş bundan kurtulmanın yolu ne mahalle kriterini koyalım tekrar etmesin diye düşünüyorsunuz SQL i üçlüyor JOİN lemeleri çoğaltıyorsunuz.Durum ancak öyle düzeliyor.Ama Takbis te bir mahallede tekrar eden ada ve parsel numaraları da var onu ne yapacaksınız .Onu ancak raporlayıp tapu bilgilerinin düzeltilmesini beklemekten başka bir çareniz yok…”

Burada esas sorun , Emlak verisinde Mahalle bilgisi alınan rayiç gereği belediye tarafından belirlenen idari mahalle sınırlarına göre her ne kadar tapu bilgisi girilse de (hala böyle ama ADNKS CBS  ve TAKBİS tabanlı olursa ve E-Belediye Emlak vergisi kısmına Web servisleri eklenebilirse ancak düzenlenebilecek) beyan aslında arsanın veya binanın adresine göre tahakkuk ettiriliyor  ama biz elimizdeki doğru bir veri ile kıyaslama mecburiyeti taşıdığımızdan ancak ada ve parsel kriterini ortaya koyabiliyoruz.(Bunun detayları var ama Meram Belediyesi ile yaptığımız çalışmada bu durumu çözdük) Tapudaki Mahalle idari sınırı ifade eden bir sınır ile aynı olsa idi  sorun kalmayacaktı emlak beyanındaki mahalle ada parsel =Tapudaki güncel mahalle ada ve parsel bilgisine tamamdı.Ama şimdi ne yapıyoruz  beyandaki mahalleyi hiç dikkate almıyoruz.Çünkü bu yanlış olabiliyor ada parseli esas alıp bunu coğrafyada temsil edip coğrafyada var olan idari mahalle sınırını beyan veri tabanına atıyoruz.(bununla ilgili yaptığımız bir sürü cambazlıklar var açıkcası )Bu yüzden mahalle sınırları belediyeler tarafından ikide bir değiştirilmemeli ama değiştirilme zarureti ortaya çıkınca da Tapuda aynı değişiklik yapılmalı ama uygulamada bazen pafta üzerinde normal de işi olduğu için değiştirmesi gereken bir çok hususu(ada ve parsel numarası) değiştirmeye fırsat bulamayan teknikerin tapuda işi başından aşkın bir tapu memurunun bunları değiştirmesi uygulamada oldukça zor görülmektedir

e-Belediye uygulamalarında belediyelerin elinde yıllara sari hukuken olması gerekli olan mevcut verilerin olduğu gerçeği göz ardı edilmemelidir. ADNKS öncesinde numarataj yönetmeliği uygulanılması istenmiş ve bu durumda şehirlerde numarataj nerede ise %60-70 oranında değişime tabi olmuştur.Eski Numaralar sistemde tutulmadığı için bir ilişkilendirme rutinde kalmamıştır.e-Belediye çalışmalarında bilinmelidir ki Belediye yasal olarak elinde var olan her türlü vergi kaydı esas almak zorundadır.Bu kayıtlar hiç yokmuş gibi bir sistemin kurgulanmaması gerekir.Beyana bağlı vergi alınma yöntemi(bana göre yanlıştır ama bu konuya burada girmeyelim)ile bir kişinin malik bulunduğu mülklerin kişinin verdiği bilgilere göre doldurulduğu bir işlemdir.Kişi bu bilgileri verir iken çok eski tarihlerden kalma bir tapu ile Emlak beyanı verebilmektedir.Uygulamada belediye ben senin beyanını alamam lüksüne ve yasal yetkisine sahip değildir.Bu durum başka sakıncalar da oluşturmaktadır ancak en basitinden eski ada parsel numarası  ile beyan vermekte , vasfını tarla olarak vermekte,hatta çoğu arsanın yeri ana bir caddeye bakmakta iken ara bir sokağa bakıyor gibi göstermektedir.Bu durum bu kaydın doğru veri ile karşılaştırması sırasında(Örneğin bu sıkıntılar ben hem Aksaray da hem de Meram belediyesi ile yaptığımız ortak çalışmada gördüm)bu parselin aslında bir imar uygulaması gördüğü parselin vasfının arsaya çevrildiği ada parsel numarasının değiştiği hata üzerinde lüks bir villa bile olabildiği verilen beyanın konumsal bilgisinin ana caddeye cephe olup rayiç bedeli verdiği beyanın iki katı olduğu gibi sonuçlarla karşılaşılmaktadır.Öncelikle beyan verilen kaydın ada ve parsel numarasına bakılmakta bu ada ve parselleri elimizde güncelliğinden emin olduğumuz ada ve parseller ile karşılaştırmakta elimizdeki ada ve parseller ile eşleşmemesi durumunda bu parselin his toriği TAKBİS te olmadığı için(TAKBİS te hem objesel anlamda hem de text tabanında bir parselin fenni anlamda parselin ilk kadastrolamasından son duruma kadar başına gelenler tutulmalıdır)elimizdeki imar uygulama kayıtları kişilerin tecrübeleri ile aslında tapuda beyan verilen ada parselin gerçek numarası bulunmakta bu sayede öncelikli eşleme yapılmakta verilen beyan coğrafyaya getirilmektedir.Daha sonra aslında bu parselin beyan adresi topolojik keyden alınmakta böylelikle parselin gerçek adresi ortaya çıkarılmaktadır.Daha sonra bu parsel üzerinde bina var ise  ki bazen eski tapu üzerinde eskiden var olan kerpiç bir eve emlak beyanı alındığını da biliyorum.Çoğunlukla bir bina (TOPOLOJİK KEY ilişkisinden )çıkmakta ve bu binanın da aslında 5 katlı bir apartman olduğu ve apartmanın ya kaçak bir bina yada kat mülkiyetine geçmeyen bir yapı olduğu görülmektedir.***.Dikkat ederseniz parselin malikinin yazışma adresinden hiç bahsetmedim.Bu adres uygulamada vatandaş para versin de nasıl verirse versin mantığından çoğunlukla doldurulmamış veya elde bulunan bir adres verisine uygun değildir.Veya bu adres adres standart ı taşımamaktadır.Bu nedenle beyan üzerinde vatandaş adreslerini hiç dikkate almıyoruz.Bunun yerine eğer kazara varsa kişinin T.C kimlik nosu en iyisi ama yoksa isimden baba adından doğum yılından  ADNKS den T.C üretip bu T.C ile tebligat adresi çıkartmaktayız.(bu konuda detaylarda oldukça fazla sıkıntı var burada bir başlasak kitap olur).Yukarıda da belirttiğim üzere dikkat edilir ise objeye nerelerde ihtiyaç duydum ise onun için ADNKS nin de Coğrafya üzerinde temsil edilmesi önemlidir. Konya KBS de ilçe belediyelerimize tavsiyemiz;

1- Vergi Beyanı Verenlerin kayıtlarının Düzeltilmesi Beyan Vermeyenlere veya yanlış Beyan verenlere hukuki tebliğin sağlanması.

2- Emlak Beyanında hiç bulunulmamış taşınmazların tespiti ve maliklerine beyana davet mektubu gönderilmesinin sağlanması.

3- Veri Tabanının düzenlenmesi ve düzeltilmesinin hemen akabinde Emlak Beyan vb. İşlemlerin bundan sonraki süreçte KBS Veri tabanı(içinde ADNKS TAKBİS vb hususların yer aldığı) ile entegrasyonlu  olarak çalışması.

Olmuştur.

2 İlçe belediyemizde yukarıda sayılan yöntemlere göre çalışma yürütmektedir.Bir çok Yazılım firması Anahtar teslim fikri ile 3. Adımı taahhüt olarak belediyelere vermektedir.Ancak 1. Ve 2. Adımların gerçekte muhatabı belediyenin kendi personelidir.Kendi işleyişidir.Bu nedenle bu işlemlerin tamamı tecrübeli  bir belediye kadrosu ile yapılmalı (bu kısımların belediye dışından gelecek bir firma tarafından yapılması ilgililerin ilgili belediyenin işleyişi ile ilgili bilgisi olamayacağından bence mümkün değildir.Sorunlar matematik ile çözümlenecek, iki SQL tablosunun karşılaştırılması mantığına göre çözümlenecek  sorunlar olmadığından ancak insan tecrübesi ve bilgisi ile bu işlemin yapılacağını düşünmekteyim)

Ve 2. Adımlar yapılmadan 3.adıma geçmek mümkün değildir.Bu nedenle

e-Belediye çalışmalarına başlamadan önce İçişleri Bakanlığı bir Genelge yayınlamalı bu Genelge Belediyelerin elinde bulunan eski verilerden kişi temelli olanlarda T.C kimliklerinin ,mülkiyet temelli olanlarda son ada ve parsel numarasının ,beyan verilen yere ait adresin(ADNKS den alınarak) düzettirilmesi için Belediyelere görev vermeli  bu konularda ayrıca işi sadece bu iş olan personeller(uygulamada bu işler ya sağda solda pek de işe yaramadığı düşünülen hadi sizde şunu yapın denilen kişilere ya da zaten rutin işleri oldukça fazla olan personellere verilmektedir.Bu işi yapabilecek kişiler belediyenin işlerine hakim ,bu işin önemini anlamış ve bu işi gönül işi olarak gören insanlar tarafından yapılmalı, idareciler tarafından da bu kişiler onur ize edilmelidir)  istihdam edilmesi,bu konuda tabiri caiz ise seferberlik oluşturmalıdır.e-belediye anlamında istediğiniz sistemi oluşturun ,en güzel yazılımları insanların önüne koyun işleyiş sırasıda eski veriler bu sisteme entegre olabileceği bir yapı yok ise sistemin yaygınlaşması ,benimsenmesi psikolojik faktörler nedeni ise zafiyete uğrayacaktır. Bu durum İnşaat ruhsatı ve iskan ruhsatlarının TUİK web ara yüzünden yaptırılması sırasında görülmüştür. Kısmen azalsa da halen sorunlar devam etmektedir.

Söz İnşaat Ruhsat ve İskanların ADNKS ile oluşturulmasına gelmiş iken bu konuda yapılan işleme(tek bir web ara yüzü ile  ve ADNKS ile ilişki kurarak) sonuna kadar katıldığımı belirtmeden geçemeyeceğim. Tek problem belediye elinde eskiden beri var olan verilerin de bu sisteme son aldığı ada parsel numaralarını da işletmeyi hedef alan bir çalışma başlatılmasıdır. Uygulamada eski datalardan kopulamadığından hem kendi lokallerindeki yazılıma hem de bu konudaki Web Arayüzü vasıtası ile UAVT ye giriş yapılmaktadır.Bu uygulamada sorunlar oluşturmaktadır.Burada en büyük sorun analiz yapılamadan yapılmış bir kurgudan kaynaklanmaktadır.Ruhsat basit bir klişe değildir.Bu klişeye bağlı bir çok faktör de bu işte takip ve kontrol edilmektedir. Başlangıçtaki kurguda bağımsız bölümlerin oluşumunun nerede olduğu nerede iskan kesildiği ve hangi unsurlara göre işlem yapıldığı gibi bir çok konu uygulayıcılara sorularak kurgulanmamıştır. Yasalarda tarif edilen işlemler uygulamada belediyelerin yapa geldikleri usuller ile yorumlanarak doğru bir model çıkartılması gerekir iken(e-Belediye Çalışmalarında da yapılması gereken budur)böyle bir hususa tenezzül etmeyen bir anlayış ile belediyelere göre bu işten hiç anlamayan hatta hayatında hiç ruhsat kesmemiş insanların kurguladıkları tepeden inme  bir sistem olarak eleştirilmektedir. imar kanun ve yönetmeliklerinde yanan yıkılan binaların da aslında bir nevi ruhsat işlemine tabi tutulması gerekir iken uygulamada hiçbir belediye böyle bir işlem yapmamaktadır. Yapılması da reel değildir.Bunu uygulamada görmeden sırf “kanunda bu nasıl olsa var siz de yapmak zorundasınız “gibi bir mantıkla bunun kurgulanması da bizce yanlıştır.Bizim tabirimiz ile Masa başı kanunları ile bu işe bakılmıştır.Türkiye Cumhuriyetinde Kanunlardaki bir takım hususların uygulamada sorunlar oluşturduğu veya uygulanmasında sorun oluşturduğu zaman değiştirilmesi ve kanunda hedeflenen hususların analiz edilerek yeniden değiştirilebileceği bir gerçektir.Ancak her nedense “kanunda yazsın da uygulamada yapılmak zorundadır.Bu gerçekten yapılabilir mi yapılamaz mı pratiğinin olmaması bence ciddi bir anlayış sorunu varlığını ortaya koymaktadır.

Belediye Vergi  dataları güncel son bilgiler ile update ettikten sonra  bütün sokak envanterlerinin Konya KBS ile objesel karşılıkları ile güncellenmesi son işlemlerden birisidir.Konya KBS de açılmış veya açılmamış bütün yolların yol orta çizgilerini çizip onlara olabilecek tanıtım numaraları verilmiştir.Şu anda Mmeram belediyesinde ve diğer İlçe belediyelerinde açılamamış sokakların olduğu parsellerde” diğer” diye bir gurup var bilgi konumsal olmadığından hiç yolu açılmamış ama aktif bir caddeye cepheli ada ve parsellerin caddeye bakan parselleri güzel bir rayiçle ödüllendiriliyor.!!! .Ada nın caddeye bakmayan henüz yolu da açılmamış cephesindeki oluşacak yola bakan parsel de mükâfatlandırılıyor. Bu parsel ile daha arka tarafta imar durumu ile de pek cazip olamayan parsel aynı “diğer” gurubunda rayiç bedel ile beyan ödüyor. Konumsal bilgi burada da önem arz ediyor.KONYA KBS de  her ne kadar ismi olmasa da kod numaraları olan  bütün açılmış ve açılmamış yolları veri tabanında dolayısı ile harita üzerinde temsil edilmiştir.Akabinde de konumsal bilgisine göre rayiç koyup ona göre vergi alınması ile daha adaletli bir vergi alınması sağlanmış olacaktır.

Numarataj yönetmeliğinde bir adresin tarif edilmesi ilçe mahalle sokak kapı numarası ilişkisi içinde yolu esas olan bir sistemle yapıla gelmektedir.”Konumsal tabanlı işlerde bir bina içinde 10 tane daire var ise 5 tane dükkan var ise veri tabanına bu şekilde girilmektedir.ADNKS de bunu ifade etmek oldukça sıkıntılıdır”.Özellikle köşe başındaki binalarda bir binanın 2 dükkanı bir sokağa 3 dükkanı da caddeye bakıyor ise bu bağımsız bölümleri ayrı ayır İdendifikasyon olarak  ilişkilendirmeniz istenmektedir.Dahası bir binanın aynı bağımsız bölümlere çıkan birden fazla kapısı var ise her kapıya numara verilmesi istenmekte(Numarataj yönetmeliği) ancak veri tabanında bu girişlerden birisi tahsis olarak belirtin gibi bence saçma sapan bir talepte bulunulmaktadır.” Bir kapıya numaranın verilmesi yönetmelikte yazılmıştır veri tabanı kurgusu için sokak envanteri üzerinde de  kapının birisinin bağımsız bölümleri var diğerine tahsis dir diyerek veri modeli oluşturulması çok yanlıştır . “Bizce yapılması gereken  bir binanın aynı bağımsız bölümlere giden ve aynı sokadan giriş alan  diğer girişlerine numara verilmez” dir. (Bu hususta Konya da özellikle iş hanların  da oldukça sıkıldık ve bunaldık binanın 10 tane girişi var.Hepsinden de bir şekilde  aynı bağımsız bölümlere gidiliyor  veri tabanında istenen gösterim şekli birisine bağımsız bölümleri bağla diğerlerine numara ver ama tahsis yap o zaman ilk önce  Numarataj yönetmeliği değil de Adres Veri Tabanı Kuralları diye bir yönetmelik çıkarılması akabinde bir  Numarataj yönetmeliği tasarlanması uygun olacaktı. Numarataj yönetmeliği ilişkisel bir veri tabanına uymayan bir çok hususu içinde barındırmaktadır.Biz kapıyı değil binayı esas alan bir yönetmelik talep ediyoruz. Çünkü vatandaş bir gün kapısını bir tarafa çeviriyor öbür gün bir tarafa. Bunun güncelliğini nasıl sağlamayı düşünüyorsunuz?

Numarataj mülkiyet temelli ve coğrafya üzerinde yapılmalıdır. Çünkü arazide ki durum ile bir parselin varlığı yokluğu parselin büyüklüğü sınırı imar planında kaç kata müsaadeli olduğu gibi hususlar aynı numaranın bir daha tekrar etmemesi gereken Numarataj mantığında bazen sorunlara neden olmaktadır. Özellikle arazide bakıyorsunuz burada parsel yoktur dediğiniz yerde aslında parsel çıkmaktadır.2 kat imara müsaadeli olan bir yerde 10 bina yapılabilmekte halbuki siz imar durumunu çevresindeki öyle zannettiğiniz bir duruma bakarak 5 kat olarak gördüğünüz bir yere 3 numara tahsis edebilmektesiniz. Bunu bir şekilde aşabiliyorsunuz ama 10 parsel olarak gördüğünüz ve buna göre tahsis yaptığınız bir yere 3 tane bina yapılır ise siz sokak da yeniden Numarataj yapacaksınız ki bu durumda vatandaş oldukça sıkıntı çıkarıyor ya da kalan 7 tane ortalıkta hiç olmayan tahsisler gezmektedir. Arazide gezerken 3-5-7-17 olabilmektedir.9-11-13-15 tahsis olmakta ama reel de böyle bir tahsise ait ortalıkta arsa da olmamaktadır. Tabi mülkiyetin sayısal ortamda olmadığı yerler için bence ADNKS nin de CBS ye dayanmasının bir anlamı yoktur. Böyle olan yerlerde bence e-belediye de yürümeyecek amaç hasıl olmayacaktır. Bu nedenle özellikle şehir merkezlerinde TAKBİS in kadastro ayaklarının tamamı ile bitirilmesi ve Tapu ve Kadastronun tıpkı ADNKS de olduğu gibi WEB servisleri vasıtası ile Belediyelere açılması önem arz etmektedir.

Bir arsa üzerinde arsa vergisinin tebligatını yapma noktasında  takip etmek malik in T.C sini de elde edebiliyorsanız sorun olmayacak şekilde çözülmektedir. Fakat Bina beyanında üzerinde 10 daire olan bir bina olsun bu ada parselden yola çıkarak 10 ayrı malikin bu sefer daha önce beyan verip vermediği verdi ise nereye beyan verdiğinin araştırılmasını gerektirmektedir.Tapu da 10 daire gözükmekte ama uygulamada 14 daire olabilmektedir.Bu durumda bu 4 daire ye nasıl beyan alacağız bilinmemekte  bu durumda bir Encümen Kararı alarak bu durumu tutanağa bağlayıp kaçak olan yerlerin adreslerine(coğrafya ilişkisinden elde ederek) (isme değil) beyana davet mektubu göndermek en iyi yoldur.Esas sorun ise beyan verilir iken arsa beyanı veren ama iskan almadığı için tapuda ya arsa olarak gözüken ya da kat irtifaklı olarak kalıp üzerinde bina gözükmeyen yerlerdir.Burada kesinlikle yasal bir değişikliğe ihtiyaç vardır.

Önerim biraz radikal ama  bana göre kat irtifası tamamen kaldırılmalıdır. Bir bina vardır ya da yoktur.Bu durumda tapuda gösterilir Tapusunda Bina var olan binanın vergisi alınır yok olanın ise arsa beyanı alınır ve diğer her tür işlemi de ona göre yapılır tapuda bina var ise elektrik su bağlanır yok ise bağlanmaz Binanın var olması kat mülkiyeti ile olur yokluğu ise arsa tapusudur.Arası olmaz olur ise şu anda olduğu gibi istismarlar olur.Kat irtifasını kaldırır isek bundan tek zararlı mali durumu zayıf olan yap satıcılar olacaktır , çünkü onlar vatandaştan para alıp aldıkları parayı inşaata vermekte; ortada buna devlet garantisini de eklersek kat irtifası onların işine gelmektedir.Vatandaş için ise bir anlaşmanın güvencesidir kat irtifası.

Ama uygulama bütün istismarların vergi kayıplarının en temel sıkıntısı kat irtifası kurulma sorunudur.Bunu tamamen  ortadan kaldırmak yerine irtifa sözleşmelerinin  noterlere verilmesi bu anlamda da hukuksal bir güvencenin sağlanmasıdır.Ayrıca bu durum her önüne gelenin inşaat yaptığı ,kontrolün sıkıntılı  olduğu memleketimizde daha ehliyetli ve daha çok parası olan müteahhitliğe teşvik ederek kaliteli inşaatlaşmanın önünü açar diye düşünüyorum.İnşaat sektörü biraz yavaşlayabilir ama inşaat sektörünü hareketlendirip te kalitesiz inşaat yapılmasındansa bu durum daha karlıdır diye düşünüyorum. Tabi inşaat kalitesini sadece bu hususa da bağlamak hata olur.

Kat irtifasını kaldırıp ,tüm binaların iskan almak zorunda olduğu bir yapıya geçmez isek(tabi iskanda sigorta borcu konusunu vergi borcu olma sorunu-fenni olmayan her türlü sorunu iskan vermeye engel bir durum olmayan bir yasaya daha ihtiyaç var) resmi kayıtlarda şu anda olduğu gibi bir zaafla karşı karşı karşıya kalınmaktadır.Devletin aslı kaydı tapudur ve bu asli kayda göre Konya Kent Bilgi Sistemi Çalışmalarına göre Konya da Tipi Yapı olan Taşınmaz  sayısı 127599 iken   tapu kayıtlarında toplam 459057 olan taşınmazdan(tapu)  58382 adetinin  üzerinde bir yapı olduğuna dair kayıt olduğu, tapu kaydını güncel halihazıra kesiştirirsek tapuda var olan resmi bina sayısı  75124 sayısı bulunmaktadır.Bu husus bence devletimizin bir zaafıdır.Bunu teknik anlamı dışında en basitinden  vergilendirmede ,nedenli adaletsizlik oluşturduğunu dikkatlere sunuyorum.

Başka bir yöntem ise iskan vermek yerine vergilendirme konusunda adaletin sağlanması için  belediyelere re’sen bir yetki vererek Belediye encümenine tapu kütüğünün asıl kısmına geçmeksizin (o zaman imar affı olabilir 2981 benzeri)bina varlığı belirleme ve tutulan tutanağa dayanılarak bina beyanı alabilme ve bu kayıtları tapu  kütüğünde beyanlar hanesinde tutma mecburiyeti getiren bir yasal ile yetki verilebilir.Aksaray da 2002-2003 yıllarında yaptığımız bir çalışmada  Tapuda arsa gözüküp te üzerinde aslında bina olan ve içersinde 140 daire olan bir örnekte belediyenin  yıllık sadece 100 milyon TL arsa beyanı aldığı ama aslında burada nerde ise 140x100 milyon TL kadar beyan alınması gerektiği tecrübe edilmiştir.

Bilindiği üzere Bina ve Bağımsız bölümlere numara verilir İken 31 Temmuz 2006 tarihli Adres ve Numaralamaya dair yönetmeliğe göre hareket edilmektedir. İlçe belediyesince inşaat ruhsatı verme aşamasında kat irtifasına  veya İskan aşaması akabinde Kat Mülkiyetine geçilir iken  Tapu Kütüğüne tescil esasına göre verilen numaralar ile yönetmelik kapsamında verilen numaraların aynı olmamasından dolayı uygulamada sorunlar yaşanmaktadır.İş yeri  ve tapuya tescili olmayan bağımsız bölümlerin (kapıcı dairesi vb.) yönetmeliğe göre numaralanması usulü ile kat irtifasına göre verilen numaralar aynı olmamaktadır.Tapuda tescili yapılmayan bağımsız bölümler kat irtifasında numara almamakta ama numarataj yönetmeliğine göre numara alması gerekmektedir.Yine Kat irtifasında herhangi bir yerden numaralandırmaya başlandığı için tapuda yer alan numara ile dairenin Adres yönetmeliğine göre olması gereken numarası da  çoğunlukla tutmamaktadır.Bu nedenle Ulusal Adres Veri Tabanında tanımlanan bağımsız bölüm numaraları ile iskan verilir iken uyuşmazlıklar oluşmakta Adrese dayalı Nüfus Kayıt Sistemin hedeflediği durumdan geri kalınmakta Vatandaş oturum sonrasında Okul kayıt işlemleri veya sonrasında su,elektrik vb aboneliklerinde problemler yaşamaktadır/yaşayacaktır .Ayrıca konut  satın almak isteyen vatandaşın tapuda gördüğü numara ile satın almak istediği dairenin  numarasının aynı olmadığı gördüğünde tedirgin olmakta ve bu durum bazı istismarlara da yol açabilmektedir.Özellikle köşe başına gelen ve farklı sokaklardan numara alan iş yerlerinin hangi esasa göre Ulusal Adres Veri Tabanında  iskanlan dırılacağı konusunda problemler oluşmakta,genelde bir cepheden numara verilmiş gibi iskan ruhsatı işlemleri yürütülmektedir.Sanayi bölgelerinde numaralandırma yapılır iken ayrı ayrı numara verilmesi neticesinde Örneğin iş yerlerinin numarası numarataj yönetmeliğine göre  1-3-5-7 gibi verildiğinde tapuda kat irtifasında bu numaraları aynen korunması istenir ise mümkün olmamakta ,tapu tescilin de 2-4-6 numaralarının nerede olduğu sorulmaktadır. Bu nedenle kat mülkiyeti kanunu ile Nüfus hizmetleri Kanunu çelişmektedir.İlgililere yazı yazdık Nüfus Hizmetleri Genel Müdürlüğü bize uygulamanın Numarataj yönetmeliğine göre yapılmasını istiyor ama Tapu ve Kadastro Kat Mülkiyetine aykırı olduğundan gerekli düzenlemeden kaçınıyor bu durum E-Belediye ile ilgili hususlarda da sorun yaratacaktır …