Notice bibliographique
Résumé
System Summary Baltimore is an old East Coast city that is diverse not only in its population but also in its infrastructure. The Department of Public Works--Bureau of Water and Wastewater Bureau is responsible for maintaining three of the four city-owned and city-operated utilities. These include the water distribution, storm water, and wastewater collection systems. While the storm water and wastewater collection systems are confined to the city's corporate limits, the water distribution system extends well beyond and services a large portion of neighboring Baltimore County. With systems as complex and extensive as Baltimore's, there is a continuous need to provide large amounts of information to maintenance crews, engineers, designers, consultants, contractors, and the public. This effort has at times been both frustrating and time-consuming for employees, professionals, and homeowners alike. The fact that each utility had its own map scales, naming conventions, and tiling schemes only compounded the problem. With more than a quarter million documents to manage related to the utility infrastructure, records research and timely access to accurate information required for proper decision making have been difficult to provide. Change was needed. Technology and time were the keys to that change. Utility-related Geographic Information System (GIS) development began in earnest in the late 1990s with the typical aerial photography, stereo compilation, and conversion of paper records. This effort was completed in early 2000. At that time, ArcIMS development and system-support requirements made any application development unfavorable. Finally, in 2003, funding and network infrastructure came together, which permitted the establishment of servers running ArcIMS and Oracle/SDE. With the development of U-View, the city can now take advantage of GIS and Internet technologies to provide available tabular, geographical, and image-related data to any user at any PC within the city. No longer are employees tied to their respective offices where the information resided. The loss in productivity resulting from staff having to travel to dispersed locations to retrieve paper records is being eliminated. As an unexpected bonus to the development effort, the application has been found to work exceptionally well with wireless technologies, which will add significant value to the city's investment by allowing maintenance managers, complaint scouts, engineers, and other city managers access to the vast infrastructure data sets in real time, in the field, at the site where timely and accurate emergency decisions, based on real information, need to be made. What makes U-View exemplary and unique within the region is its ability to deliver a variety of utility-related information to a multitude of users at varying levels of city government. From information desk attendants, permit reviewers, and maintenance crews through engineers and appointed decision makers, U-View provides easy and timely access to the information needed for making better decisions related to utility infrastructure management. Motivation for System Development As with most governments, both large and small, in today's economic environment, the biggest motivation is cost and the need to reduce those costs for our constituents. The resounding theme heard in nearly every discussion of budgets is do more with less--less equipment, less staff, less money, but not less services. Given these orders, the natural solution becomes greater use of automation and technology when performing routine manual tasks. The general reduction in man-hours related to records research and retrieval while maintaining or improving records access was the motivation and goal related to the development of U-View. An additional motivation was the need to replace an obsolete version of a desktop-based system that is no longer supported by the vendor. …
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,000 | 0,002 |
| Science ouverte | 0,000 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».