IMPLEMENTATION DETAILS

  1. Precizări legate de modalitatea de implementare a normelor tehnice aprobate prin Ordinul MDLPA nr. 904/2023:

    1. Prin excepție de la prevederile art. 7, elaboratorii documentațiilor pot transmite către MDLPA și seturi de date spațiale realizate în format Geopackage varianta 1.2.0, în situația în care varianta 1.3.1 nu este disponibilă în aplicația GIS utilizată pentru realizarea setului de date. Verificarea variantei Geopackage utilizate se poate face prin interogarea bazei de date cu expresia „PRAGMA user_version” (fără ghilimele); pentru varianta 1.2 rezultatul acestei interogări este „10200”.

    2. Pentru obiectul spațial ReglementariUrbanisticePunct, câmpul Detaliu_RU, tipul corect al câmpului este varchar (text) și nu decimal, așa cum rezultă și din textul ordinului (p. 19). În „Schema conceptuală a setului de date spațiale pentru documentațiile de urbanism” (p. 7) apare eronat tipul decimal.

    3. În „Schema conceptuală a setului de date spațiale pentru documentațiile de urbanism” (p. 7) relaționarea corectă între obiectele spațiale RegulamentLocalUrbanismDetaliat și ZonaReglementareSuplimentara se realizează la nivelul câmpurilor Cod_SZF_ZRS_D și Cod_ZRS_D, așa cum este menționată și în textul ordinului, Anexa nr. 1, art. 18, alin. (2) și (3) (p. 14). În varianta publicată a schemei este detaliată în mod eronat această relaționare (la nivelul câmpurilor Cod_SZF_ZRS_D și Cod_ZRS).

    4. În acord cu prevederile Anexei 1, art. 11, alin. (2), elaboratorii pot extinde seturile de date cu alte obiecte (layere) noi fără nicio limitare specifică, în funcție de necesitățile identificate în procesul de elaborare a documentațiilor. Limitările impuse de Ordin se referă strict la obiectele și câmpurile incluse în cadrul normativului, care trebuie utilizate pentru scopul specificat și care nu se pot schimba de către elaboratori din punct de vedere al denumirii, tipologiei și valorilor admise.

    5. Pentru introducerea elementelor aparținătoare rețelelor tehnico-edilitare reprezentate sub formă de punct, vă recomandăm să adăugați un obiect spațial nou în baza de date (ex.: ReteleTehnicoEdilitarePunct). Puteți de asemenea să păstrați și pentru acest layer o structură similară cu cea propusă la art. 21, alin. (3) și (4), detaliind în câmpul „Detaliu_RTE” ce reprezintă obiectele reprezentate ca punct (ex.: stații de gaz). Integrarea aspectelor privind rețelele tehnico-edilitare (tip punct) reprezintă un element opțional, care nu este reglementat în cadrul Ordinului și nu condiționează validarea documentațiilor de urbanism.

    6. Obiectul spațial ReglementariUrbanisticePunct, definit în acord cu prevederile art. 23, a fost conceput pentru localizarea imobilelor cu reglementări urbanistice specifice. Punctele reprezentate în cadrul acestui obiect spațial pot fi diferențiate din punct de vedere tipologic după câmpul „Tip_RU”. În cadrul acestui obiect spațial pot fi integrate următoarele aspecte de interes:

    - obiective de patrimoniu (monumente istorice, clădiri cu valoare arhitecturală / ambientală deosebită etc.);

    - obiective de utilitate publică (ex.: unități de învățământ, unități sanitare, clădiri ale administrației publice etc.);

    - alte reglementări urbanistice (ex.: accente de înălțime) sau puncte de interes care nu pot fi reprezentate sub formă de poligon la scara hărții (ex.: intersecții propuse spre amenajare).

    7. Prin excepție de la prevederile Ordinului, în cazul câmpurilor de tip dată (DATE) se acceptă înlocuirea formatului ZZ.LL.AAAA cu formatul implicit utilizat în cadrul Geopackage, conform cu specificațiile ISO-8601 (YYYY-MM-DD). Formatul DATETIME nu este acceptat. În cazul utilizării Esri FileGeodatabase ca format temporar de lucru, în momentul realizării câmpurilor de tip dată, vă rugăm să selectați opțiunea „Date only”; aceasta creează un câmp de tip DATE care va păstra aceeași tipologie și în baza de date Geopackage (dacă se alege opțiunea „Date”, câmpul se transformă în DATETIME la momentul salvării în format Geopackage).

    8. Prin excepție de la prevederile Ordinului, câmpurile Clad_Hmax, POT și CUT din cadrul obiectului non-spațial RegulamentLocalUrbanismDetaliat pot fi de tip text atunci când informațiile incluse în RLU prezintă o complexitate sporită și nu pot fi reduse la o singură valoare.

    9. Toleranța utilizată pentru verificările de topologie (art. 9) este de 0,1 m. Toleranța pentru verificarea respectării limitei administrative a UAT este dată de o zonă-tampon (buffer) de 10 m. Toleranța pentru verificarea valorilor numerice calculate pe baza geometriei (suprafață, lungime) este de 0,1 m / mp / ha (după caz).

    10. Pentru calcularea aspectelor legate de geometria obiectelor spațiale (lungime, suprafață) vă rugăm să utilizați sistemul de referință Stereografic 1970, respectiv coordonate planimetrice, nu elipsoidale. Aplicațiile GIS pot avea funcții distincte pentru calcularea dimensiunilor în cele două sisteme de coordonate - ex.: în QGIS, funcția area($geometry) calculează coordonate planimetrice, în timp ce funcția $area calculează coordonate elipsoidale.

    11. În cazul în care au fost respectare precizările tehnice privind modalitatea de calcul a suprafețelor și se constată totuși că regulile aferente nu sunt validare corespunzător, vă rugăm să verificați faptul că obiectele spațiale din strat sunt de tip Polygon (nu CurvePolygon sau MultiPolygon), folosind o formulă de tipul „geom_to_wkt(@geometry)” (QGIS), aplicată pe înregistrările din tabela de atribute. Dacă obiectele spațiale sunt de alt tip, este necesară conversia acestora în format Polygon, folosind un instrument de tipul „Segmentize by maximum distance” (QGIS) sau Densify (ArcGIS), cu o precizie mică (ex.: 0,000001). Operațiunea va fi urmată de recalcularea suprafețelor folosind coordonate planimetrice.

    12. Pentru generarea stratului PlanSpatial vă rugăm să folosiți limitele administrative oficiale publicate de ANCPI prin aplicația „Descărcare limite administrative” sau prin intermediul serviciului de hartă dedicat (stratul „Unitate administrativa UAT”).

    13. Prin excepție de la prevederile Ordinului (art. 8), în cazul planurilor urbanistice generale, stratul PlanSpatial va fi întotdeauna de tip MultiPolygon, pentru a permite reprezentarea unităților administrativ-teritoriale care dețin mai multe corpuri individuale de teritoriu. Toate celelalte straturi vor fi de tip Point, LineString sau Polygon (după caz).

    14. Prin excepție de la prevederile Ordinului (art. 8), în cazul planurilor de amenajare a teritoriului județean, stratul Limita_UAT_p va fi întotdeauna de tip MultiPolygon, pentru a permite reprezentarea unităților administrativ-teritoriale care dețin mai multe corpuri individuale de teritoriu. Toate celelalte straturi vor fi de tip Point, LineString sau Polygon (după caz).

    15. Între straturile ZFPropusa (câmp Cod_SZF) și RegulamentLocalUrbanismDetaliat (câmpul Cod_SZF_ZRS_D) trebuie să existe o corespondență exactă. Acolo unde nu există coduri unice pentru subzonele funcționale, avem rugămintea să creați această listă și să notificați beneficiarul documentației (primăria) cu privire la acest aspect. Pentru terenurile din extravilan, care nu prezintă reglementări urbanistice specifice în RLU, este obligatorie doar completarea câmpurilor Cod_SZF_ZRS_D, Tip_zona, Tip_SZF_ZRS_D și Desc_SZF_ZRS_D.

    16. Pentru unitățile administrativ-teritoriale care nu au avut planuri urbanistice generale aprobate după anul 1989, pentru stratul LimitaIntravilanExistenta, câmpul „Sursa_revizie” (reprezentând sursa ultimei revizii - HCL aprobare), vă rugăm să utilizați valoarea „L18/19.02.1991”.

    17. Poligoanele de dimensiuni reduse („sliver polygons”) sunt identificate în cadrul instrumentului de validare pe baza raportului dintre perimetru și suprafață, dacă este întrunită condiția unei arii foarte reduse.

    18. Pentru zonele de reglementare suplimentară definite conform art. 5 alin. (6) și art. 16 alin. (3), precizăm că codurile din seria ZRS25-ZRS28 se utilizează atunci când se cunoaște tipologia rețelei tehnico-edilitare, iar codul ZRS12, care are un caracter mai general, poate fi utilizat atunci când există o categorie de rețele tehnico-edilitare care nu se încadrează în tipologia menționată anterior.

    19. Stratul PlanSpatial corespunde limitei de aplicare a documentației de urbanism (art. 12), care reprezintă limita administrativ-teritorială (pentru planuri urbanistice generale), respectiv limita zonei reglementate (pentru planuri urbanistice zonale).

    20. Pentru câmpul Clad_RHMax din cadrul obiectului non-spațial RegulamentLocalUrbanismDetaliat, se acceptă și variante mai complexe de notare a regimului de înălțime al clădirilor, în funcție de specificul RLU (ex.: pentru clădiri cu subsol / demisol / mansardă), chiar dacă precizarea din Ordin este de forma „P+n”. Exemple de formate complexe: D+P+2E+M (demisol + parter + 2 etaje + mansarda), 2S+D+2E+M (2 subsoluri + demisol + parter + 2 etaje + mansarda).

    Updated at: 27-05-2025